Skip to content

Document Status, Source Baseline And Precedence Rules

  • Status: CURRENT CROSS-FAMILY DOCUMENT AUTHORITY RULE
  • Current source baseline at publication: qa/master@b09c339ec1a7305554af16bd55bc4be1685719b5
  • Durable Context: Appendix O
  • Applies to: Product/Context, Roadmap, Tasks, Process contracts, reconstruction packets, Runbooks, Wiki projections, operational handovers and source-candidate evidence
  • Does not own: Product decisions, Task activation, Process lifecycle, Runtime behavior, Wiki publication or external effects

1. Problem

CTC contains current source, historical plans, detached candidates, detailed reconstruction packets and future migration designs. Those artifacts are all useful, but they answer different questions.

A document becomes unsafe when it uses one word such as CURRENT, DONE, RELEASED or IMPLEMENTED for multiple meanings.

Examples of prohibited ambiguity:

source exists
-> described as field accepted

candidate had local tests
-> described as current qa

remote master moved
-> described as runtime healthy

rebuild packet is detailed
-> described as M4

historical plan is approved
-> used as current implementation prompt

This document defines the required status vocabulary and precedence.

2. Status Classes

2.1 CURRENT VERIFIED / ACCEPTED

Use only when the exact claimed dimension has current evidence and acceptance.

Required qualifiers:

source / environment / tenant / role / process / provider / deployment
verification date
acceptance owner

Examples:

CURRENT SOURCE VERIFIED at qa/master@<sha>
CURRENT TARGET-ROLE VERIFIED in local environment
CURRENT PRODUCTION SOURCE READBACK at <sha>
CURRENT FIELD ACCEPTED by <role/owner>

One qualifier does not imply the others.

2.2 CURRENT SOURCE-RECONCILED

Use when current source families were inspected and reconciled into one consistent model, but Runtime/role/provider/field evidence remains incomplete.

source-backed current model
!= Runtime verified
!= Process approved
!= M3

A source-reconciled packet must name the analysis baseline.

2.3 CURRENT SOURCE PRESENT / EVIDENCE REQUIRED

Use when source exists at current qa/master, but documentation has not yet reconciled the current implementation or required evidence.

Typical causes:

  • new operational commit after packet baseline;
  • implementation differs from approved historical plan;
  • source was merged without current role/provider/Wiki evidence;
  • current schema/environment state is unknown.

2.4 POST-BASELINE SOURCE DELTA

Use when a later source commit touches a documented family after its analysis baseline.

The delta register records:

commit
changed owners
change class
packet validity
required revalidation

A post-baseline delta does not automatically invalidate an entire packet. It does block a claim that the older baseline is fully current until disposition is recorded.

2.5 HISTORICAL USER DECISION

Use for approved direction that remains important but is no longer a reliable implementation description.

It may preserve:

  • user intent;
  • non-goals;
  • rejected alternatives;
  • required visible result;
  • architectural limits.

It must not be executed as a current implementation plan unless current source authority explicitly reactivates it.

2.6 HISTORICAL IMPLEMENTATION PACKAGE

Use for an old staged plan, prompt or progress ledger whose implementation stage has ended, been superseded or diverged from current source.

Required banner:

DO NOT EXECUTE AS CURRENT IMPLEMENTATION AUTHORITY

The package remains useful as evidence and decision provenance.

2.7 SOURCE CANDIDATE

Use for code that is not current qa/master.

Required fields:

exact ref/SHA
base and relationship to current qa/master
changed source surface
embedded evidence
conflicts/unknowns
accept/revise/reject owner

A candidate is never called released merely because it is ahead of a branch or once passed local tests.

2.8 TARGET MIGRATION DESIGN

Use for the intended React/Next.js/TypeScript/worker/PostgreSQL or platform target.

It must state:

NOT CURRENT RUNTIME
NOT ACTIVATED unless Roadmap/user says otherwise

2.9 OPEN POLICY / UNKNOWN

Use when source, user decision or runtime evidence does not answer the question.

Do not replace UNKNOWN with:

  • a plausible default;
  • current customer ID behavior;
  • a framework convention;
  • a test assumption;
  • an inferred operational practice.

3. Baseline Fields

Every source-authority or reconstruction packet includes:

analysisBaseline
currentHeadAtLastReview
ownedSourceFamilies
postBaselineDeltaState
runtimeEvidenceState
wikiEvidenceState
migrationReadinessState

3.1 Analysis baseline

The exact ref/SHA inspected when the packet was written.

It remains historically valid even after source moves.

3.2 Current head at last review

The exact qa/master head when freshness was last checked.

3.3 Post-baseline delta state

Allowed values:

NONE
COMPATIBLE DELTA RECORDED
REVALIDATION REQUIRED
PACKET REVISION REQUIRED
PACKET SUPERSEDED
UNKNOWN

3.4 Evidence state

Use independent fields:

sourceEvidence
localRuntimeEvidence
targetRoleEvidence
providerDeviceEvidence
productionSourceEvidence
productionRuntimeEvidence
fieldAcceptance
stabilization

Never collapse them into one verified field.

4. Authority Precedence

4.1 Current implemented behavior

current qa/master source
-> current authorized environment evidence
-> owning current source-authority document
-> current Process contract
-> current Runbook/Wiki projection
-> historical plan/candidate
-> target design

Environment evidence can refine source interpretation but does not rewrite Product/Process intent.

4.2 Product and architecture direction

current user decision
-> Product / durable Context
-> Target Design
-> Roadmap activation state
-> Task details
-> research/proposals

4.3 Phase and Task status

current user instruction
-> docs/ROADMAP.md
-> activated Task file
-> Task evidence

A Task file or implementation commit does not activate itself.

4.4 Process semantics

Product/Profile intent
-> owning Process contract
-> current source facts
-> policy decision matrix
-> reconstruction packet
-> UI/API/table adapters

4.5 Wiki content

current T_WIKI_PAGE + rendered page
-> accepted Process/Runbook meaning
-> repository projection draft

Repository projection never proves publication.

4.6 Deployment and recovery

remote source release
-> observed deployed runtime identity
-> readiness/dependency evidence
-> business canary
-> field acceptance/stabilization

5. Conflict Rules

5.1 Contradictory statements inside one document

If one document simultaneously says:

released
and
not merged / not released

then the status section is invalid until rewritten.

Do not choose whichever sentence appears first.

5.2 Navigation duplicates volatile status

Navigation files link to the owner rather than copying:

  • current candidate SHA;
  • current release SHA;
  • detailed stage status;
  • Production schema count;
  • provider state.

Volatile facts belong in one source-authority/evidence owner.

5.3 Historical prompt remains executable

When current source exists or the implementation package is retired:

  • add DO NOT EXECUTE banner;
  • point to current source authority;
  • preserve the file only as history;
  • remove it from current execution navigation.

5.4 Later source touches an owned family

The family owner must choose:

NO SEMANTIC IMPACT
ADDENDUM SUFFICIENT
FULL REVALIDATION REQUIRED
PACKET REVISION REQUIRED

5.5 Current source contradicts approved historical decision

Do not silently change the Product decision or pretend the source matches it.

Record:

approved decision
current source behavior
exact divergence
operational risk
safe current action
future correction owner

When implementation work is held, the safe current action is documentation/review only unless an operational defect requires a separately bounded fix.

6. Freshness Classes

Class Meaning Allowed use
HEAD-CURRENT source authority reviewed against current qa/master current source description
DELTA-RECONCILED later source exists and an addendum records its impact current with explicit addendum
BASELINE-STALE later source touched the owner and no disposition exists historical/reference only
TARGET-ONLY future target, no current implementation claim migration design only
UNKNOWN current relationship cannot be established stop consequential reliance

A packet may be detailed and BASELINE-STALE at the same time.

7. Readiness And Coverage Separation

7.1 Documentation coverage

MISSING
MAPPED
PARTIAL
COMPLETE INPUT

7.2 Process lifecycle

draft
reviewed
approved
deprecated

7.3 Migration readiness

M0
M1
M2
M3
M4
M5

7.4 Implementation/release evidence

SOURCE PRESENT
ENGINEERING CANDIDATE
LOCAL RUNTIME VERIFIED
TARGET-ROLE VERIFIED
RELEASED SOURCE
PRODUCTION RUNTIME VERIFIED
FIELD ACCEPTED
STABILIZED

These are independent axes.

A large COMPLETE INPUT packet can remain M1/M2 and unimplemented.

8. Current Cross-Family Rule

At qa/master@b09c339ec1a7305554af16bd55bc4be1685719b5:

All Phase implementation: USER HOLD
No family: accepted M4
Current operational source: may continue changing
Documentation: must consume later operational deltas

Source authority documents must not pin a stale SHA as current qa without also recording current head and delta disposition.

9. Document Header Template

Use this minimum header for current source/rebuild documents.

Status:
Owner:
Analysis baseline:
Current head at last review:
Post-baseline delta state:
Current Runtime/source classification:
Runtime/role/provider/field evidence:
Process lifecycle:
Migration readiness:
Effect boundary:
Supersedes / superseded by:

10. Correction And Retirement

A stale document is handled by one of:

UPDATE IN PLACE
ADD CURRENT DELTA ADDENDUM
RECLASSIFY AS HISTORICAL
REPLACE WITH SUCCESSOR AND REDIRECT NAVIGATION
DELETE AFTER CONSUMER/CALLER-ZERO

Before deletion or movement:

  • search human and executable consumers;
  • update navigation and pinned paths;
  • preserve decision/evidence references;
  • prove no current execution prompt depends on it;
  • retain Git history as historical recovery.

11. Review Checklist

Before describing a document as current:

  • [ ] exact current qa/master checked;
  • [ ] later commits touching owned source inspected;
  • [ ] no contradictory status statements;
  • [ ] historical decision separated from current source;
  • [ ] current and target behavior separated;
  • [ ] Runtime/role/provider/Wiki evidence stated independently;
  • [ ] lifecycle and M-readiness not inferred from document detail;
  • [ ] volatile status owned by one document;
  • [ ] effect boundary explicit;
  • [ ] next owner and revalidation trigger recorded.

---

Source: docs/reconstruction/DOCUMENT_STATUS_BASELINE_AND_PRECEDENCE_RULES.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.