From 7d32673812263aceaf30cb84a0ba52becb8ca1d5 Mon Sep 17 00:00:00 2001 From: codex Date: Tue, 18 Aug 2026 17:00:07 +0200 Subject: [PATCH] docs: align master with canon and policy publication --- INTENT.md | 51 ++++- SCOPE.md | 198 ++++++++++++------ WORK-RECORDS.md | 6 + ...ADR-0001-repository-prefix-architecture.md | 10 + ...DR-0002-rail-kubernetes-wave-1-boundary.md | 10 + .../adr/ADR-0003-rapp-first-wave-selection.md | 10 + docs/adr/ADR-0004-first-wave-reef-rollout.md | 10 + docs/adr/ADR-0005-derived-rail-composition.md | 10 + .../adr/ADR-0006-reef-production-admission.md | 10 + .../adr/ADR-0007-rapp-declaration-contract.md | 10 + .../ADR-0008-private-by-default-exposure.md | 10 + ...-canon-and-policy-publication-alignment.md | 138 ++++++++++++ 12 files changed, 403 insertions(+), 70 deletions(-) create mode 100644 workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md diff --git a/INTENT.md b/INTENT.md index c7d17b7..75e0d81 100644 --- a/INTENT.md +++ b/INTENT.md @@ -9,7 +9,9 @@ ## One-liner -**The Railiance architecture-definition home — turning evolving repo families, workload models, and substrate realities into a coherent framework vocabulary and boundary model.** +**The authoritative source for Railiance framework architecture — turning +evolving repo families, workload models, and substrate realities into coherent, +reviewable, and permanently publishable boundary decisions.** --- @@ -57,6 +59,20 @@ organization. They shape how humans and agents coordinate responsibilities, reason about workload placement, and evolve operating models without losing the ability to scale into more mature security and delivery expectations. +Railiance also participates in two wider governance structures: + +* **InfoTechCanon** owns the general semantic models, standards, and repository + conventions that Railiance adopts. This repository imports those concepts and + applies them to Railiance; it does not redefine the canon by local usage. +* **`policy-nexus`** owns permanent publication, addressing, history, and + currency for estate policy. This repository remains the source and + ratification home for its architecture decision records. Publication is + generated downstream and never written back here. + +That separation matters. Content authority, semantic canon, and publication +infrastructure are related responsibilities, not one responsibility hidden in +three repositories. + --- ## The Mission @@ -66,7 +82,8 @@ ability to scale into more mature security and delivery expectations. To become the **canonical home for Railiance framework architecture** — where repository taxonomy, architectural boundaries, execution-model concepts, managed workload patterns, substrate concepts, and migration direction are -defined once and referenced everywhere else. +defined once, reviewed here, published durably when governing, and referenced +everywhere else. This means: @@ -76,6 +93,8 @@ This means: **separate and composable** * Explorations mature into **stable decisions** before they spread across the wider repo landscape +* Governing ADRs carry enough ownership, revision, status, and review metadata + to be published without a second source of truth * The framework can support both **early-stage experimentation** and **production-grade operation** without collapsing those needs into one vague structure @@ -137,6 +156,27 @@ purpose and operational boundary. They should not be created merely because a named machine exists. +### 10. Import Canon; Own Railiance Semantics + +General concepts such as intent, scope, demand, task, governance, evidence, and +repository layout come from InfoTechCanon and estate conventions. This repo owns +their Railiance-specific application: repo-family vocabulary, composition, +admission, exposure, and cross-repo boundary decisions. + +### 11. Author Here; Publish Downstream + +Accepted framework ADRs are policy sources. They are authored, reviewed, +superseded, or withdrawn here and published by `policy-nexus`. Workplans, +evidence, runbooks, and general documentation remain working material rather +than becoming policy merely because they are useful. + +### 12. Keep Intent, Scope, and Demand Distinct + +`INTENT.md` describes the direction and stable purpose. `SCOPE.md` describes +what the repository currently owns and achieves. Consumer requests and incoming +proposals are demand signals until reviewed; they do not silently expand scope +or become committed work. + --- ## What This Is (Conceptually) @@ -146,6 +186,8 @@ This repository is: * an **architecture-definition home** * a **repository taxonomy authority** * a home for **framework-level ADRs and conceptual models** +* the **source repository** for Railiance framework ADRs published through + `policy-nexus` * a place to define how Railiance repos **compose across multiple axes** * a **migration map** from current repo reality toward cleaner framework structure @@ -162,6 +204,9 @@ This repository is not: * the forge runtime * the application release surface * the implementation of the ecosystem graph registry +* the general semantic canon owned by InfoTechCanon +* the permanent policy publication surface owned by `policy-nexus` +* a policy CMS or a second copy of published policy * a dumping ground for operational runbooks that belong elsewhere It is the **place where the framework explains itself**. @@ -177,6 +222,8 @@ This repository is expected to evolve toward: * stronger **boundary guidance** for new repos and migrations * better linkage between architecture decisions and `railiance-fabric` declarations +* publication-ready ADR lifecycle metadata and durable downstream policy links +* explicit, graded adoption of the InfoTechCanon repository-layout convention * a repeatable path from **exploration -> ADR -> adopted framework pattern** * a clear model for when experimental multi-rail substrates are acceptable and when production-grade separation is the better default diff --git a/SCOPE.md b/SCOPE.md index 56cd52d..bcd38f1 100644 --- a/SCOPE.md +++ b/SCOPE.md @@ -1,112 +1,166 @@ # SCOPE -> This file helps you quickly understand what this repository is about, -> when it is relevant, and when it is not. -> It is intentionally lightweight and may be incomplete. +> This file describes the repository's current, evidenced responsibility. It is +> deliberately distinct from the direction in `INTENT.md` and from unreviewed +> consumer demand. --- ## One-liner -Architecture-definition home for Railiance: repository taxonomy, framework ADRs, -cross-repo boundary rules, and cross-repo workplans for architecture changes. +Current source of truth for Railiance repository taxonomy, family contracts, +framework ADRs, declaration schemas, and cross-repo architecture workplans. --- -## Core Idea +## Current Responsibility -`railiance-master` is the framework-level architecture repo for Railiance. -It exists so shared concepts such as `railiance-*`, `rail-*`, `rapp-*`, and -`reef-*` are defined once, with explicit boundaries, before they spread across -implementation repos. +`railiance-master` currently owns the Railiance-specific meaning of the four +repository axes: ownership repos (`railiance-*`), execution contracts +(`rail-*`), managed workload packages (`rapp-*`), and substrate boundaries +(`reef-*`). -It also serves as the natural workplan home for changes that span multiple -Railiance repos and cannot be owned cleanly by only one of them. +The current implementation includes: + +- eight accepted framework ADRs covering repository families, rail composition, + production admission, the rapp declaration contract, and exposure posture; +- framework contracts and migration guidance under `docs/`; +- JSON Schemas for rail, rapp, and reef declarations plus a family-declaration + validator and fixtures; +- cross-repo workplans and State Hub bindings for architecture changes that do + not belong wholly to one implementation repository. + +This repo owns the architectural source documents and their lifecycle. It does +not own every implementation implied by them. --- ## In Scope -- Framework-level architecture documents for Railiance -- Repository taxonomy and naming conventions -- Architectural boundaries between ownership repos, rails, `rapp`s, and reefs -- Architecture decision records affecting multiple Railiance repos -- Cross-repo Railiance workplans whose implementation spans multiple sibling repos +- Railiance framework architecture and Railiance-specific vocabulary +- Repository taxonomy, naming, composition, lifecycle, and boundary rules +- Architecture decisions affecting multiple Railiance repositories +- Rail/rapp/reef declaration contracts and framework-level validation rules +- Cross-repo workplans whose outcome cannot be owned cleanly by one concrete + ownership or family repository +- Source metadata and lifecycle decisions for this repo's publishable ADRs +- Routing accepted architecture into repo-local implementation work --- ## Out of Scope -- OS provisioning and host hardening work owned by `railiance-infra` -- Kubernetes runtime implementation owned by `railiance-cluster` -- Platform-service implementation owned by `railiance-platform` -- Application release implementation owned by `railiance-apps` -- Forge runtime implementation owned by `railiance-forge` -- Fabric graph implementation owned by `railiance-fabric` +- General semantic canon or repository standards owned by `info-tech-canon` +- Permanent policy addressing, rendering, hosting, and currency checks owned by + `policy-nexus` +- Regulatory interpretation or disclosure timing owned by `risk-nexus` +- OS provisioning and host hardening owned by `railiance-infra` +- Kubernetes substrate implementation owned by `railiance-cluster` +- Rail implementation owned by the relevant `rail-*` repository +- Managed workload implementation owned by the relevant `rapp-*` repository +- Reef-local substrate declarations and operations owned by the relevant + `reef-*` repository +- Platform services, application releases, forge runtime, and Fabric graph + implementation owned by their concrete repositories + +--- + +## Authority and Publication Boundaries + +| Concern | Authority | Relationship to `railiance-master` | +| --- | --- | --- | +| General semantic models and repository-layout standard | `info-tech-canon` | Imported and applied; not redefined here | +| Railiance framework architecture and ADR lifecycle | `railiance-master` | Authored, reviewed, accepted, superseded, or withdrawn here | +| Permanent publication of accepted ADRs | `policy-nexus` | Downstream read-only publication; never a second source of truth | +| Work indexing and coordination | State Hub | Cache/index rebuilt from repo-local workplan files | +| Runtime implementation | Concrete ownership, rail, rapp, or reef repo | Routed outward after the framework boundary is settled | + +The policy publication corpus from this repo is `docs/adr/*.md`. Workplans, +evidence, runbooks, schemas, and general documentation are not policy merely +because they are useful. `policy-nexus` currently discovers all eight ADRs, but +they remain `metadata-pending` until source lifecycle metadata and explicit +publication addressing are completed. --- ## Relevant When -- Defining a new Railiance repo family or framework term -- Clarifying boundaries between existing Railiance repos -- Planning migrations that touch multiple Railiance repos -- Recording a framework-level architecture decision - ---- +- Defining or changing a Railiance repository family or framework term +- Clarifying a boundary shared by multiple implementation repositories +- Deciding how rails, rapps, reefs, and ownership repositories compose +- Establishing framework-wide admission, exposure, declaration, or lifecycle + rules +- Planning a migration that spans multiple Railiance repositories +- Recording or reviewing a Railiance framework ADR ## Not Relevant When -- The work belongs entirely inside one implementation repo -- The work is operational rather than architectural -- The work is workload-specific rather than framework-wide +- Work belongs entirely inside one implementation repository +- Work is operational execution of an already-settled boundary +- A workload-specific decision has no framework-wide consequence +- The request is raw demand that has not yet been reviewed for purpose and scope + fit --- ## Current State -- Status: maintained / evolving -- Implementation: architecture baseline documents are present and the first concrete repo-family materialization wave has been completed from this repo -- Stability: evolving -- Usage: internal Railiance framework architecture home and handoff point for cross-repo planning +- Status: maintained and evolving +- Architecture baseline: four repository axes are materialized and governed by + accepted ADRs and contracts +- Validation: rail/rapp/reef schemas and declaration checks are implemented +- Active cross-repo work: OpenBao migration closeout remains partially blocked; + public-listener retraction is in progress while destructive source cleanup + retains separate approval and disaster-recovery gates +- Publication: ADR discovery exists in `policy-nexus`; publication metadata and + stable addressing remain an open alignment gap -The repo now holds the canonical framework decisions and boundary documents for -separating `rail-*`, `rapp-*`, and `reef-*` concerns out of the existing -Railiance repos. It also now governs the first implementation wave that turns -those repo families into concrete repos while downstream ownership repos retain -their implementation responsibility. +--- + +## InfoTechCanon Repository-Layout Alignment + +Declared conformance: **`minimal`** under ITC-REPO-LAYOUT 0.1.0-RC1. + +- `INTENT.md` contains stable aspiration and boundaries. +- `SCOPE.md` contains current evidenced responsibility and explicit gaps. +- `docs/` contains stakeholder-facing framework contracts and ADRs. +- `workplans/` contains committed work and remains authoritative for State Hub. +- `history/` contains dated, inactive architecture explorations. + +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. +- Consumer purposes and inbound requests are not folded into INTENT or SCOPE; + a future demand intake may provide that third plane explicitly. --- ## How It Fits -- Upstream dependencies: `the-custodian` canon and State Hub conventions -- Downstream consumers: all `railiance-*`, future `rail-*`, future `rapp-*`, and future `reef-*` repos -- Often used with: `railiance-fabric`, `railiance-platform`, `railiance-cluster`, `state-hub` - ---- - -## Terminology - -- Preferred terms: architecture home, repository axis, rail, `rapp`, reef, ownership repo -- Also known as: framework architecture repo -- Potentially confusing terms: this repo defines framework structure; it does not implement the lower-layer systems it describes - ---- - -## Related / Overlapping Repositories - -- `railiance-fabric` — models the ecosystem graph; `railiance-master` defines framework taxonomy and boundaries -- `state-hub` — indexes and coordinates work; `railiance-master` provides the framework architecture to be coordinated -- `repo-scoping` — explains what repos are useful for; `railiance-master` defines how Railiance repo families fit together +- Upstream standards: `info-tech-canon`, `the-custodian` canon, Custodian + workplan conventions +- Downstream policy publisher: `policy-nexus` (ADRs only, read-only) +- Downstream architecture consumers: all `railiance-*`, `rail-*`, `rapp-*`, and + `reef-*` repositories +- Coordination/index: State Hub +- Common collaborators: `railiance-fabric`, `railiance-platform`, + `railiance-cluster`, `railiance-infra`, `railiance-enablement` --- ## Getting Oriented -- Start with: `README.md`, `INTENT.md` -- Key files / directories: `docs/`, `history/`, `workplans/` -- Entry points: `docs/repository-axes.md`, `docs/reef-substrate-model.md`, `docs/adr/` +- Start with: `README.md`, `INTENT.md`, `SCOPE.md` +- Architecture entry points: `docs/repository-axes.md`, + `docs/reef-substrate-model.md`, `docs/adr/` +- Machine-readable contracts: `schemas/`, + `tools/validate-family-declarations.py` +- Active and historical coordination: `workplans/`, `WORK-RECORDS.md` --- @@ -122,13 +176,21 @@ keywords: [railiance, architecture, taxonomy, rail, rapp, reef] ```capability type: governance title: Railiance framework architecture decisions -description: Records framework-level architecture decisions and boundary guidance for changes spanning multiple Railiance repos. -keywords: [architecture, adr, governance, boundaries, framework] +description: Owns framework ADR content and lifecycle while permanent publication is delegated read-only to policy-nexus. +keywords: [architecture, adr, governance, boundaries, policy-source] +``` + +```capability +type: validation +title: Railiance family declaration contracts +description: Provides schemas and validation rules for rail, rapp, and reef declarations and their cross-family constraints. +keywords: [schema, validation, declaration, rail, rapp, reef] ``` --- -## Notes +## Gap to Intent -Use this repo for architecture that must stay shared. Push concrete -implementation outward into the ownership repos once the framework boundary is clear. +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. diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md index aee50df..4d211e2 100644 --- a/WORK-RECORDS.md +++ b/WORK-RECORDS.md @@ -16,6 +16,7 @@ | 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 | @@ -66,3 +67,8 @@ | 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 | diff --git a/docs/adr/ADR-0001-repository-prefix-architecture.md b/docs/adr/ADR-0001-repository-prefix-architecture.md index 384b70a..b616db6 100644 --- a/docs/adr/ADR-0001-repository-prefix-architecture.md +++ b/docs/adr/ADR-0001-repository-prefix-architecture.md @@ -1,3 +1,13 @@ +--- +id: RMASTER-ADR-0001 +title: "Repository Prefix Architecture" +status: accepted +revision: "accepted-1" +owner: railiance-master +last_reviewed: "2026-07-25" +review_interval: 6m +--- + # ADR-0001: Repository Prefix Architecture Date: 2026-07-25 diff --git a/docs/adr/ADR-0002-rail-kubernetes-wave-1-boundary.md b/docs/adr/ADR-0002-rail-kubernetes-wave-1-boundary.md index 341a8a2..872d4a9 100644 --- a/docs/adr/ADR-0002-rail-kubernetes-wave-1-boundary.md +++ b/docs/adr/ADR-0002-rail-kubernetes-wave-1-boundary.md @@ -1,3 +1,13 @@ +--- +id: RMASTER-ADR-0002 +title: "Wave 1 rail-kubernetes Boundary" +status: accepted +revision: "accepted-1" +owner: railiance-master +last_reviewed: "2026-07-25" +review_interval: 6m +--- + # ADR-0002: Wave 1 `rail-kubernetes` Boundary Date: 2026-07-25 diff --git a/docs/adr/ADR-0003-rapp-first-wave-selection.md b/docs/adr/ADR-0003-rapp-first-wave-selection.md index 6f5dcd9..cb8d608 100644 --- a/docs/adr/ADR-0003-rapp-first-wave-selection.md +++ b/docs/adr/ADR-0003-rapp-first-wave-selection.md @@ -1,3 +1,13 @@ +--- +id: RMASTER-ADR-0003 +title: "First-Wave rapp Selection" +status: accepted +revision: "accepted-1" +owner: railiance-master +last_reviewed: "2026-07-25" +review_interval: 6m +--- + # ADR-0003: First-Wave `rapp-*` Selection Date: 2026-07-25 diff --git a/docs/adr/ADR-0004-first-wave-reef-rollout.md b/docs/adr/ADR-0004-first-wave-reef-rollout.md index 9ca7ee7..8a36edb 100644 --- a/docs/adr/ADR-0004-first-wave-reef-rollout.md +++ b/docs/adr/ADR-0004-first-wave-reef-rollout.md @@ -1,3 +1,13 @@ +--- +id: RMASTER-ADR-0004 +title: "First-Wave reef Rollout" +status: accepted +revision: "accepted-1" +owner: railiance-master +last_reviewed: "2026-07-26" +review_interval: 6m +--- + # ADR-0004: First-Wave `reef-*` Rollout Date: 2026-07-25 diff --git a/docs/adr/ADR-0005-derived-rail-composition.md b/docs/adr/ADR-0005-derived-rail-composition.md index 71f3252..b441fbe 100644 --- a/docs/adr/ADR-0005-derived-rail-composition.md +++ b/docs/adr/ADR-0005-derived-rail-composition.md @@ -1,3 +1,13 @@ +--- +id: RMASTER-ADR-0005 +title: "Derived Rail Composition" +status: accepted +revision: "accepted-1" +owner: railiance-master +last_reviewed: "2026-07-26" +review_interval: 6m +--- + # ADR-0005: Derived Rail Composition Date: 2026-07-26 diff --git a/docs/adr/ADR-0006-reef-production-admission.md b/docs/adr/ADR-0006-reef-production-admission.md index d0fa052..4ab6898 100644 --- a/docs/adr/ADR-0006-reef-production-admission.md +++ b/docs/adr/ADR-0006-reef-production-admission.md @@ -1,3 +1,13 @@ +--- +id: RMASTER-ADR-0006 +title: "Reef Production Admission" +status: accepted +revision: "accepted-1" +owner: railiance-master +last_reviewed: "2026-08-15" +review_interval: 6m +--- + # ADR-0006: Reef Production Admission Date: 2026-07-26 diff --git a/docs/adr/ADR-0007-rapp-declaration-contract.md b/docs/adr/ADR-0007-rapp-declaration-contract.md index 1890fab..af29f09 100644 --- a/docs/adr/ADR-0007-rapp-declaration-contract.md +++ b/docs/adr/ADR-0007-rapp-declaration-contract.md @@ -1,3 +1,13 @@ +--- +id: RMASTER-ADR-0007 +title: "Rapp Declaration Contract" +status: accepted +revision: "accepted-1" +owner: railiance-master +last_reviewed: "2026-08-13" +review_interval: 6m +--- + # ADR-0007: Rapp Declaration Contract Date: 2026-08-13 diff --git a/docs/adr/ADR-0008-private-by-default-exposure.md b/docs/adr/ADR-0008-private-by-default-exposure.md index 0de4bb7..5f9e5d8 100644 --- a/docs/adr/ADR-0008-private-by-default-exposure.md +++ b/docs/adr/ADR-0008-private-by-default-exposure.md @@ -1,3 +1,13 @@ +--- +id: RMASTER-ADR-0008 +title: "Private-by-default Exposure" +status: accepted +revision: "accepted-1" +owner: railiance-master +last_reviewed: "2026-08-15" +review_interval: 6m +--- + # ADR-0008: Private-by-default Exposure Date: 2026-08-15 diff --git a/workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md b/workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md new file mode 100644 index 0000000..b5b5452 --- /dev/null +++ b/workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md @@ -0,0 +1,138 @@ +--- +id: RMASTER-WP-0024 +type: workplan +title: "Align railiance-master with InfoTechCanon and policy publication" +domain: financials +repo: railiance-master +status: active +owner: codex +topic_slug: railiance +created: "2026-08-18" +updated: "2026-08-18" +state_hub_workstream_id: "de6681cd-9f8b-4a17-89d8-d3e3ce506388" +--- + +# RMASTER-WP-0024 - Canon and policy publication alignment + +## Goal + +Adopt the useful parts of the InfoTechCanon consumer and repository-layout +standards while preserving Railiance-specific authority, and make this repo's +accepted ADRs consumable by `policy-nexus` without creating a second source of +truth. + +## Boundaries + +- `info-tech-canon` owns the general semantic and layout standards; this repo + records consumer alignment and sends canon pressure back explicitly. +- `railiance-master` owns Railiance framework ADR content and lifecycle. +- `policy-nexus` owns publication addresses, rendering, history, and currency; + it reads this repo and never writes back. +- This workplan does not publish workplans, evidence, runbooks, schemas, or + general documentation as policy. +- Custodian ADR-001 workplan discovery remains controlling where the generic ITC + layout recommendation would break State Hub indexing. + +## T01 - Separate intent, current scope, canon authority, and publication + +```task +id: RMASTER-WP-0024-T01 +status: done +priority: high +state_hub_task_id: "bc28546d-4184-40df-b9e5-5f1c1015ba1e" +``` + +Review `INTENT.md` and `SCOPE.md` against ITC-REPO-LAYOUT, the canon consumer +review workflow, and the `policy-nexus` source/publication boundary. Record an +honest layout conformance level, current omissions, authority relationships, +and the SCOPE-to-INTENT gap. + +Completed 2026-08-18. `INTENT.md` now distinguishes semantic canon, Railiance +content authority, and downstream publication. `SCOPE.md` describes current +artifacts and active work, declares minimal ITC layout conformance, preserves +the Custodian archive deviation, and records the policy-publication gap. + +## T02 - Make framework ADR source metadata publication-ready + +```task +id: RMASTER-WP-0024-T02 +status: progress +priority: high +state_hub_task_id: "00e6bc8b-5ff1-4f12-9ea0-08fe2d8486ca" +state_hub_task_id: "00e6bc8b-bb75-44a0-b6aa-5a4ce034ce99" +``` + +Add consistent source metadata to every accepted ADR under `docs/adr/`: title, +status, owner, immutable semantic revision, and last-reviewed date. Review each +date rather than copying file timestamps. Define how amendments advance a +revision without rewriting an already-published immutable revision. + +Coordinate with `policy-nexus` for explicit stable and revision addresses and a +review interval. The publication manifest remains downstream; the source +metadata remains here. + +Done when all eight currently discovered ADRs move from `metadata-pending` to +published or carry an explicit reviewed reason not to publish, and the +`policy-nexus` source audit/build/currency checks pass against a clean +`railiance-master` revision. + +2026-08-18: Source-side metadata is present on all eight ADRs using stable +`RMASTER-ADR-NNNN` identities, `accepted-1` as their first immutable semantic +revision, source ownership, evidence-based last-reviewed dates, and a six-month +review interval. Remaining work is downstream explicit addressing, manifest +registration, and clean-revision publication verification in `policy-nexus`. + +## T03 - Establish reviewed demand intake without demand-as-task + +```task +id: RMASTER-WP-0024-T03 +status: todo +priority: medium +state_hub_task_id: "54e321e2-e603-4b72-9d76-7a36f6b30782" +``` + +Decide whether recurring cross-repo architecture proposals justify adopting +the ITC `demand/` surface and `core` layout conformance. If adopted, define a +small demand record that captures provenance, consumer purpose, purpose fit, +scope pressure, review disposition, and the resulting workplan or rejection. + +Do not mirror the State Hub inbox wholesale and do not promote raw requests +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. + +## T04 - Reconcile completed-work archival with State Hub discovery + +```task +id: RMASTER-WP-0024-T04 +status: todo +priority: medium +state_hub_task_id: "27f1b916-d6fc-4cc4-8bd2-52eda8994666" +``` + +Review finished workplans still present in `workplans/`. Archive eligible files +using the repository's Custodian convention +`workplans/archived/YYMMDD-RMASTER-WP-...` and preserve frontmatter IDs and +links. Keep `history/` for dated inactive architecture exploration rather than +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. + +## T05 - Produce a repeatable canon-consumer alignment packet + +```task +id: RMASTER-WP-0024-T05 +status: todo +priority: low +state_hub_task_id: "ff70f0e3-32ba-4420-8ce5-983224d792a3" +``` + +Apply the InfoTechCanon consumer review kit using the smallest relevant surface +set: Purpose/Demand, Intent-Scope-Purposes, Governance, Task, Information Space, +Landscape, and ITC-REPO-LAYOUT. Record mappings, evidence, prioritized gaps, +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.