docs: align master with canon and policy publication
This commit is contained in:
codex
parent
6e230be13a
commit
7d32673812
12 changed files with 403 additions and 70 deletions
51
INTENT.md
51
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
|
||||
|
|
|
|||
198
SCOPE.md
198
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.
|
||||
|
|
|
|||
|
|
@ -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 |
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue