Codex 10 — The Institutional Critic

The greatest danger to a long project is affection for its own ideas. This Codex installs disciplined review at the point of proposal, so that ideas are pressure-tested before they become part of the institution rather than after they have cost a redesign.

The Critic is not a veto and not a committee. It is a written self-examination the proposer performs, in the proposal, before anyone is asked to accept it.

When the Critic is mandatory

A proposal is major — and therefore requires a critique — when it does any of the following:

• adds a new public surface, division, engine, or dashboard;
• adds or changes a table, an API boundary, or a permission scope;
• creates a new revenue stream, price, or contractual commitment;
• touches member data, credentials, assessment integrity, or public claims;
• introduces a recurring operational or vendor cost;
• changes doctrine, or asks for an exception to it.

Small, reversible work inside an existing pattern does not require a critique. When it is unclear, write the critique.

The nine questions

Each is answered specifically. "No concerns", "should be fine", and restating the proposal are not answers. An honest unknown is an acceptable answer; an unexamined one is not.

1. 1What could fail at scale? Describe the failure at a hundred times today's volume: which query, queue, cost line, review workload, or human bottleneck breaks first.
2. 2What assumptions are we making? List them, and mark which are verified and which are not. Name the assumption whose falsehood would be most expensive.
3. 3Is there a simpler solution? State the simplest version that would deliver most of the value, and say plainly why it was not chosen.
4. 4Does this duplicate an existing system? Check the engines, the knowledge graph, and the other divisions. If a capability exists anywhere, extend it rather than fork it (Codex 0, §2; Codex 3).
5. 5How would an enterprise customer view this? Consider procurement, security review, reporting scope, data residency, contractual promises, and what it would cost them to trust it.
6. 6How would a first-time user experience this? Walk the first ninety seconds with no prior context and no vocabulary. Name where confidence is lost.
7. 7What legal, operational, or security concerns arise? Privacy and consent, retention, jurisdiction, credential and certification claims, access paths, and who is on the hook when it fails at 3am.
8. 8What technical debt could this introduce? Name the debt, what was traded for it, and what repays it. Unnamed debt is not permitted (Codex 7).
9. 9Is this consistent with the Constitution and the Codices? Cite the Codices it touches. Where it conflicts, name the conflict and propose the closest compliant alternative (Codex 9).

Standard of review

• A failed question requires redesign before proposal, not a caveat after it. This mirrors Codex 1, Article III.
• The critique is preserved with the proposal and, where the proposal becomes a decision, carried into its record in DECISIONS/ (Codex 9).
• The Critic runs before approval. A critique written after a decision is documentation, not review.
• The purpose is not rejection. Most proposals survive the Critic in a stronger, smaller, or better-sequenced form — that is the intended outcome.

Companion tests

The Critic sits alongside two other gates, and a major proposal answers all three: