docs: complete canon alignment housekeeping

2026-08-18 18:12:32 +02:00 · 2026-08-18 18:12:32 +02:00 · debbc13b40
commit debbc13b40
parent 490c2d97b1
14 changed files with 397 additions and 81 deletions
--- a/README.md
+++ b/README.md
@ -6,6 +6,10 @@ This repository defines how Railiance concepts map to repositories, how the
 different repo families compose, and where new architecture decisions should be
 recorded before they are spread across implementation repos.

+- [Intent and direction](INTENT.md)
+- [Current scope and authority boundaries](SCOPE.md)
+- [Reviewed architecture-demand intake](demand/README.md)
+
 ## Current Architecture Baseline

 - [docs/repository-axes.md](docs/repository-axes.md)
--- a/SCOPE.md
+++ b/SCOPE.md
@ -119,10 +119,12 @@ publication addressing are completed.

 ## InfoTechCanon Repository-Layout Alignment

-Declared conformance: **`minimal`** under ITC-REPO-LAYOUT 0.1.0-RC1.
+Declared conformance: **`core`** under ITC-REPO-LAYOUT 0.1.0-RC1.

 - `INTENT.md` contains stable aspiration and boundaries.
 - `SCOPE.md` contains current evidenced responsibility and explicit gaps.
+- `demand/` holds unreviewed architecture demand and requires a purpose/scope
+  disposition before work is committed.
 - `docs/` contains stakeholder-facing framework contracts and ADRs.
 - `workplans/` contains committed work and remains authoritative for State Hub.
 - `history/` contains dated, inactive architecture explorations.
@ -132,11 +134,12 @@ Intentional deviations and omissions:
 - Finished workplan archival follows the Custodian ADR-001 convention at
  `workplans/archived/YYMMDD-...`, not the generic ITC `history/` placement, so
  State Hub discovery remains deterministic.
- `demand/`, `research/`, `spec/`, `wiki/`, and `issues/` are not currently
-  claimed. They should be added only when their distinct semantics are needed,
-  not as empty structural decoration.
+- `research/`, `spec/`, `wiki/`, and `issues/` are not currently claimed. They
+  should be added only when their distinct semantics are needed, not as empty
+  structural decoration.
 - Consumer purposes and inbound requests are not folded into INTENT or SCOPE;
-  a future demand intake may provide that third plane explicitly.
+  `demand/` provides that third plane and resolved reviews move to dated
+  `history/` records.

 ---

@ -191,6 +194,6 @@ keywords: [schema, validation, declaration, rail, rapp, reef]

 ## Gap to Intent

-The next obvious alignment work is to make accepted ADRs publication-ready,
-formalize how raw architecture demand is reviewed before it becomes a workplan,
-and cleanly archive completed work without breaking State Hub conventions.
+The remaining alignment work is to complete downstream ADR publication, cleanly
+archive completed work without breaking State Hub conventions, and retain a
+repeatable canon-consumer review packet as the architecture evolves.
--- a/WORK-RECORDS.md
+++ b/WORK-RECORDS.md
@ -8,39 +8,8 @@

 | Kind | ID | Status | Lane | Source |
 | --- | --- | --- | --- | --- |
-| workplan | ADHOC-2026-07-30 | finished | — | workplans/ADHOC-2026-07-30.md |
-| workplan | RMASTER-WP-0017 | finished | — | workplans/RMASTER-WP-0017-rail-rapp-reef-repo-separation.md |
-| workplan | RMASTER-WP-0018 | finished | — | workplans/RMASTER-WP-0018-first-wave-repo-family-materialization.md |
-| workplan | RMASTER-WP-0019 | finished | — | workplans/RMASTER-WP-0019-knative-qonto-runtime-on-reef-railiance.md |
 | workplan | RMASTER-WP-0020 | blocked | — | workplans/RMASTER-WP-0020-openbao-migration-to-reef-railiance.md |
-| workplan | RMASTER-WP-0021 | finished | — | workplans/RMASTER-WP-0021-rapp-declaration-schema.md |
-| workplan | RMASTER-WP-0022 | finished | — | workplans/RMASTER-WP-0022-establish-reef-storage.md |
-| workplan | RMASTER-WP-0023 | finished | — | workplans/RMASTER-WP-0023-private-by-default-exposure.md |
-| workplan | RMASTER-WP-0024 | active | — | workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md |
-| task | ADHOC-2026-07-30-T01 | done | — | workplans/ADHOC-2026-07-30.md |
-| task | RMASTER-WP-0017-T01 | done | — | workplans/RMASTER-WP-0017-rail-rapp-reef-repo-separation.md |
-| task | RMASTER-WP-0017-T02 | done | — | workplans/RMASTER-WP-0017-rail-rapp-reef-repo-separation.md |
-| task | RMASTER-WP-0017-T03 | done | — | workplans/RMASTER-WP-0017-rail-rapp-reef-repo-separation.md |
-| task | RMASTER-WP-0017-T04 | done | — | workplans/RMASTER-WP-0017-rail-rapp-reef-repo-separation.md |
-| task | RMASTER-WP-0017-T05 | done | — | workplans/RMASTER-WP-0017-rail-rapp-reef-repo-separation.md |
-| task | RMASTER-WP-0017-T06 | done | — | workplans/RMASTER-WP-0017-rail-rapp-reef-repo-separation.md |
-| task | RMASTER-WP-0017-T07 | done | — | workplans/RMASTER-WP-0017-rail-rapp-reef-repo-separation.md |
-| task | RMASTER-WP-0018-T01 | done | — | workplans/RMASTER-WP-0018-first-wave-repo-family-materialization.md |
-| task | RMASTER-WP-0018-T02 | done | — | workplans/RMASTER-WP-0018-first-wave-repo-family-materialization.md |
-| task | RMASTER-WP-0018-T03 | done | — | workplans/RMASTER-WP-0018-first-wave-repo-family-materialization.md |
-| task | RMASTER-WP-0018-T04 | done | — | workplans/RMASTER-WP-0018-first-wave-repo-family-materialization.md |
-| task | RMASTER-WP-0018-T05 | done | — | workplans/RMASTER-WP-0018-first-wave-repo-family-materialization.md |
-| task | RMASTER-WP-0018-T06 | done | — | workplans/RMASTER-WP-0018-first-wave-repo-family-materialization.md |
-| task | RMASTER-WP-0019-T01 | done | — | workplans/RMASTER-WP-0019-knative-qonto-runtime-on-reef-railiance.md |
-| task | RMASTER-WP-0019-T02 | done | — | workplans/RMASTER-WP-0019-knative-qonto-runtime-on-reef-railiance.md |
-| task | RMASTER-WP-0019-T03 | done | — | workplans/RMASTER-WP-0019-knative-qonto-runtime-on-reef-railiance.md |
-| task | RMASTER-WP-0019-T04 | done | — | workplans/RMASTER-WP-0019-knative-qonto-runtime-on-reef-railiance.md |
-| task | RMASTER-WP-0019-T05 | done | — | workplans/RMASTER-WP-0019-knative-qonto-runtime-on-reef-railiance.md |
-| task | RMASTER-WP-0019-T06 | done | — | workplans/RMASTER-WP-0019-knative-qonto-runtime-on-reef-railiance.md |
-| task | RMASTER-WP-0019-T07 | done | — | workplans/RMASTER-WP-0019-knative-qonto-runtime-on-reef-railiance.md |
-| task | RMASTER-WP-0019-T08 | done | — | workplans/RMASTER-WP-0019-knative-qonto-runtime-on-reef-railiance.md |
-| task | RMASTER-WP-0019-T09 | done | — | workplans/RMASTER-WP-0019-knative-qonto-runtime-on-reef-railiance.md |
-| task | RMASTER-WP-0019-T10 | done | — | workplans/RMASTER-WP-0019-knative-qonto-runtime-on-reef-railiance.md |
+| workplan | RMASTER-WP-0024 | blocked | — | workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md |
 | task | RMASTER-WP-0020-T01 | done | — | workplans/RMASTER-WP-0020-openbao-migration-to-reef-railiance.md |
 | task | RMASTER-WP-0020-T02 | done | — | workplans/RMASTER-WP-0020-openbao-migration-to-reef-railiance.md |
 | task | RMASTER-WP-0020-T03 | done | — | workplans/RMASTER-WP-0020-openbao-migration-to-reef-railiance.md |
@ -50,25 +19,8 @@
 | task | RMASTER-WP-0020-T07 | done | — | workplans/RMASTER-WP-0020-openbao-migration-to-reef-railiance.md |
 | task | RMASTER-WP-0020-T08 | wait | — | workplans/RMASTER-WP-0020-openbao-migration-to-reef-railiance.md |
 | task | RMASTER-WP-0020-T09 | progress | — | workplans/RMASTER-WP-0020-openbao-migration-to-reef-railiance.md |
-| task | RMASTER-WP-0021-T01 | done | — | workplans/RMASTER-WP-0021-rapp-declaration-schema.md |
-| task | RMASTER-WP-0021-T02 | done | — | workplans/RMASTER-WP-0021-rapp-declaration-schema.md |
-| task | RMASTER-WP-0021-T03 | done | — | workplans/RMASTER-WP-0021-rapp-declaration-schema.md |
-| task | RMASTER-WP-0021-T04 | done | — | workplans/RMASTER-WP-0021-rapp-declaration-schema.md |
-| task | RMASTER-WP-0021-T05 | done | — | workplans/RMASTER-WP-0021-rapp-declaration-schema.md |
-| task | RMASTER-WP-0021-T06 | done | — | workplans/RMASTER-WP-0021-rapp-declaration-schema.md |
-| task | RMASTER-WP-0021-T07 | done | — | workplans/RMASTER-WP-0021-rapp-declaration-schema.md |
-| task | RMASTER-WP-0021-T08 | done | — | workplans/RMASTER-WP-0021-rapp-declaration-schema.md |
-| task | RMASTER-WP-0021-T09 | done | — | workplans/RMASTER-WP-0021-rapp-declaration-schema.md |
-| task | RMASTER-WP-0022-T01 | done | — | workplans/RMASTER-WP-0022-establish-reef-storage.md |
-| task | RMASTER-WP-0022-T02 | done | — | workplans/RMASTER-WP-0022-establish-reef-storage.md |
-| task | RMASTER-WP-0022-T03 | done | — | workplans/RMASTER-WP-0022-establish-reef-storage.md |
-| task | RMASTER-WP-0023-T01 | done | — | workplans/RMASTER-WP-0023-private-by-default-exposure.md |
-| task | RMASTER-WP-0023-T02 | done | — | workplans/RMASTER-WP-0023-private-by-default-exposure.md |
-| task | RMASTER-WP-0023-T03 | done | — | workplans/RMASTER-WP-0023-private-by-default-exposure.md |
-| task | RMASTER-WP-0023-T04 | done | — | workplans/RMASTER-WP-0023-private-by-default-exposure.md |
-| task | RMASTER-WP-0023-T05 | done | — | workplans/RMASTER-WP-0023-private-by-default-exposure.md |
 | task | RMASTER-WP-0024-T01 | done | — | workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md |
-| task | RMASTER-WP-0024-T02 | progress | — | workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md |
-| task | RMASTER-WP-0024-T03 | todo | — | workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md |
-| task | RMASTER-WP-0024-T04 | todo | — | workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md |
-| task | RMASTER-WP-0024-T05 | todo | — | workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md |
+| task | RMASTER-WP-0024-T02 | wait | — | workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md |
+| task | RMASTER-WP-0024-T03 | done | — | workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md |
+| task | RMASTER-WP-0024-T04 | done | — | workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md |
+| task | RMASTER-WP-0024-T05 | done | — | workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md |
--- a/demand/README.md
+++ b/demand/README.md
@ -0,0 +1,64 @@
+# Architecture Demand Intake
+
+This directory is the unreviewed intake surface for proposed changes to the
+Railiance framework architecture. It implements the InfoTechCanon distinction
+between a `DemandSignal` and committed work:
+
+- a file here records a request, opportunity, conflict, or observed scope
+  pressure;
+- it is not a task and carries no implementation commitment;
+- review compares it with `INTENT.md`, current `SCOPE.md`, existing ADRs, and
+  the purpose of the requesting consumer;
+- only an accepted disposition may create or amend a workplan;
+- resolved demand leaves this directory and moves to `history/` with its review
+  trail intact.
+
+State Hub messages are coordination transport, not this directory's source of
+truth. Capture a message here only when it presents genuine architecture demand
+that needs review. Do not mirror the inbox wholesale.
+
+## File convention
+
+Pending demand uses `YYYY-MM-DD-NNN-<slug>.md` and this minimum shape:
+
+```yaml
+---
+id: RMASTER-DEMAND-YYYY-MM-DD-NNN
+type: demand-signal
+status: unreviewed
+received: "YYYY-MM-DD"
+source: "operator | agent/repo | discovery"
+consumer: "who needs the outcome"
+---
+```
+
+Each record answers:
+
+1. What is being requested or observed?
+2. What consumer purpose would it serve?
+3. How does it fit the producer intent?
+4. Does it expose a current-scope defect, future-scope pressure, or work that
+   belongs elsewhere?
+5. What evidence supports it?
+
+## Review dispositions
+
+- `accepted` — create or link the repo-local workplan, then archive the demand
+  record as `history/YYMMDD-demand-<slug>.md`.
+- `routed` — name the owning repository and durable handoff evidence, then
+  archive the record.
+- `deferred` — state the trigger or missing evidence; keep the record here only
+  while it remains genuinely unreviewed, otherwise archive it.
+- `rejected` — record why it conflicts with intent, scope, or an accepted
+  decision, then archive it.
+
+Review changes the demand record's status and adds reviewer, review date,
+purpose fit, scope pressure, disposition rationale, and resulting work ID. Raw
+demand must never move directly into task status without that trail.
+
+## Worked example
+
+The first completed intake is
+[`history/260818-demand-canon-policy-alignment.md`](../history/260818-demand-canon-policy-alignment.md).
+It records the operator request that became `RMASTER-WP-0024` and demonstrates
+the full signal → review → workplan → history path.
--- a/docs/evidence/infotech-canon-alignment-review-2026-08-18.yaml
+++ b/docs/evidence/infotech-canon-alignment-review-2026-08-18.yaml
@ -0,0 +1,186 @@
+id: rmaster-itc-alignment-2026-08-18
+title: Railiance Master InfoTechCanon Alignment Review
+repository:
+  slug: railiance-master
+  path_or_url: https://forgejo.coulomb.social/coulomb/railiance-master
+  branch: main
+reviewer:
+  name: codex
+  reviewed_at: "2026-08-18"
+  method: InfoTechCanon consumer alignment review kit at revision 1695d62bdcca118bd6ae208c166c1ac0de66f8e3
+review_mode: full-alignment-review
+
+repository_context:
+  producer_intent:
+    - Own the Railiance-specific framework architecture and repository-family vocabulary.
+    - Keep ownership, execution contract, managed workload package, and substrate axes separate and composable.
+    - Author and govern framework ADRs while delegating permanent publication downstream without writeback.
+  current_scope:
+    - Eight accepted framework ADRs and stakeholder-facing architecture contracts.
+    - Rail, rapp, and reef declaration schemas plus cross-family validation tooling.
+    - Cross-repo architecture workplans whose implementation is routed to concrete ownership repositories.
+    - Reviewed architecture-demand intake and dated resolution history.
+  consumer_purposes:
+    - Give Railiance repositories one stable meaning for rail, rapp, reef, ownership, admission, and exposure.
+    - Give maintainers an evidence-linked path from demand through decision to repo-local implementation.
+    - Give policy-nexus authoritative source records that can be published without becoming a second source of truth.
+    - Give humans and agents predictable orientation and retrieval surfaces.
+  evidence_inventory:
+    - source: INTENT.md
+      role: Producer intent and stable architecture direction.
+    - source: SCOPE.md
+      role: Current responsibility, exclusions, conformance, and gap declaration.
+    - source: demand/README.md
+      role: Unreviewed DemandSignal intake and disposition contract.
+    - source: history/260818-demand-canon-policy-alignment.md
+      role: Worked demand-review evidence linking an operator request to RMASTER-WP-0024.
+    - source: docs/adr/
+      role: Accepted framework decisions and policy source records.
+    - source: schemas/ and tools/validate-family-declarations.py
+      role: Machine-readable declaration contracts and enforcement evidence.
+    - source: workplans/ and WORK-RECORDS.md
+      role: Repo-authoritative task state and State Hub projection.
+    - source: workplans/archived/
+      role: State Hub-compatible archive for completed workplans.
+    - source: docs/evidence/
+      role: Dated decision and verification evidence that does not become policy by location.
+
+selected_canon_surfaces:
+  - id: model/purpose-demand-extension
+    reason_selected: The repo must distinguish producer intent, current scope, consumer purpose, raw demand, and scope pressure.
+    required_evidence: [INTENT.md, SCOPE.md, demand/README.md, reviewed demand record]
+  - id: pattern/intent-scope-purposes
+    reason_selected: The prior orientation mixed aspiration and current implementation and had no explicit demand plane.
+    required_evidence: [INTENT.md, SCOPE.md, demand/]
+  - id: model/governance
+    reason_selected: The repo authors accepted ADRs, evidence-backed decisions, exposure grants, and lifecycle metadata.
+    required_evidence: [docs/adr/, docs/evidence/, workplan review gates]
+  - id: model/task
+    reason_selected: Architecture findings become repo-local workplans and indexed State Hub tasks.
+    required_evidence: [workplans/, WORK-RECORDS.md, State Hub bindings]
+  - id: model/information-space
+    reason_selected: The repo separates current stakeholder documents, evidence, intake, and inactive history.
+    required_evidence: [docs/, docs/evidence/, demand/, history/]
+  - id: model/landscape
+    reason_selected: Railiance architecture describes repositories, services, execution contracts, workloads, substrates, and their relations.
+    required_evidence: [docs/repository-axes.md, docs/reef-substrate-model.md, family schemas]
+  - id: standard/repository-layout
+    reason_selected: The request explicitly asks for alignment with the canonical retrieval-oriented repository structure.
+    required_evidence: [INTENT.md, SCOPE.md, demand/, workplans/, docs/, history/]
+
+mapping_findings:
+  - id: RMASTER-ITC-M01
+    source_concept: Repository intent
+    canon_target: model/governance Intent and pattern/intent-scope-purposes
+    fit: direct
+    evidence: [INTENT.md]
+    notes: Stable direction is separate from current implementation claims.
+  - id: RMASTER-ITC-M02
+    source_concept: Current repository scope
+    canon_target: model/governance Scope and pattern/intent-scope-purposes
+    fit: direct
+    evidence: [SCOPE.md]
+    notes: Current artifacts, authority, exclusions, and gaps are explicit.
+  - id: RMASTER-ITC-M03
+    source_concept: Architecture proposal intake
+    canon_target: model/purpose-demand-extension DemandSignal, ConsumerPurpose, PurposeFit, and ScopePressure
+    fit: direct
+    evidence: [demand/README.md, history/260818-demand-canon-policy-alignment.md]
+    notes: Raw demand is not a task; disposition is required before commitment.
+  - id: RMASTER-ITC-M04
+    source_concept: Framework architecture decisions
+    canon_target: model/governance Decision, policy source, evidence, status, and review lifecycle
+    fit: direct
+    evidence: [docs/adr/, RMASTER-WP-0024-T02]
+    notes: Content authority stays here while publication is read-only downstream.
+  - id: RMASTER-ITC-M05
+    source_concept: Cross-repo architecture workplans
+    canon_target: model/task work item lifecycle and dependencies
+    fit: direct
+    evidence: [workplans/, WORK-RECORDS.md, AGENTS.md]
+    notes: Files remain authoritative and State Hub remains an index/cache.
+  - id: RMASTER-ITC-M06
+    source_concept: Completed-work archive
+    canon_target: standard/repository-layout history semantics and model/task lifecycle
+    fit: partial
+    evidence: [workplans/archived/, history/, SCOPE.md]
+    notes: Semantics align, but Custodian ADR-001 requires workplans/archived rather than generic history placement for deterministic indexing.
+  - id: RMASTER-ITC-M07
+    source_concept: Rail, rapp, reef, and ownership repository axes
+    canon_target: model/landscape systems, services, runtime resources, relationships, and boundaries
+    fit: partial
+    evidence: [docs/repository-axes.md, schemas/rail.schema.json, schemas/rapp.schema.json, schemas/reef.schema.json]
+    notes: Native terms are intentionally preserved; flattening them into generic landscape terms would lose Railiance semantics.
+  - id: RMASTER-ITC-M08
+    source_concept: Stakeholder documentation and dated evidence
+    canon_target: model/information-space knowledge packaging, provenance, and retrieval
+    fit: direct
+    evidence: [docs/, docs/evidence/, history/]
+    notes: Policy sources, working evidence, and inactive exploration remain distinct.
+  - id: RMASTER-ITC-M09
+    source_concept: Permanent policy publication
+    canon_target: model/governance authority and provenance boundary
+    fit: direct
+    evidence: [INTENT.md, SCOPE.md, RMASTER-WP-0024-T02]
+    notes: policy-nexus owns addresses, rendering, history, and currency but cannot modify source decisions.
+  - id: RMASTER-ITC-M10
+    source_concept: Repository layout conformance
+    canon_target: standard/repository-layout core conformance
+    fit: direct
+    evidence: [INTENT.md, SCOPE.md, demand/, workplans/, docs/]
+    notes: Optional directories are omitted intentionally rather than created empty.
+
+scorecard:
+  - dimension: fit
+    rating: 3
+    rationale: Selected canon surfaces map cleanly; Railiance-native family terms remain intentionally specialized.
+    evidence: [mapping findings RMASTER-ITC-M01 through RMASTER-ITC-M10]
+  - dimension: gaps
+    rating: 3
+    rationale: Remaining gaps are explicit and bounded to downstream ADR publication plus periodic reassessment.
+    evidence: [SCOPE.md Gap to Intent, RMASTER-WP-0024-T02]
+  - dimension: conflicts
+    rating: 3
+    rationale: No unresolved semantic collision remains; the one archive-path tension is documented as a compatibility question rather than silently normalized.
+    evidence: [RMASTER-ITC-M06, SCOPE.md repository-layout alignment]
+  - dimension: evidence-quality
+    rating: 3
+    rationale: Claims link to source files, accepted ADRs, schemas, validation tools, workplan bindings, and dated review evidence.
+    evidence: [repository_context.evidence_inventory]
+  - dimension: implementation-priority
+    rating: 3
+    rationale: Publication, demand intake, archival cleanup, and repeatable review are ordered by current consumer value and ownership.
+    evidence: [RMASTER-WP-0024]
+  - dimension: canon-pressure
+    rating: 2
+    rationale: Consumer alignment is strong, but ITC-REPO-LAYOUT should clarify compatibility with task systems that require a specialized indexed archive path.
+    evidence: [RMASTER-ITC-M06]
+  - dimension: workplan-readiness
+    rating: 4
+    rationale: RMASTER-WP-0024 has explicit boundaries, owners, statuses, acceptance criteria, downstream routing, and validation paths.
+    evidence: [workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md]
+
+decision_band: ready-to-adopt
+
+recommended_workplans:
+  - id: RMASTER-WP-0024
+    title: Align railiance-master with InfoTechCanon and policy publication
+    target_repo: railiance-master
+    priority: high
+    rationale: The existing workplan owns all actionable consumer-side gaps without moving implementation into the canon or publisher repos.
+    tasks:
+      - Complete downstream permanent ADR publication verification.
+      - Maintain reviewed demand intake and disposition evidence.
+      - Preserve State Hub-compatible completed-work archival.
+      - Repeat this alignment review when intent, scope, or the selected canon surfaces materially change.
+
+canon_feedback:
+  - id: RMASTER-ITC-F01
+    feedback_type: open-question
+    summary: Clarify whether ITC-REPO-LAYOUT full conformance permits a repository-specific indexed archive such as workplans/archived when moving completed tasks to generic history would break the task system's deterministic discovery contract.
+    proposed_owner: info-tech-canon
+    handoff_message_id: 446f5cf1-53f7-4ca0-ab5a-f7278eae6fd7
+  - id: RMASTER-ITC-F02
+    feedback_type: no-change
+    summary: Rail, rapp, reef, and ownership repository axes should remain Railiance-native specializations mapped to the Landscape Model; no generic canon concept change is requested.
+    proposed_owner: railiance-master
--- a/history/260818-demand-canon-policy-alignment.md
+++ b/history/260818-demand-canon-policy-alignment.md
@ -0,0 +1,78 @@
+---
+id: RMASTER-DEMAND-2026-08-18-001
+type: demand-review
+status: accepted
+received: "2026-08-18"
+reviewed: "2026-08-18"
+reviewer: codex
+source: operator
+consumer: railiance-master maintainers and architecture consumers
+resulting_workplan: RMASTER-WP-0024
+---
+
+# Review: align railiance-master with InfoTechCanon and policy-nexus
+
+## Demand signal
+
+Review and update the repository's intent and current scope against the newer
+InfoTechCanon repository structure and `policy-nexus` authority model, then
+identify and execute the obvious alignment work.
+
+## Consumer purpose
+
+Maintainers and downstream Railiance repositories need to tell, without
+reconstructing context from multiple repos:
+
+- what architecture this repository owns;
+- which general concepts it imports from InfoTechCanon;
+- which accepted records are policy sources;
+- which responsibilities belong to the permanent publisher; and
+- how inbound architecture requests become reviewed work.
+
+## Purpose fit
+
+**Strong fit.** `INTENT.md` already names this repository as the Railiance
+framework architecture home. Clarifying semantic-canon, content-authority, and
+publication boundaries strengthens that purpose without adding an implementation
+layer.
+
+## Scope pressure
+
+The demand exposed three current-scope gaps rather than a request to broaden the
+mission:
+
+1. `INTENT.md` and `SCOPE.md` did not distinguish InfoTechCanon authority,
+   Railiance-specific authority, and `policy-nexus` publication.
+2. Eight accepted ADRs were discovered by `policy-nexus` but lacked required
+   publication metadata and addressing.
+3. The repo had no explicit pre-work intake, so State Hub messages could be
+   promoted to workplans without a durable purpose/scope review.
+
+It also exposed housekeeping pressure: completed workplans remained in the
+active retrieval directory despite a repository-specific archive convention.
+
+## Evidence reviewed
+
+- `INTENT.md`, `SCOPE.md`, `README.md`, and `.repo-classification.yaml`
+- `docs/adr/ADR-0001` through `ADR-0008`
+- `schemas/`, `tools/`, `workplans/`, and `history/`
+- InfoTechCanon ITC-REPO-LAYOUT 0.1.0-RC1 and consumer review kit
+- `policy-nexus/INTENT.md`, publication contract, and source inventory
+
+## Disposition
+
+**Accepted** as `RMASTER-WP-0024`.
+
+The work belongs here because it changes the architecture repository's own
+interfaces and source metadata. Downstream address selection and rendering are
+routed to `policy-nexus`; the publisher does not edit the source records.
+
+## Outcome
+
+- Intent and scope authority boundaries were corrected.
+- Repository-layout conformance became explicit and later advanced to `core`
+  through the reviewed demand intake demonstrated by this record.
+- ADR source metadata became renderer-compatible; downstream publication remains
+  separately owned.
+- Remaining alignment work is tracked in `RMASTER-WP-0024` rather than inferred
+  from the original request.
--- a/workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md
+++ b/workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md
@ -4,7 +4,7 @@ type: workplan
 title: "Align railiance-master with InfoTechCanon and policy publication"
 domain: financials
 repo: railiance-master
-status: active
+status: blocked
 owner: codex
 topic_slug: railiance
 created: "2026-08-18"
@ -56,7 +56,7 @@ the Custodian archive deviation, and records the policy-publication gap.

 ```task
 id: RMASTER-WP-0024-T02
-status: progress
+status: wait
 priority: high
 state_hub_task_id: "00e6bc8b-bb75-44a0-b6aa-5a4ce034ce99"
 ```
@ -83,11 +83,17 @@ registration, and clean-revision publication verification in `policy-nexus`.
 That handoff is State Hub message
 `3f27c5a1-3ff8-4d9d-9310-799f303f526a`.

+2026-08-18 closeout: all source-side and repo-local work is complete. T02 is
+`wait` because `policy-nexus` has not yet claimed the message or registered the
+eight explicit publication entries. The workplan is blocked only on that
+downstream owner action; no local metadata, renderer, or clean-revision gate
+remains.
+
 ## T03 - Establish reviewed demand intake without demand-as-task

 ```task
 id: RMASTER-WP-0024-T03
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "54e321e2-e603-4b72-9d76-7a36f6b30782"
 ```
@ -103,11 +109,18 @@ directly to tasks. Empty directories alone do not count as adoption.
 Done when the repo either has a used, documented demand intake with one worked
 example or records why `minimal` conformance remains the honest level.

+Completed 2026-08-18. `demand/README.md` defines an unreviewed DemandSignal
+surface, required purpose/scope review, four explicit dispositions, and the
+rule that resolved records leave intake for dated history. The operator request
+that created this workplan is the worked example at
+`history/260818-demand-canon-policy-alignment.md`. `SCOPE.md` now declares
+honest `core` conformance; no empty optional directories were created.
+
 ## T04 - Reconcile completed-work archival with State Hub discovery

 ```task
 id: RMASTER-WP-0024-T04
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "27f1b916-d6fc-4cc4-8bd2-52eda8994666"
 ```
@ -121,11 +134,18 @@ silently adopting the generic ITC finished-workplan placement.
 Done when active retrieval is uncluttered, archived records remain indexed, and
 `statehub fix-consistency` reports no task or workplan drift.

+Completed 2026-08-18. Seven finished records (`ADHOC-2026-07-30` and
+`RMASTER-WP-0017`, `0018`, `0019`, `0021`, `0022`, `0023`) moved to
+`workplans/archived/260818-...`, retained their stable IDs and State Hub task
+bindings, and changed to `status: archived`. `history/` remains the home for
+inactive architecture exploration and reviewed demand rather than workplan
+state.
+
 ## T05 - Produce a repeatable canon-consumer alignment packet

 ```task
 id: RMASTER-WP-0024-T05
-status: todo
+status: done
 priority: low
 state_hub_task_id: "ff70f0e3-32ba-4420-8ce5-983224d792a3"
 ```
@ -137,3 +157,12 @@ repo-local work, and any canon feedback without silently changing canon terms.

 Done when a future reviewer can repeat the assessment and distinguish a
 Railiance-specific gap from genuine pressure on InfoTechCanon.
+
+Completed 2026-08-18. The structured review packet is
+`docs/evidence/infotech-canon-alignment-review-2026-08-18.yaml`. It records the
+repository context, seven selected canon surfaces, ten source-linked mappings,
+the full scorecard, the existing repo-local workplan, and two feedback items.
+Rail/rapp/reef specialization remains local; the only canon pressure is whether
+ITC-REPO-LAYOUT should explicitly permit task-system-compatible archive paths.
+That question was routed to `info-tech-canon` in State Hub message
+`446f5cf1-53f7-4ca0-ab5a-f7278eae6fd7`.
--- a/workplans/archived/260818-ADHOC-2026-07-30.md
+++ b/workplans/archived/260818-ADHOC-2026-07-30.md
@ -4,11 +4,11 @@ type: workplan
 title: "Ad-hoc Railiance framework maintenance on 2026-07-30"
 domain: financials
 repo: railiance-master
-status: finished
+status: archived
 owner: codex
 topic_slug: railiance
 created: "2026-07-30"
-updated: "2026-07-30"
+updated: "2026-08-18"
 state_hub_workstream_id: "1cc4d75f-9bd8-4843-8b18-5ce9637edd60"
 ---

--- a/workplans/archived/260818-RMASTER-WP-0017-rail-rapp-reef-repo-separation.md
+++ b/workplans/archived/260818-RMASTER-WP-0017-rail-rapp-reef-repo-separation.md
@ -4,13 +4,13 @@ type: workplan
 title: "Rail, Rapp, and Reef Repo Separation"
 domain: financials
 repo: railiance-master
-status: finished
+status: archived
 owner: codex
 topic_slug: railiance
 planning_priority: high
 planning_order: 17
 created: "2026-07-25"
-updated: "2026-07-25"
+updated: "2026-08-18"
 related_repos:
  - railiance-master
  - railiance-cluster
--- a/workplans/archived/260818-RMASTER-WP-0018-first-wave-repo-family-materialization.md
+++ b/workplans/archived/260818-RMASTER-WP-0018-first-wave-repo-family-materialization.md
@ -4,13 +4,13 @@ type: workplan
 title: "First-Wave Repo Family Materialization"
 domain: financials
 repo: railiance-master
-status: finished
+status: archived
 owner: codex
 topic_slug: railiance
 planning_priority: high
 planning_order: 18
 created: "2026-07-25"
-updated: "2026-07-26"
+updated: "2026-08-18"
 related_repos:
  - railiance-master
  - railiance-cluster
--- a/workplans/archived/260818-RMASTER-WP-0019-knative-qonto-runtime-on-reef-railiance.md
+++ b/workplans/archived/260818-RMASTER-WP-0019-knative-qonto-runtime-on-reef-railiance.md
@ -4,13 +4,13 @@ type: workplan
 title: "Knative Qonto Runtime on reef-railiance"
 domain: financials
 repo: railiance-master
-status: finished
+status: archived
 owner: codex
 topic_slug: railiance
 planning_priority: high
 planning_order: 19
 created: "2026-07-26"
-updated: "2026-07-29"
+updated: "2026-08-18"
 related_repos:
  - railiance-master
  - qonto-assistant
--- a/workplans/archived/260818-RMASTER-WP-0021-rapp-declaration-schema.md
+++ b/workplans/archived/260818-RMASTER-WP-0021-rapp-declaration-schema.md
@ -4,13 +4,13 @@ type: workplan
 title: "Rapp Declaration Schema and Family Declaration Validator"
 domain: financials
 repo: railiance-master
-status: finished
+status: archived
 owner: codex
 topic_slug: railiance
 planning_priority: high
 planning_order: 21
 created: "2026-08-11"
-updated: "2026-08-13"
+updated: "2026-08-18"
 related_repos:
  - railiance-master
  - railiance-platform
--- a/workplans/archived/260818-RMASTER-WP-0022-establish-reef-storage.md
+++ b/workplans/archived/260818-RMASTER-WP-0022-establish-reef-storage.md
@ -4,11 +4,11 @@ type: workplan
 title: "Establish reef-storage for Scaleway object storage"
 domain: financials
 repo: railiance-master
-status: finished
+status: archived
 owner: grok
 topic_slug: railiance
 created: "2026-08-14"
-updated: "2026-08-14"
+updated: "2026-08-18"
 related:
  - RMASTER-WP-0017
  - RMASTER-WP-0021
--- a/workplans/archived/260818-RMASTER-WP-0023-private-by-default-exposure.md
+++ b/workplans/archived/260818-RMASTER-WP-0023-private-by-default-exposure.md
@ -4,13 +4,13 @@ type: workplan
 title: "Private-by-default exposure until production admission"
 domain: financials
 repo: railiance-master
-status: finished
+status: archived
 owner: grok
 topic_slug: railiance
 planning_priority: high
 planning_order: 23
 created: "2026-08-15"
-updated: "2026-08-15"
+updated: "2026-08-18"
 related:
  - ADR-0006
  - ADR-0008
@ -97,7 +97,7 @@ It does **not** belong as the system owner in:
 ## Decision (T01, accepted 2026-08-15)

 Ratified as written. Recorded in
-[`docs/adr/ADR-0008-private-by-default-exposure.md`](../docs/adr/ADR-0008-private-by-default-exposure.md).
+[`docs/adr/ADR-0008-private-by-default-exposure.md`](../../docs/adr/ADR-0008-private-by-default-exposure.md).

 | Posture | Meaning | Who may reach it |
 | --- | --- | --- |