# Documentation Standards

These standards keep AeThex documentation operational, reviewable, and honest about the maturity of each system.

| Field | Value |
|---|---|
| Documentation status | Active |
| Maintainer | AeThex documentation maintainers |
| Last verified | 2026-06-26 |

## Required page header

Product and service pages should identify:

- Product maturity: research, alpha, beta, live, maintenance, or deprecated.
- Documentation status: draft, active, needs verification, or archived.
- Public URL when one exists.
- Owning AeThex program.
- Last verified date.
- Source repository when public.

## Content requirements

A stable product page should answer:

1. What is this system?
2. Who is it for?
3. What works now?
4. How does someone begin?
5. Which identities or permissions are required?
6. What data does it store?
7. What are its known limitations?
8. Where are changes recorded?

## Maturity language

| Label | Meaning |
|---|---|
| Research | Exploring the problem; interfaces are not commitments |
| Alpha | Implemented but expected to change |
| Beta | Usable with known limitations |
| Live | Publicly available and actively operated |
| Maintenance | Supported with limited active development |
| Deprecated | Scheduled for removal or replacement |

## Verification

- “Last verified” means a maintainer checked the page against the running system or current source.
- Automated health checks do not replace behavioral verification.
- Pages older than 90 days should be reviewed or marked as needing verification.
- Never publish credentials, private operator endpoints, internal hostnames, or user data.

## Change discipline

- Update the changelog before announcing a shipped capability.
- Link behavior changes to the affected reference page.
- Keep future plans in roadmaps, not API reference pages.
- Preserve historical entries; add corrections rather than silently rewriting history.