STD-Q — The Quality Standard

The institutional definition of done. STD-Q is the keystone of the Standards layer (00-index.md §5.1): every other Standard holds subject-matter rules; this Standard is the single gate that declares a thing finished, and it cites the others rather than restating them. See 00-index.md for authority, normative vocabulary, citation, and waiver rules.

1. Purpose

1.1 A Codex says what is true. A subject Standard says how to build one kind of thing correctly. STD-Q says when any of it is actually finished, in a form a reviewer who did not do the work can verify without having to trust the author's word.

1.2 STD-Q exists because "it works on my machine," "I tested it," and "it's basically done" are not checkable claims. This Standard replaces them with artefacts, checks, and signatures that a second person can inspect.

2. Scope and non-scope

2.1 In scope: what "ships" means; the universal definition of done; a specific definition of done for nine work classes; the review independence rule; evidence obligations; regression obligations; rollback and recovery obligations; the named-debt rule; the waiver interaction with the other seven Standards; the conformance certificate template.

2.2 Out of scope: the subject-matter content of STD-A, STD-D, STD-S, STD-I, STD-X, STD-R, STD-F. STD-Q never restates a clause from those Standards; it cites the clause and states that conformance to it must be demonstrated before the gate opens.

2.3 Applies to everything that reaches a member, a client, a partner, the public, or production data (00-index.md §5.2) — every surface, API, migration, agent, curriculum unit, publication, internal tool, financial or pricing change, and doctrine change, regardless of division, and regardless of whether the author is human or an AI system.

3. What "ships" means

3.1 A thing has shipped when it is reachable by a member, a client, a partner, the public, or production data — not when the code merges, not when the document is written, not when a demo succeeds. Merged-but-unreachable and reachable-but-uncertified are both "not shipped."

3.2 A thing that is reachable but has not passed this Standard's gate is a defect in the release process, not a grey area. It is rolled back or gated off, not left live pending paperwork.

3.3 "Shipping" a partial capability is permitted only where the Registry status is set to partial and the gap is named per §7 (named debt); a partial status is not a lower bar, it is an honest label on a bar that was still met for what is actually reachable.

4. The universal definition of done

4.1 The following apply to every work class in §5, without exception. A work class's specific section adds to this list; it never subtracts from it.

4.1.1 Registry entry precedes implementation. The Registry entry (Codex 0 §0.6, all eight fields) exists and is current before the work is built (00-index.md §6.1). Work built without a prior Registry entry is non-conformant regardless of its quality.

4.1.2 The governing Standard is satisfied, not asserted. Every applicable subject Standard's conformance checklist (STD-A, STD-D, STD-S, STD-I, STD-X, STD-R, STD-F, as relevant to the work) is completed and attached to the work's record.

4.1.3 Evidence, not assertion. Every conformance claim states how it was checked — the command run, the page tested, the query inspected, the reviewer's independent action — not merely that it was checked (§6).

4.1.4 Independent review. The person who signs conformance is not the work's author (§8).

4.1.5 Regression is checked, not assumed absent. The work's effect on existing behaviour, existing data, and existing commitments is verified, not inferred from the change being "additive" (§9).

4.1.6 Rollback is possible and named. A path back to the last known-good state exists and is stated before the work ships, for anything that touches production data, a public surface, or a financial commitment (§10).

4.1.7 Incompleteness, if present, is named debt. No unnamed gap, shortcut, or deferred correctness exists in shipped work (§7).

4.1.8 The Registry status moves. On shipping, the author moves the Registry status to reflect reality (built, partial, with what remains named); an untouched status after shipped work is itself a defect (Codex 0 §0.6.5).

4.1.9 The final gate is answered. "Did this make the person's life better?" is answered in writing, per §12, before the certificate is signed.

5. Definition of done by work class

Each work class below states: required artefacts, required checks, the Registry status movement, and who signs. All entries additionally require §4 in full.

5.1 A surface or page

• Artefacts: the Codex 6 page or interaction template; the completed Institutional UX Rubric self-score (STD-X §… / CODEX-6/RUBRIC.md); the review form (TEMPLATE-review.md).
• Checks: all eight rubric dimensions scored with written evidence; no dimension at 0; any dimension at 1 carries a named remediation owner and date; the final gate of the Rubric answered; accessibility checked by an independent pass (keyboard, contrast, reduced motion), not asserted; all five states (error, empty, loading, partial, unauthorised) specified and reachable in a manual walkthrough.
• Registry status: moves to built only once the rubric total, the dimension floor, and the final gate all pass; a rubric total at 16 or below returns the work to redesign, not to a lower "shipped" status.
• Signs: a reviewer independent of the surface's author, holding UX review authority for the division; Stewardship Office assent required if the surface touches member trust or credential presentation.

5.2 A server boundary or API

• Artefacts: the STD-A module-boundary declaration (interface contract: accepted shapes, returned shapes, error shapes); the STD-S access-control record for the boundary (caller verification method, per Codex 0 §17.5.3); a version note if the boundary is public.
• Checks: caller verification tested for a public route, not assumed from internal convention; edge validation confirmed on a malformed payload, not only a valid one; row-level policy tested against the policy itself, independent of the application's intended access pattern (Codex 0 §17.13.4); typecheck output read in full with zero unread error text (Codex 0 §17.13.2); a breaking change carries a version, a migration window, and a decision record.
• Registry status: moves to built when the boundary is reachable, tested, and its consumers (named in "how it connects") are confirmed unaffected or migrated.
• Signs: a reviewer independent of the author holding engineering review authority; a second sign-off from a Stewardship-designated reviewer where the boundary touches member data or a consequential action (Codex 0 §17.9.3).

5.3 A database migration

• Artefacts: the migration file with its GRANTs and row-level policy included in the same migration that creates or alters the table (mandatory per stack fact; STD-D, STD-S); a stated default-deny posture for any newly introduced access pattern not yet specified (Codex 0 §17.6.3).
• Checks: the policy is tested against a request that should be denied, not only one that should be allowed; the migration is confirmed reversible or its irreversibility is named and accepted in writing before it runs; any delegated access grant carries a stated expiry.
• Registry status: the owning entry's status does not advance on a migration alone; it advances only when the feature the migration supports is itself functionally verified (Codex 0 §17.14.3 applies by analogy: status moves through demonstrated work, not through schema existing).
• Signs: a reviewer independent of the author holding data or security review authority; the Stewardship Office where the table holds member data.

5.4 An AI agent

• Artefacts: the STD-I scope declaration (what the agent may read, decide, and act on); the human-checkpoint map (where a person decides rather than the agent); the evaluation and logging plan.
• Checks: every consequential action the agent can trigger is confirmed to route through a human checkpoint or an audited, reversible path (Codex 0 §17.9.3); the agent's explanation of its own action is checked against the actual action taken, not merely present; a sampled set of the agent's outputs is independently reviewed for the failure mode named in the proposal's Institutional Critic (Codex 10, question 1).
• Registry status: moves to built only once the checkpoint map is demonstrated in a real run, not a specification alone.
• Signs: a reviewer independent of the agent's author holding AI review authority; Stewardship Office assent where the agent touches member data, credentials, or a financial commitment.

5.5 A curriculum unit or lesson

• Artefacts: the capability it targets, named against the knowledge graph (Codex 0 Chapter 06); the assessment instrument that will verify the capability was actually gained.
• Checks: the assessment is checked for rigor independent of the author (a second qualified reviewer attempts or reviews the assessment blind); the unit is checked against Codex 1 Article VI.7 — no softened assessment to raise completion figures; the unit's claims are checked against demonstrated capability, never consumption metrics (Codex 0 §16.2.2).
• Registry status: moves to built once delivered to at least one real cohort and the assessment's discrimination (does it actually distinguish who gained the capability) is reviewed.
• Signs: a reviewer independent of the author holding Academy faculty or curriculum authority.

5.6 A research publication

• Artefacts: the methodology and underlying data, retained in a form supporting independent reproduction (STD-R); the sponsor-disclosure record if sponsored (Codex 0 §15.6.6).
• Checks: an independent reviewer attempts to verify the finding's central claim against the retained methodology and data, not against the narrative alone; editorial independence from any sponsor's preferred conclusion is confirmed in writing.
• Registry status: moves to built/published only once the independent verification pass is recorded.
• Signs: a reviewer independent of the author holding Research Institute editorial authority; the author is never their own methodology reviewer.

5.7 An internal operator tool

• Artefacts: the STD-A boundary declaration if it consumes an API; the access-scope record (who may use it, on what data).
• Checks: operator-facing figures are checked against the same honesty rule as public reporting (Codex 0 §16.2.3) — a number without a stated definition and period does not ship; elevated access is confirmed to produce an audit record (Codex 0 §17.6.4).
• Registry status: moves to built once a real operator has completed a real task with it under observation, not once the interface renders correctly in isolation.
• Signs: a reviewer independent of the author holding engineering or the owning division's operational authority.

5.8 A financial or pricing change

• Artefacts: the STD-F seven-axis evaluation; the STD-F conformance checklist completed in full.
• Checks: all items on the STD-F checklist (§5 of STD-F) confirmed yes or no-with-reason; the pricing surface is scored against the Codex 6 Rubric dimension 6 dark-pattern list where the change touches an interface; concentration and reserve impact confirmed against current thresholds.
• Registry status: a new revenue stream or material pricing change does not move to built without the seven-axis evaluation dated before commitment and a recorded Codex 10 review (Codex 0 §15.9.1).
• Signs: a reviewer independent of the author holding financial review authority; Stewardship Office assent for anything touching reserves or member-facing pricing.

5.9 A doctrine change

• Artefacts: the decision record naming the clauses changed, the reasoning, and what it supersedes (00-index.md §7.1); the Codex 10 Institutional Critic examination; the Codex 8 seven-axis evaluation where the change has financial effect.
• Checks: the decision record is checked for whether it names a superseded clause correctly and whether the citation-numbering rule is respected (numbers never reused, 00-index.md §3.2); a pattern of waivers against the clause being changed is checked as the trigger, per 00-index.md §7.2, rather than the change being introduced for unrelated convenience.
• Registry status: the amended Standard or Codex is updated only after the decision record exists, never edited first and recorded after.
• Signs: the Stewardship Office, always, for any doctrine change (00-index.md §1.2, §4.4); a doctrine change is never self-certified by the division that proposed it.

6. Evidence obligations

6.1 A conformance claim states the method: what was run, what was read, what was independently reproduced, and by whom. "Tested" is not evidence; "ran the cancellation flow as a new user and counted four steps against enrollment's four steps" is evidence.

6.2 Evidence is written into the work's record at the time it was gathered, not reconstructed from memory at sign-off. A reviewer who cannot find contemporaneous evidence treats the claim as unverified.

6.3 Where a check was performed by an AI system rather than a person, the record states that plainly; an AI-performed check does not substitute for the human sign-off required by §8.

7. The named-debt rule

7.1 Named debt is the only form of incompleteness this Standard permits. It states, at minimum: the constraint that forced the tradeoff, the capability given up, and the condition under which it must be repaid (a scale threshold, a Registry status change, a date) — the same discipline Codex 0 §17.14.2 requires for engineering debt, generalised to every work class.

7.2 Debt without a named owner and a named repayment condition is not debt; it is an unrecorded defect and blocks shipping under §4.1.7.

7.3 A Registry status is never moved upward on the strength of debt going unremarked (Codex 0 §17.14.3). Debt is repaid through demonstrated work, tracked to closure, not forgotten by omission.

8. Review independence

8.1 The author of a piece of work does not sign its own conformance. A second person, holding the review authority named for that work class in §5, performs the check and signs.

8.2 Where no second qualified reviewer exists in a division at the time, the work does not ship until one is found or the review authority is delegated in writing to another division's qualified reviewer; a Registry entry is never certified solo because a reviewer was unavailable.

8.3 Independence extends to AI: an AI system does not certify its own output's conformance, and a person does not rubber-stamp an AI's self-report as if it were independent review (STD-I).

9. Regression obligations

9.1 Every change is checked against what it might break, not only what it intends to add. The check names the surfaces, boundaries, or reports that consume the changed thing (per STD-A §3's module-boundary declaration) and confirms each still behaves as before, or names the intended change to each.

9.2 A regression check that only exercises the new path and never re-exercises an existing one is incomplete and does not satisfy §4.1.5.

9.3 A metric, report, or credential-bearing figure that changes value as a side effect of unrelated work is treated as a regression until proven to be an intended, disclosed change (Codex 0 §16.9).

10. Rollback and recovery obligations

10.1 Before anything reaches production data, a public surface, or a financial commitment, the path back to the last known-good state is stated: what is reverted, how long it takes, and who is authorised to execute it.

10.2 A migration or data change that cannot be reverted states that irreversibility explicitly, and is accepted in writing by the reviewer, before it runs, not discovered after.

10.3 A degraded state on rollback failure names what could not be restored; it never fabricates a success state (Codex 0 §17.10.3).

11. The waiver interaction

11.1 STD-Q does not grant waivers itself; a waiver is granted against a specific clause of STD-A, STD-D, STD-S, STD-I, STD-X, STD-R, or STD-F, under the terms of 00-index.md §4.

11.2 A work item may not pass STD-Q's gate carrying a must not violation from any of those Standards under any waiver; must not clauses are never waivable (00-index.md §4.1).

11.3 A work item may pass STD-Q's gate carrying a waived must clause only if the waiver is visible in the work's Registry entry, names an owner and an expiry date, and — where it touches mission, member trust, data use, credential integrity, or reserves — carries Stewardship Office assent (00-index.md §4.4).

11.4 An expired waiver discovered at any later review is treated as a present defect against the underlying Standard's clause, reported through that Standard, not silently renewed (00-index.md §4.5).

11.5 A pattern of waivers against the same clause across multiple work items is escalated as evidence the clause is wrong, per 00-index.md §7.2, rather than repeatedly re-granted.

12. The final gate

12.1 After every other clause in this Standard is satisfied, the reviewer answers in writing, in one paragraph, the question from Codex 6's Rubric, generalised to every work class:

Did this make the person's life better?

12.2 "It increased engagement" is not a valid answer to §12.1 and is an automatic failure regardless of every other score or check passed (Codex 0 §01.4.5; CODEX-6/RUBRIC.md, "The final gate"). A reviewer who receives this answer returns the work, unsigned.

12.3 The final gate cannot be satisfied by inference from metrics. It is answered about the specific person or institution the work reaches, in terms a second reviewer could contest.

13. Conformance certificate template

A single page, completed by the reviewer for any work class, attached to the Registry entry.

CONFORMANCE CERTIFICATE

Work item:                 [Registry ID and short name]
Work class (§5):           [surface | API | migration | agent | curriculum |
                             research | operator tool | financial | doctrine]
Author:                    [name]
Reviewer (independent, §8): [name — must differ from author]

Registry entry existed before implementation:      yes / no / n-a-because
Governing subject Standard(s) checklist attached:   [STD- IDs]  yes / no
Universal definition of done (§4) satisfied:        yes / no / n-a-because
Work-class specific artefacts present (§5):         yes / no / n-a-because
Work-class specific checks performed, with evidence
  stated per §6 (how, not that):                    yes / no / n-a-because
Regression check performed (§9):                    yes / no / n-a-because
Rollback path stated (§10):                          yes / no / n-a-because
Named debt recorded, if any (§7):                    yes / no / n-a-because
  - Constraint:            [ ]
  - Capability given up:   [ ]
  - Owner:                 [ ]
  - Repayment condition:   [ ]
Active waivers against subject Standards (§11):     yes / no
  - Clause waived:         [ ]
  - Owner:                 [ ]
  - Expiry:                [ ]
  - Stewardship assent (if required):  yes / no / n-a-because
Registry status moved to reflect reality (§4.1.8):  yes / no / n-a-because

Final gate (§12): "Did this make the person's life better?"
[one paragraph, specific to this work item, in the reviewer's own words]

If the honest answer restates "increased engagement" in any form, this
certificate is void and the work is returned unsigned.

Reviewer signature:        [name, date]
Stewardship assent (if required by §11.3 or the work class's §5 entry):
                            [name, date, or "not required because ___"]

14. Governing Codex clauses

14.1 Codex 1, Article III (the tests before work exists) and Article V/VI (the non-negotiables this gate enforces at the point of shipping).

14.2 Codex 0 §0.6 (Registry mandatory before implementation) and §17.13–17.14 (verification and technical debt), generalised here from engineering to every work class.

14.3 CODEX-6/RUBRIC.md, "the final gate" and the prohibited-pattern list, which §12 and the surface-class §5.1 cite directly.

14.4 Codex 10, the nine questions, which a major proposal answers before this Standard's gate is ever reached (00-index.md §6.2).

15. Conformance checklist

• [ ] The Registry entry existed, complete, before implementation began. (yes/no/n-a-because)
• [ ] Every applicable subject Standard's checklist is attached and completed. (yes/no/n-a-because)
• [ ] Every conformance claim states how it was checked, not merely that it was. (yes/no/n-a-because)
• [ ] The signing reviewer is not the work's author. (yes/no/n-a-because)
• [ ] A regression check was performed against existing behaviour, not only the new path. (yes/no/n-a-because)
• [ ] A rollback path is stated, or irreversibility is named and accepted in writing. (yes/no/n-a-because)
• [ ] Any incompleteness is recorded as named debt with an owner and repayment condition. (yes/no/n-a-because)
• [ ] Any active waiver names an owner, an expiry date, and Stewardship assent where required. (yes/no/n-a-because)
• [ ] The Registry status was moved to reflect the work actually done. (yes/no/n-a-because)
• [ ] The final gate was answered in writing and specifically, and did not rest on engagement. (yes/no/n-a-because)

16. Interfaces to other Standards

16.1 STD-A, STD-D, STD-S, STD-I, STD-X, STD-R, STD-F each supply the subject-matter checklist that STD-Q requires as a precondition; STD-Q never duplicates their clauses, only requires their satisfaction be demonstrated.

16.2 STD-X's Institutional UX Rubric is the required artefact for the surface work class (§5.1) and the source of the final gate's wording (§12).

16.3 STD-F's checklist is the required artefact for the financial work class (§5.8); a financial change cannot pass STD-Q without it.

16.4 STD-S's access-control and audit obligations are the required checks for the API and migration work classes (§5.2, §5.3).

16.5 STD-I's checkpoint-mapping obligation is the required artefact for the agent work class (§5.4) and governs review independence for any AI-authored work under §8.3.

17. Open questions

17.1 The specific qualification criteria for who may hold "review authority" per work class in §5 are reserved pending each division's first certification cycle under this Standard.

17.2 Whether a tenth work class (e.g., a cross-division workflow spanning several of §5's classes at once) needs its own definition of done, or is adequately covered by requiring every component class's gate individually, is open pending the first such workflow's certification.

17.3 The mechanism for escalating a repeated pattern of near-miss final-gate answers (technically not "engagement" but functionally adjacent) to a doctrine review is reserved pending Codex 10 guidance.