Reviewed Transitions

The transition boundary is where a proposed account gains authority to become current truth.

Binding review

TM-CHG-001 — Exact proposal identity. Review MUST bind an exact proposed change, including its delta, evidence set, rationale, uncertainty, and expected state. An implementation MUST make unreviewed substitution detectable.

TM-CHG-002 — Attributable review. An accepted change MUST identify the reviewing authority and acceptance event. When different reviewers authorize different parts, their scopes MUST remain explicit.

TM-CHG-003 — Expected-state check. Application MUST verify that current truth still has the state or revision the accepted proposal expected.

Application

TM-CHG-004 — Atomic coherence. Application MUST advance every mutation inside the proposed coherence boundary together or advance none of them.

TM-CHG-005 — Validation before visibility. All invariants required for the new current state MUST pass before that state becomes visible as current.

TM-CHG-006 — Stale work advances nothing. If the expected state is stale, the transition MUST NOT modify current truth. Reconciliation or review must occur again against the new state.

TM-CHG-007 — Invalid work advances nothing. If any required mutation, authority rule, provenance link, or invariant fails, the transition MUST NOT partially advance current truth.

TM-CHG-008 — Change and truth move together. A successful transition MUST make the new current truth and its complete accepted change record durable as one recoverable operation.

Accepted change record

TM-CHG-009 — Durable change content. An accepted change record MUST retain:

• stable change identity;
• exact expected prior state;
• exact before and after effect;
• cited evidence;
• rationale;
• material uncertainty;
• proposing actor;
• reviewing authority and acceptance event;
• validation result; and
• resulting current-state identity.

TM-CHG-010 — Append-only decision. An accepted change MUST NOT be substantively rewritten. A correction MUST be a later attributable change that preserves what was accepted previously.

TM-CHG-011 — Ordered successor. Current-state identities MUST provide a deterministic successor relationship sufficient to identify what state a change replaced.

Identity mechanisms

The specification does not require one hashing or transaction mechanism. Suitable implementations include:

• database transactions plus immutable change identities;
• content-addressed proposal documents;
• signed event envelopes;
• compare-and-swap revisions;
• Git commits with a verified expected parent; or
• deterministic canonical serialization followed by a cryptographic digest.

The burden is behavioral: what applies must be exactly what was reviewed, and stale or invalid work must be structurally unable to become current.