coulomb/railiance-master
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: align master with canon and policy publication

Browse source
This commit is contained in:
codex 2026-08-18 17:00:07 +02:00
parent 6e230be13a
commit 7d32673812
12 changed files with 403 additions and 70 deletions
Download patch file Download diff file Expand all files Collapse all files

51
INTENT.md
View file

@ -9,7 +9,9 @@
## One-liner ## 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 reason about workload placement, and evolve operating models without losing the
ability to scale into more mature security and delivery expectations. 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 ## 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** — To become the **canonical home for Railiance framework architecture** —
where repository taxonomy, architectural boundaries, execution-model concepts, where repository taxonomy, architectural boundaries, execution-model concepts,
managed workload patterns, substrate concepts, and migration direction are 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: This means:
@ -76,6 +93,8 @@ This means:
**separate and composable** **separate and composable**
* Explorations mature into **stable decisions** before they spread across the * Explorations mature into **stable decisions** before they spread across the
wider repo landscape 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 * The framework can support both **early-stage experimentation** and
**production-grade operation** without collapsing those needs into one vague **production-grade operation** without collapsing those needs into one vague
structure structure
@ -137,6 +156,27 @@ purpose and operational boundary.
They should not be created merely because a named machine exists. 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) ## What This Is (Conceptually)
@ -146,6 +186,8 @@ This repository is:
* an **architecture-definition home** * an **architecture-definition home**
* a **repository taxonomy authority** * a **repository taxonomy authority**
* a home for **framework-level ADRs and conceptual models** * 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 place to define how Railiance repos **compose across multiple axes**
* a **migration map** from current repo reality toward cleaner framework * a **migration map** from current repo reality toward cleaner framework
structure structure
@ -162,6 +204,9 @@ This repository is not:
* the forge runtime * the forge runtime
* the application release surface * the application release surface
* the implementation of the ecosystem graph registry * 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 * a dumping ground for operational runbooks that belong elsewhere
It is the **place where the framework explains itself**. 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 * stronger **boundary guidance** for new repos and migrations
* better linkage between architecture decisions and `railiance-fabric` * better linkage between architecture decisions and `railiance-fabric`
declarations 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 repeatable path from **exploration -> ADR -> adopted framework pattern**
* a clear model for when experimental multi-rail substrates are acceptable and * a clear model for when experimental multi-rail substrates are acceptable and
when production-grade separation is the better default when production-grade separation is the better default

198
SCOPE.md
View file

@ -1,112 +1,166 @@
# SCOPE # SCOPE
> This file helps you quickly understand what this repository is about, > This file describes the repository's current, evidenced responsibility. It is
> when it is relevant, and when it is not. > deliberately distinct from the direction in `INTENT.md` and from unreviewed
> It is intentionally lightweight and may be incomplete. > consumer demand.
--- ---
## One-liner ## One-liner
Architecture-definition home for Railiance: repository taxonomy, framework ADRs, Current source of truth for Railiance repository taxonomy, family contracts,
cross-repo boundary rules, and cross-repo workplans for architecture changes. framework ADRs, declaration schemas, and cross-repo architecture workplans.
--- ---
## Core Idea ## Current Responsibility
`railiance-master` is the framework-level architecture repo for Railiance. `railiance-master` currently owns the Railiance-specific meaning of the four
It exists so shared concepts such as `railiance-*`, `rail-*`, `rapp-*`, and repository axes: ownership repos (`railiance-*`), execution contracts
`reef-*` are defined once, with explicit boundaries, before they spread across (`rail-*`), managed workload packages (`rapp-*`), and substrate boundaries
implementation repos. (`reef-*`).
It also serves as the natural workplan home for changes that span multiple The current implementation includes:
Railiance repos and cannot be owned cleanly by only one of them.
- 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 ## In Scope
- Framework-level architecture documents for Railiance - Railiance framework architecture and Railiance-specific vocabulary
- Repository taxonomy and naming conventions - Repository taxonomy, naming, composition, lifecycle, and boundary rules
- Architectural boundaries between ownership repos, rails, `rapp`s, and reefs - Architecture decisions affecting multiple Railiance repositories
- Architecture decision records affecting multiple Railiance repos - Rail/rapp/reef declaration contracts and framework-level validation rules
- Cross-repo Railiance workplans whose implementation spans multiple sibling repos - 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 ## Out of Scope
- OS provisioning and host hardening work owned by `railiance-infra` - General semantic canon or repository standards owned by `info-tech-canon`
- Kubernetes runtime implementation owned by `railiance-cluster` - Permanent policy addressing, rendering, hosting, and currency checks owned by
- Platform-service implementation owned by `railiance-platform` `policy-nexus`
- Application release implementation owned by `railiance-apps` - Regulatory interpretation or disclosure timing owned by `risk-nexus`
- Forge runtime implementation owned by `railiance-forge` - OS provisioning and host hardening owned by `railiance-infra`
- Fabric graph implementation owned by `railiance-fabric` - 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 ## Relevant When
- Defining a new Railiance repo family or framework term - Defining or changing a Railiance repository family or framework term
- Clarifying boundaries between existing Railiance repos - Clarifying a boundary shared by multiple implementation repositories
- Planning migrations that touch multiple Railiance repos - Deciding how rails, rapps, reefs, and ownership repositories compose
- Recording a framework-level architecture decision - 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 ## Not Relevant When
- The work belongs entirely inside one implementation repo - Work belongs entirely inside one implementation repository
- The work is operational rather than architectural - Work is operational execution of an already-settled boundary
- The work is workload-specific rather than framework-wide - 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 ## Current State
- Status: maintained / evolving - Status: maintained and evolving
- Implementation: architecture baseline documents are present and the first concrete repo-family materialization wave has been completed from this repo - Architecture baseline: four repository axes are materialized and governed by
- Stability: evolving accepted ADRs and contracts
- Usage: internal Railiance framework architecture home and handoff point for cross-repo planning - 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 ## InfoTechCanon Repository-Layout Alignment
those repo families into concrete repos while downstream ownership repos retain
their implementation responsibility. 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 ## How It Fits
- Upstream dependencies: `the-custodian` canon and State Hub conventions - Upstream standards: `info-tech-canon`, `the-custodian` canon, Custodian
- Downstream consumers: all `railiance-*`, future `rail-*`, future `rapp-*`, and future `reef-*` repos workplan conventions
- Often used with: `railiance-fabric`, `railiance-platform`, `railiance-cluster`, `state-hub` - Downstream policy publisher: `policy-nexus` (ADRs only, read-only)
- Downstream architecture consumers: all `railiance-*`, `rail-*`, `rapp-*`, and
--- `reef-*` repositories
- Coordination/index: State Hub
## Terminology - Common collaborators: `railiance-fabric`, `railiance-platform`,
`railiance-cluster`, `railiance-infra`, `railiance-enablement`
- 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
--- ---
## Getting Oriented ## Getting Oriented
- Start with: `README.md`, `INTENT.md` - Start with: `README.md`, `INTENT.md`, `SCOPE.md`
- Key files / directories: `docs/`, `history/`, `workplans/` - Architecture entry points: `docs/repository-axes.md`,
- Entry points: `docs/repository-axes.md`, `docs/reef-substrate-model.md`, `docs/adr/` `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 ```capability
type: governance type: governance
title: Railiance framework architecture decisions title: Railiance framework architecture decisions
description: Records framework-level architecture decisions and boundary guidance for changes spanning multiple Railiance repos. description: Owns framework ADR content and lifecycle while permanent publication is delegated read-only to policy-nexus.
keywords: [architecture, adr, governance, boundaries, framework] 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 The next obvious alignment work is to make accepted ADRs publication-ready,
implementation outward into the ownership repos once the framework boundary is clear. formalize how raw architecture demand is reviewed before it becomes a workplan,
and cleanly archive completed work without breaking State Hub conventions.

6
WORK-RECORDS.md
View file

@ -16,6 +16,7 @@
| workplan | RMASTER-WP-0021 | finished | — | workplans/RMASTER-WP-0021-rapp-declaration-schema.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-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-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 | 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-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-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-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-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-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 |

10
docs/adr/ADR-0001-repository-prefix-architecture.md
View file

@ -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 # ADR-0001: Repository Prefix Architecture
Date: 2026-07-25 Date: 2026-07-25

10
docs/adr/ADR-0002-rail-kubernetes-wave-1-boundary.md
View file

@ -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 # ADR-0002: Wave 1 `rail-kubernetes` Boundary
Date: 2026-07-25 Date: 2026-07-25

10
docs/adr/ADR-0003-rapp-first-wave-selection.md
View file

@ -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 # ADR-0003: First-Wave `rapp-*` Selection
Date: 2026-07-25 Date: 2026-07-25

10
docs/adr/ADR-0004-first-wave-reef-rollout.md
View file

@ -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 # ADR-0004: First-Wave `reef-*` Rollout
Date: 2026-07-25 Date: 2026-07-25

10
docs/adr/ADR-0005-derived-rail-composition.md
View file

@ -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 # ADR-0005: Derived Rail Composition
Date: 2026-07-26 Date: 2026-07-26

10
docs/adr/ADR-0006-reef-production-admission.md
View file

@ -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 # ADR-0006: Reef Production Admission
Date: 2026-07-26 Date: 2026-07-26

10
docs/adr/ADR-0007-rapp-declaration-contract.md
View file

@ -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 # ADR-0007: Rapp Declaration Contract
Date: 2026-08-13 Date: 2026-08-13

10
docs/adr/ADR-0008-private-by-default-exposure.md
View file

@ -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 # ADR-0008: Private-by-default Exposure
Date: 2026-08-15 Date: 2026-08-15

138
workplans/RMASTER-WP-0024-canon-and-policy-publication-alignment.md Normal file
View file

@ -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.