P1-001 Stage 1 — Canonical Document Hierarchy Draft

• Status: RESEARCH / P1-001 USER-APPROVED DECISION RECORD — D2=B; D1/D3~D12=A
• Authority: preserves the user-approved P1-001 Stage 1 decision; current rules are owned by the integrated canonical owners
• Task: P1-001
• Decision source: CTC_PRODUCT_PLATFORM_AND_DOCUMENTATION_CONTEXT.md
• Decision-time source snapshot: qa@508eb0be8e80e2d8267fc1f6c1195fd838258a18, Local Reset Revision 11
• Drafted: 2026-07-30
• Retention: keep as P1 decision traceability; deletion requires a separate disposition after committed owner absorption and consumer review

2026-07-31 user correction: this dated record preserves its decision-time Reset wording, but every proposal that treats that document as temporary or deletes it after P1 is superseded. The renamed durable Context remains throughout the project.

1. Approval boundary

The user approved D2 option B and options A for D1 and D3-D12. At that decision point, this authorized Stage 3 owner construction and the Stage 4 source-by-source integration review. It did not authorize:

• moving or deleting a Runtime-, script-, build-, in-app manual- or operator-consumed path;
• creating a catalog, generated index, validator or fixed Harness;
• implementing Request Operations, Control Tower, MK, PostgreSQL or React;
• changing Runtime, database, provider, service, master or Production state;
• changing remote Roadmap status, committing, pushing or creating a handoff;
• declaring a Stability Gate pass, Product readiness or P10/P11/P12 activation;
• deciding or implementing P1-004 verification policy/script or P5/P6 semantics.

At the decision point, this Local artifact was not remote completion, changed-file or evidence state. A later commit/handoff required one final writer to reconcile the committed Roadmap and owner documents. The approval was recorded in Local Reset Revision 11 and was uncommitted at that time; current integration and Git state are read from the canonical owners, Roadmap and repository refs.

2. Proposed principles

1. Route a question to its document class before comparing authority.
2. One recurring question has one current owner.
3. A target document states what is approved, not what is implemented.
4. A current technical owner states verified Runtime fact only within its surface.
5. Research and evidence retain detail and provenance but never own current Product, Phase, Task or process status.
6. docs/ROADMAP.md alone owns Phase/Task status, Lane, parallelism and dependencies. A Task file owns its execution detail.
7. A process contract owns required business behavior. A manual owns the steps a user follows. Neither silently rewrites the other.
8. Process state, authority, exception, retry and recovery are defined before module manifests or command/query/handler templates that implement them.
9. Git history is the default history store. A historical file remains in the current tree only for unique evidence, a proven consumer or an explicit retention requirement.
10. Existing paths are retained unless an approved decision changes them. D2=B moves Product/System target ownership only after every active consumer can migrate in the same rollback unit; old sources remain compatibility inputs until verification.
11. Required metadata and human review are sufficient. No catalog, generated status or exact-text validator is part of this proposal.

3. Conflict resolution

For the same question:

latest explicit user-approved decision recorded in the reset or final owner
-> current owner for that document class
-> verified source/environment fact for an implementation question
-> dated evidence
-> research
-> history

This is not a universal override chain. A Product target cannot override a verified Runtime fact, and Runtime source cannot redefine Product direction. Chat memory or an unrecorded conversation is not durable authority. A newly approved correction is first recorded in the reset while it remains active, or in the final owner after reset exit. When two current owners plausibly answer the same question:

1. stop the affected integration;
2. record the exact conflicting claims and their dates/scope;
3. choose one owner or narrow both owners;
4. update both references in one change;
5. keep the conflict visible as OPEN-DECISION until approved.

Until the reset exits, its newer explicit user decision wins over conflicting legacy Product Charter or former System Design target text.

For the common Stability Gate, ownership is deliberately split:

• docs/PRODUCT.md owns canonical criteria, intended outcome and reopen rule;
• Roadmap links those criteria and alone records P10/P11/P12 conditional state and user activation;
• dated Evidence proves only the observed gate checks;
• the user owns final post-stability activation.

Roadmap must not retain a second long-term copy of Product gate criteria.

4. Proposed document classes

Class	Single question	Canonical path and naming	Audience	May own
Repository entry	Where does a human start?	README.md	all readers	navigation only
Agent entry and routing	What must an agent read and obey for this repository/surface?	AGENTS.md; .agents/rules/<UPPER_SNAKE_CASE>.md; .agents/skills/<skill>/SKILL.md	AI agents, developers	scoped execution instructions; no Product/Task status
Product North Star	What product, customer value, scope and product gates are approved?	docs/PRODUCT.md	product, engineering, operations	Product target; canonical Stability Gate criteria, outcome and reopen rule; no live activation status
Target System and Repository Design	What target decomposition, authority, module/profile/repository boundary and invariant are approved?	docs/DESIGN.md	architecture, engineering, agents	target design; no current implementation proof
Current Runtime architecture	How does the verified Runtime currently work?	.agents/rules/ARCHITECTURE.md	engineering, agents, operations	current Runtime architecture facts
Current technical contract	What current API, DB, tenant, UI or integration rule applies?	.agents/rules/<SURFACE>.md, including API_CONTRACTS.md, DB_SCHEMA.md, DB_QUERY_RULES.md, TENANT_CONFIG.md, UI_STRUCTURE.md, CONTROL_TOWER.md	engineering, agents	current scoped fact/contract only
Development and documentation standard	How are coding/document conventions, document classes, metadata, naming, lifecycle and creation/move reviews governed?	docs/DEVELOPMENT.md; reusable examples under docs/templates/	developers, document writers, agents	development/document standard; no agent startup, Git/deploy rule or Task status
Repository operation	How is approved repository/Git/external-effect/release work performed safely?	.agents/rules/PROJECT_OPERATIONS.md	developers, agents, release operators	operational execution rules
Objective=Phase Roadmap	What each Phase must accomplish and what Phase/Task is current, next, planned or conditional, in which Lane and dependency order?	docs/ROADMAP.md	product, engineering, agents	Phase schema; sole Phase/Task status, Lane, parallelism, dependency and user activation record; links to Product gate criteria rather than duplicating them
Task detail	What bounded outcome, scope, sequence, acceptance, verification and rollback completes one Task?	docs/tasks/Pn-nnn.md	Task writer/reviewer	execution detail; status by Roadmap reference only
Request Operations policy	What is a Request, how is it routed, and how is it separated from Phase Tasks and deployment authority?	docs/REQUEST_OPERATIONS.md	request submitters, operators, agents	policy and authority boundary; not a live single-file registry
Process contract	What business behavior, roles, authority, state, exception, retry and recovery must be preserved?	semantic schema at docs/processes/PROCESS_CONTRACT_STANDARD.md; actual behavior at docs/processes/<DESCRIPTIVE_NAME>_WORKFLOW.md; machine navigation at docs/processes/process-registry.yaml	operations, product, engineering, AI retrieval	Standard owns approved semantic schema; each approved workflow owns its behavior; P6-001/P6-002 are the execution route for review and integration
Operations manual/SOP	How does a named role perform and recover an operation in the product?	retain current consumer-bound docs/*_MANUAL.md, docs/*_SOP.{md,html,pdf} and docs/wiki/assets/<manual-slug>/; canonical catalogue at docs/OPERATIONS_MANUAL.md; consumer-bound role quick-start projection at docs/USER_MANUAL_INDEX.md	operators, trainers, support	approved user guidance; no Runtime or Task status
Research/benchmark	What sources, comparisons, unknowns and proposed conclusions were investigated?	docs/research/<topic>/<YYYY-MM-DD>/; exact source copies under raw/	product, engineering, reviewers	research conclusions only
Research/dated observation	What was observed, where, when, how, with what limitation and mutation?	docs/research/<topic>/<YYYY-MM-DD>/; current-state snapshots remain scoped research until disposition review	reviewers, engineering, operations	observation state for its exact scope/date only
ADR/decision	Why was one durable technical or product choice made, from which options, and what supersedes it?	docs/decisions/NNNN-<lower-kebab-slug>.md	product, architecture, engineering	the named accepted decision; not work status
Runbook/release/incident procedure	How is an explicitly authorized operational or recovery action executed, verified and rolled back?	docs/runbooks/<UPPER_SNAKE_CASE>_RUNBOOK.md; supporting manifests/examples beside the owner	operators, release/incident responders	procedure after authorization; never authorization itself
Minimum Verification Standard	What smallest changed-surface checks are required, when do they block, and how are unavailable checks reported?	D3 A: a named section under docs/DEVELOPMENT.md; D3 B: docs/VERIFICATION.md	developers, agents, reviewers	verification policy only; consumes Project Operations effect boundaries and creates no write/deploy authority

4.1 Lifecycle, related classes and consumer constraints

Class	Lifecycle	Required related classes	Consumer constraint
Repository entry	CURRENT	Product, Roadmap, current Task, agent entry	human links; remove status copies rather than create a second status owner
Agent entry/routing	CURRENT	Development, Project Operations, active Task, owning technical rule	agent startup/tool routing; change with every affected pointer
Product North Star	CURRENT TARGET	Target Design, Roadmap, approved Product ADRs	gate criteria owner; human/AI planning input; never implementation or gate-pass proof
Target System/Repository Design	CURRENT TARGET	Product, current Architecture/technical contracts, Roadmap	human/AI design input; never Runtime proof
Current Runtime architecture	CURRENT FACT	Target Design and current technical contracts	source/runtime/agent consumers; verify before changing a claimed fact
Current technical contract	CURRENT FACT/CONTRACT	Architecture, owning source/schema and affected runbook	source, script, build, agent or operator consumers by surface
Development/documentation standard	CURRENT STANDARD	Product, Target Design, Project Operations, agent routing	human/AI writing and coding; does not replace effect authorization
Repository operation	CURRENT INSTRUCTION	AGENTS, active Task, release/incident runbooks	Git/external-effect/operator use; a runbook cannot self-authorize
Roadmap	CURRENT STATUS	Product and every Task detail	committed remote file alone owns live status/activation; links may point here but Local summaries do not copy or imply status
Task detail	PLANNED / ACTIVE / COMPLETE by Roadmap	Product, Roadmap and scoped owners/evidence	execution/review input; cannot create Product/Phase authority
Request policy	CURRENT POLICY after approval	Product, Roadmap, Control Tower boundary, incident policy	no Runtime/storage consumer before P3 approves one
Process contract	DRAFT / REVIEWED / APPROVED / DEPRECATED	Product, technical contracts, manuals and evidence	Standard owns approved schema, each workflow owns behavior/lifecycle, dated Evidence owns promotion proof; P6-001/P6-002 route review/integration
Manual/SOP	DRAFT / APPROVED / DEPRECATED	approved process, current UI/access contract and evidence	PHP/in-app/operator/external path consumers; same-change migration
Research/benchmark	RESEARCH-INPUT	downstream Product/System/Roadmap/Task owner	citations and human review only; historical status is inert
Evidence/dated observation	OBSERVED-FACT	tested owner/Task/process/decision	immutable artifact consumers; exact scope/date/environment only
ADR/decision	PROPOSED / ACCEPTED / SUPERSEDED / REJECTED	affected Product/System/technical owner and evidence	durable rationale; no execution or implementation status
Runbook	DRAFT / CURRENT / SUPERSEDED	owning technical/operational contract and evidence	operator/script/path-pinned consumers; use only after authorization
Minimum Verification Standard	CURRENT STANDARD after user approval and P1-004 integration	Development, Project Operations, changed surface and evidence	policy cannot grant external writes, install tools or become a deployment Gate
Local review artifact	LOCAL PROPOSAL	remote source basis, current Task and proposed downstream owner	no current authority/status/evidence; reconcile or delete after committed owner absorption

History is normally Git history. A current-tree compatibility pointer uses the HISTORY lifecycle only when a proven consumer or unique navigation need requires it and names its successor/removal condition.

4.2 Path choice

The approved hierarchy creates four final current owners:

• docs/PRODUCT.md, absorbing valid Product Charter and Reset content;
• docs/DESIGN.md, absorbing valid System Design and approved target content;
• docs/DEVELOPMENT.md, rewritten from valid recovered governance content;
• docs/REQUEST_OPERATIONS.md, limited to the approved Request/Task boundary while P3 keeps storage and implementation decisions open. The overlapping Request sections in .agents/rules/CONTROL_TOWER.md are then narrowed to the CTC/Control Tower Runtime and control-plane boundary.

D3 chooses whether the Minimum Verification Standard is a named section in docs/DEVELOPMENT.md (recommended, no third owner) or a separate docs/VERIFICATION.md. After user approval of the policy decisions, P1-004 is the execution route that integrates them and may implement a separately approved small script.

No BENCHMARK.md, catalog/, generated/ or archive/ hierarchy is added. The existing docs/templates/ files are reused as optional examples after their stale Track/register fields are corrected; no template generator is added. P1-003 benchmark output should integrate into Product, Design, Roadmap and retained dated research instead of becoming a second product owner.

5. Shared metadata

Every human-readable current owner uses the smallest applicable header:

Status:
Owns:
Does not own:
Update when:
Related sources:

Add only when applicable:

Decision/approval:
Verified source/environment/date:
Runtime/script/operator consumers:
Supersedes:
Retention/removal condition:

Research and evidence use:

Classification: RESEARCH-INPUT | OBSERVED-FACT
Captured:
Source/revision:
Environment/tenant/role:
Method:
Limitations:
Mutation summary:
Retention/removal condition:

A Local proposal additionally declares LOCAL UNCOMMITTED REVIEW ARTIFACT, names its remote source basis, and states that it is not current authority, Roadmap status, completion or committed evidence.

Machine-readable files keep required metadata in their schema or a directly linked owning standard. Binary evidence uses a nearby README or evidence record; the binary itself is not duplicated to carry metadata.

6. Class templates

docs/DEVELOPMENT.md owns the requirements below. Existing files under docs/templates/ are optional copyable examples, not authority and not generated output. Reuse the current/target/decision/evidence/manual/runbook examples. The valid former plan.md fields were absorbed into task.md. After absorption and caller-zero verification, Stage 6 approval deleted the obsolete plan.md. Existing owners migrate when materially edited or during their assigned integration wave.

Repository entry, agent routing and repository operation do not need separate copy templates: their current files are the minimal examples. Development standard changes use the shared metadata plus explicit class/creation/lifecycle sections. Process contracts continue to use docs/processes/PROCESS_CONTRACT_STANDARD.md.

Product

Purpose and target customers
Value and product model
Scope and non-goals
Profiles/modules/configuration
First product slice and reference-profile regression boundary
Product gates, including Stability Gate, and success measures
Deferred commitments
Open decisions

Target/current technical owner

Purpose and question owned
Current fact vs target (when both are needed)
Authority and invariants
Dependencies and consumers
Compatibility/migration boundary
Unknowns and deferred commitments
Update evidence

Roadmap

North Star
Current/startable work
Phase objective and necessity
Baseline and unknown
Target outcome
In scope / out of scope / must preserve
Entry and completion condition
Benchmark input and deferred feature
Task registry
Cloud / Local / Field Lane
Parallelism / dependency / final-writer boundary
Review note
Task status/Lane/parallel/dependency/detail link
Activation and completion rule
Roadmap change rule

Task

Outcome and product value
Status source, Phase, Lane, parallelism and dependencies
Canonical inputs
In scope / out of scope / must preserve
Execution stages and deliverables
Acceptance and verification
Stop conditions and rollback
Evidence, handoff and completion review

Request Operations policy

Request definition and classes
Authority matrix
Intake/routing/dedup/status semantics
Task and incident relationship
Privacy/audit/retention boundary
Channel and storage decisions
Explicitly forbidden automation
Open decisions

Process contract

P1 preserves the current path, consumers, stable IDs and only the document class, metadata and lifecycle fields. It may remove stale Track/packet status routing. P6-001/P6-002 review, propose and integrate the user-approved semantic schema into PROCESS_CONTRACT_STANDARD; each approved workflow owns its actual roles, authority, trigger/completion, state, exception, retry, recovery, tenant variation, verification and AI boundary. Those approved owners are inputs to P5-002/P5-003 manifest/handler templates.

Manual/SOP

Audience, role and prerequisite access
Menu entry and purpose
Inputs and visible completion
Steps and decisions
Errors, retry, correction and recovery
Related approved process contract
Last field/runtime verification and limitations

Research/benchmark

Question and scope
Sources with date/environment
Method
Observed facts
Comparisons/findings
Unknowns and limitations
Proposals separated from facts
Downstream owner and retention

Evidence

Claim tested
Revision/environment/tenant/role/date
Prerequisites and method
Observed result
PASS/FAIL/BLOCKED/NOT_RUN/NOT_APPLICABLE
Mutations, cleanup and residue
Limitations and files/artifacts

ADR

Status/date/owner
Context and decision drivers
Options
Decision
Consequences and rollback/supersession
Implementation/evidence links

Runbook

Purpose and authorization boundary
Target/prerequisites
Steps
Readback and success criteria
Failure/stop conditions
Rollback/cleanup
Evidence and escalation

Minimum Verification Standard

Scope and failure mode
Selected check and what it proves
Prerequisite and existing tool
Blocking or advisory
Execution timing
Override decision and record
PASS / FAIL / BLOCKED / NOT_RUN / NOT_APPLICABLE
External-effect boundary from Project Operations
Adjustment or removal condition

After user approval, P1-004 may implement only a small script for unresolved merge markers and syntax checks for changed source supported by existing repository tools. It does not authorize new tool installation or deployment integration.

7. Lifecycle, review and deletion

Class	Update trigger	Review cadence	Retention/deletion
Repository entry	approved entry path or primary owner changes	each Phase review that changes current navigation	keep one root entry; remove stale status copy/link after successor routing works
Repository operation	repository write, Git, external-effect, promotion or deployment rule changes	before affected operational use and after release/incident learning	keep while current; replace only with a verified successor and updated agent/runbook links
Product/System/Development	approved direction or boundary change	each relevant Phase review	keep while current; supersede in place
Current technical owner	verified source/Runtime contract change	with affected implementation	keep while current; remove only after replacement and caller-zero
Roadmap	status, dependency, Lane or approved Phase/Task change	every Task completion/activation	keep one current Roadmap
Task	scope/acceptance change or execution evidence	during Task and completion review	keep completed Task detail while it provides unique decision/evidence links
Request policy	approved authority/lifecycle/channel change	P3 and later policy review	keep policy; operational records follow their approved store retention
Process	workflow/state/role/recovery change	lifecycle promotion and affected release	deprecate with successor; preserve stable IDs
Manual/SOP	UI/process/access/recovery change	affected release plus field review	delete only after replacement, consumer migration and caller-zero
Research	new investigation or correction	downstream Task review	retain unique detail/provenance; delete wrapper after absorption
Evidence	verification event	immutable except correction note	retain per owning decision/process/release need
ADR	durable decision	when superseded	retain accepted/superseded ADR; never reuse ID
Runbook	operation/tool/target/rollback change	before authorized use and after incident/release learning	replace only with verified successor
Agent instruction	routing/surface rule change	affected repository change	remove only after references and behavior are migrated
Minimum Verification Standard	approved failure mode, timing, override or supported-tool change	P1-004 review and after false-positive/operational learning	adjust or remove a check when it no longer proves the named failure mode
Local review artifact	remote basis or proposal content changes	each user review and before handoff	reconcile into committed owner or delete after absorption; never retain as a status copy

Document lifecycle, process maturity, Product outcome, Stability Gate proof and Phase/Task status are independent. None may be used as evidence for another.

8. Stage 2 source-disposition packet

8.1 Exact-path rule

The approval set covers current tracked paths without creating a catalog:

1. The exact 113-path preliminary table remains available in preliminary-document-recovery-disposition-original.md. Its RESTORE, ABSORB, KEEP_RESEARCH and DELETE rows mean only KEEP, ABSORB_CANDIDATE, KEEP_RESEARCH and DELETE_CANDIDATE.
2. The committed remote tree at qa@508eb0be8e80e2d8267fc1f6c1195fd838258a18 is the exact authority manifest. Every tracked document path not named in that preliminary table or the conflict table below defaults to KEEP_PENDING_REVIEW.
3. The current exact paths with already-proven authority or freshness conflicts use the proposed action below.
4. Untracked, deployed, operator-owned and external path-pinned files remain UNKNOWN_EXTERNAL until Local/operator evidence exists.
5. The separate Local uncommitted artifact set is not part of that remote manifest and cannot establish current authority, Roadmap status or completion.

This rule identified every tracked file in the Stage 1 source basis while avoiding a second generated index. It authorized no final deletion. Stage 4 later re-read each material source and replaced the candidate with KEEP, ABSORB, REWRITE, MOVE_WITH_CONSUMER, KEEP_RESEARCH or DELETE.

8.2 Stage 1 exact-path and bounded-family conflicts

Current path	Proposed action after approval	Target/reason
README.md, AGENTS.md, .agents/rules/PROJECT_OPERATIONS.md	KEEP + REWRITE	link to committed Roadmap status; remove copied live status; do not claim the full Phase schema exists until Roadmap integration proves it
docs/tasks/P1-001.md	KEEP + REWRITE	align detailed contract with Revision 10 Objective=Phase schema and status-reference rule
docs/ROADMAP.md	KEEP + NARROW after owner integration	retain Revision 10 dynamic status and corrected dependencies; resolve the undefined Phase ACTIVE status; replace duplicated long-term Stability criteria with the Product owner link while retaining conditional/user activation state
docs/product/PRODUCT_CHARTER.md	ABSORB -> DELETE	valid Product content moved to docs/PRODUCT.md; active links migrated, caller-zero verified and old path removed
docs/reference/modernization-v1/MASTER_PLAN.md	KEEP_RESEARCH	current authority retired; exact historical path retained with a correction header while archive decisions/phases/evidence still reference it
.agents/rules/SYSTEM_DESIGN.md	ABSORB -> DELETE	valid target design moved to docs/DESIGN.md; current facts routed to Architecture/technical evidence; active links migrated and old path removed
.agents/rules/REACT_API_CLIENT.md	REWRITE as conditional proposal/history	React scaffold does not exist and React remains TBD; it cannot be a current source of truth
.agents/rules/API_CONTRACTS.md	KEEP + REWRITE	keep verified API v2 current contract; remove React adoption implication and stale plan routing
.agents/rules/INTEGRATION_PLAN.md	ABSORB -> DELETE	target/current/migration detail routed to Design, Architecture, API contracts/inventory and Roadmap; obsolete execution owner removed
.agents/rules/API_V2_CONTRACT_INVENTORY.md	REWRITE as dated current-fact/evidence input	reconcile stale execution order and conflicting legacy-shell counts before reuse
.agents/rules/AGENT_WORKFLOW.md	KEEP + NARROW	short router to Development, Project Operations and surface rules; add an AGENTS/README navigation path because no current inbound link exists
.agents/rules/CONTROL_TOWER.md	KEEP + NARROW	retain CTC/control-plane Runtime boundary; absorb Request policy into the approved Request owner
recovered docs/DEVELOPMENT.md source	REWRITE into docs/DEVELOPMENT.md	retain valid class/creation/template rules; reject old IDs, single Request registry, packet and fixed Harness
docs/templates/*.md	KEEP + REWRITE; former plan.md DELETE	reuse optional examples; valid fields were absorbed into task.md; caller-zero plan.md was deleted after Stage 6 approval; no PLAN class or generator
docs/OPERATIONS_MANUAL.md	KEEP as canonical manual catalogue	owns manual/SOP routing and operator knowledge entry; dated Local/DB appendix is an evidence-separation candidate but cannot move before exact range/signature consumer migration
docs/USER_MANUAL_INDEX.md	KEEP + NARROW as role quick-start projection	Runtime-consumed projection; does not independently own the catalogue
docs/processes/PROCESS_CONTRACT_STANDARD.md	KEEP + NARROW in P1	remove stale Track/packet status routing only; P6-001/P6-002 route the user-approved semantic rewrite into this owner before P5 templates
docs/processes/process-registry.yaml and current workflow files	KEEP	Runtime/script consumed; lifecycle/content review remains source-by-source
docs/decisions/0002-transition-audit-store.md	KEEP + REWRITE	preserve accepted decision; update the stale pre-implementation note against current source/DB owner evidence
docs/runbooks/API_V2_CUTOVER_VALIDATION_RUNBOOK.md	REWRITE or KEEP_RESEARCH	retired Feature/Issue workflow cannot remain a current execution condition
other docs/runbooks/**	KEEP_PENDING_REVIEW	classify current runbook vs manifest/example and verify operator/script consumers
docs/performance/CTC_PERFORMANCE_OPTIMIZATION_{EXECUTION_PLAN,STATUS}.md	KEEP + REWRITE/KEEP_RESEARCH	preserve P9 input; remove stale evolution-register authority
docs/reference/modernization-v1/**	KEEP_RESEARCH pending absorption and consumer review	historical detail is useful, but current phase/status claims are invalid
docs/research/**	KEEP_RESEARCH	preserve unique detail and provenance until downstream mapping
scoped docs/research/**, docs/current-state/**	KEEP as dated observation	never promote old IDs/status/next steps to current authority
reset document	ABSORB, then DELETE only at reset exit	temporary decision source
deleted evolution/Track/packet/register/catalog/generated status/fixed-Harness paths	DELETE_CANDIDATE	remain absent unless unique unabsorbed content or a proven consumer requires recovery

2026-07-31 user correction: the reset-document row above preserves the decision-time proposal but is superseded. The renamed durable Context remains throughout the project; P1 or individual Phase completion is not a deletion condition.

9. Exact consumer boundary

The in-app manual is a Runtime feature, not inert documentation:

• route/include chain: config/page_routes.php -> config/config.php -> index.php -> frontend/pages/platform/help/operations-manual.php;
• access/navigation consumers: config/modules.php, config/config.php and frontend/partials/_navbar.php;
• embedded JSON consumer: frontend/pages/system/TMS/transload/inbound-planning.php requests /operations-manual?manual_data=1&doc=inbound-planning;
• content/registry consumer: frontend/pages/platform/help/operations-manual-content.php reads docs/processes/process-registry.yaml and selected Markdown/HTML sources;
• exact manual/workflow source baseline: the preliminary disposition's manual rows plus current operations-manual.php source/range/signature declarations;
• direct HTTP/assets: source links and relative images resolve through /docs/...; a document or asset move must update both filesystem and rendered URL behavior. Preserve the nine hard-coded docs/wiki/assets/mk-client2-e2e/manual-demo/*.png paths referenced by frontend/pages/platform/help/operations-manual.php until the same-change consumer migration;
• verifier: scripts/verify_operations_manual_sources.php checks both tenant catalogues, registry closure, declared sources, anchors, signatures and docs/reference/modernization-v1/deep-analysis/10-ctc-mk-process-manual-traceability.md;
• build: scripts/tailwind-runtime/blocklist-baseline.json, scripts/tailwind-runtime/verify-blocklist-baseline.cjs, scripts/tailwind-runtime/package.json and scripts/tailwind-runtime/tailwind.config.cjs pin or scan the page/source surface;
• agent/field: .agents/skills/ctc-field-process-testing/SKILL.md requires docs/CTC_USER_PROCESS_SYSTEM_TEST_RUNBOOK.md;
• API catalogue metadata: app/platform/api_catalog.php contains literal path references to docs/PRODUCTION_ENVIRONMENT.md and docs/QUICKBOOKS_TIME_PRODUCTION_SETUP.md. Current source review found no content read and no UI use of its docs field, so this is a path pin, not proven rendered-content consumption.

Before moving or deleting any named source:

1. enumerate its current PHP/script/build/operator/external callers;
2. migrate the source, range/signature, URL/asset and caller in one rollback unit;
3. run php scripts/verify_operations_manual_sources.php --client-id=1 and --client-id=2;
4. verify the affected rendered catalogue/embedded consumer and build check;
5. establish caller-zero for the old path;
6. keep the path when deployed or external consumers remain unknown.

These checks are future move/delete prerequisites. Browser, deployed Runtime, external automation and Production were not run for this draft.

10. Open-decision routing

The reset's open decisions are not silently decided here:

Open decision	Owner
final hierarchy/path/template and retention rules	D1-D12 below, then docs/DEVELOPMENT.md
final repository target structure	P1-002, then docs/DESIGN.md / docs/DEVELOPMENT.md
first commercial vertical, accounting scope, compliance timing, SaaS topology, hardware priority, package/pricing/support model	P1-003 inputs, then assigned Product/Roadmap Tasks
Request storage/owner, Control Tower boundary and CTC-only Orca role	P3
Minimum Verification Standard blocking/advisory, timing, override and supported tool range	user decision through P1-004, then approved Development/Verification owner
process ownership/state/exception/retry/recovery semantics, then module/handler templates	semantic schema/workflow owners via P6-001/P6-002 -> P5-002/P5-003; P1 preserves paths and consumers only
process/manual/evidence/research application	lifecycle decision below; broad application in P8
PostgreSQL entry gate	P11
React decision gate	P12; current decision remains TBD

Scale-first MK delivery, CTC reference regression, process-before-template, P9's stable-repeatable-product meaning and the common Stability Gate are already USER-APPROVED in Reset Revision 11. They are integration inputs for Product/System/Roadmap owners, not new D1-D12 choices.

11. Decisions received

ID	Options and impact	Selected
D1 — classes/authority	A: approve the full Objective=Phase schema, Product gate/Roadmap activation/Evidence split, process Standard/workflow semantic owners and class table; B: revise named classes before owner construction	A
D2 — core paths	A: reuse current Product/System paths; B: make docs/PRODUCT.md/docs/DESIGN.md canonical and perform consumer-safe migration	B
D3 — Development and verification owner	A: create narrow docs/DEVELOPMENT.md and place Minimum Verification Standard in a named section; B: create docs/DEVELOPMENT.md plus docs/VERIFICATION.md; C: leave rules distributed or make an agent rule the human standard	A
D4 — Request policy	A: create policy-only docs/REQUEST_OPERATIONS.md and narrow Control Tower; B: keep policy in Control Tower, coupling product requests to a control-plane rule; C: defer the owner to P3, leaving P1 hierarchy incomplete	A
D5 — documentation examples	A: reuse docs/templates/ only for document examples, absorb valid plan.md fields into task.md, then classify plan.md as DELETE_CANDIDATE only after verified absorption/link/caller-zero; B: absorb examples into Development and make the folder a later cleanup candidate; C: generated templates/validator	A; Stage 6 later approved and completed the exact plan.md deletion; no PLAN class or process/module/handler semantic template is approved
D6 — manuals	A: keep exact paths, make OPERATIONS_MANUAL canonical and USER_MANUAL_INDEX a Runtime projection, defer folder move to P8; B: move now, requiring coordinated PHP/build/asset/operator migration	A; manuals cannot define process semantics before P6 approval
D7 — document lifecycle/retention	A: approve sections 4.1 and 7 including Local proposal lifecycle; B: name class-specific changes before integration	A; no process maturity, field acceptance, Product outcome or Phase status implication
D8 — benchmark owner	A: keep dated benchmark research and integrate structural inputs into Product/System/Roadmap; B: add a current BENCHMARK.md, creating another product-priority surface	A; features still require Stability Gate and P10/user activation
D9 — live status copies	A: committed remote Roadmap links only in entry/rule/Task files; B: allow cached summaries, requiring manual synchronization	A; Local uncommitted work implies no status
D10 — React/API documents	A: reclassify the future React client, retain React-independent API v2 current facts, absorb stale Track plans; B: keep current source-of-truth claims despite React=TBD	A; no React authority before P7-006, Stability Gate and user activation
D11 — stale current-tree claims	A: apply the Revision 10-revalidated exact-path actions in section 8.2 source-by-source; B: keep old packet/register/Issue/current-status claims	A; P1 removes stale routing, P6 routes user-approved semantics into their durable owners
D12 — disposition protocol	A: approve the 113-path preliminary baseline + Revision 10 remote manifest + separate Local artifact set + default KEEP_PENDING_REVIEW; B: require a duplicated catalog	A; final action required Stage 4 review, which later completed before the approved Stage 6 cleanup

At that decision point, the recorded decisions authorized only canonical owner construction and source-by-source integration review. They did not approve a final file move, deletion, Runtime/browser/DB/provider effect, commit, push, promotion or deployment. They also did not approve Stability pass/activation, P1-004 policy or script, P5/P6 semantic template activation, Roadmap status change, or a Local commit/handoff inference.

---

Source: docs/research/platform-foundation/2026-07-30/canonical-document-hierarchy-draft.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.