docs: complete canon alignment housekeeping
This commit is contained in:
parent
490c2d97b1
commit
debbc13b40
14 changed files with 397 additions and 81 deletions
78
history/260818-demand-canon-policy-alignment.md
Normal file
78
history/260818-demand-canon-policy-alignment.md
Normal file
|
|
@ -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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue