Framework architecture for railiance applications, railiance rails, railiance tooling. This repo explains and evolves the concepts in and around railiance.
The custodian's estate sweep of flex-auth's FLEX-WP-0030 boundaries review
records this repository as declaring a value outside the §3 vocabulary, on
the reading that §3 admits only {Staff, Engine, Tooling}. §3 enumerates four
layers, and Taxonomy is the first row of its table with §3.1 to itself, in
every version of the standard from v0.1 through v0.8. §4 assigns the value to
info-tech-canon and net-kingdom, §7 carries it as a fourth plane line, §17 is
titled for it, and gate-house's own INTENT.md uses it.
ADR-0010 records the position with those citations. The declaration is not
changed: it is the evidence of what this repository holds itself to be, and
changing it now would pre-empt the ruling. RMASTER-WP-0027 holds the wait and
says what to do either way.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
|
||
|---|---|---|
| activity-definitions | ||
| demand | ||
| docs | ||
| history | ||
| reviews | ||
| schemas | ||
| tools | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| INTENT.md | ||
| layer.yaml | ||
| LICENSE | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
railiance-master
Architecture home for the Railiance framework.
This repository defines how Railiance concepts map to repositories, how the different repo families compose, and where new architecture decisions should be recorded before they are spread across implementation repos.
- Intent and direction
- Current scope and authority boundaries
- Reviewed architecture-demand intake
- NetKingdom security-layer alignment review
- RMASTER-WP-0026 — security-layer alignment
Current Architecture Baseline
- docs/repository-axes.md
- docs/reef-substrate-model.md
- docs/rail-kubernetes-boundary.md
- docs/rapp-first-wave-candidates.md
- docs/reef-first-wave-rollout.md
- docs/fabric-state-hub-adaptation.md
- docs/repo-family-bootstrap-contract.md
- docs/rail-composition-contract.md
- docs/reef-production-readiness-contract.md
- docs/exposure-posture-contract.md
- docs/netkingdom-security-consumption-contract.md
- docs/netkingdom-axis-layer-open-questions.md
- docs/qonto-knative-runtime-contract.md
- docs/adr/ADR-0001-repository-prefix-architecture.md
- docs/adr/ADR-0002-rail-kubernetes-wave-1-boundary.md
- docs/adr/ADR-0003-rapp-first-wave-selection.md
- docs/adr/ADR-0004-first-wave-reef-rollout.md
- docs/adr/ADR-0005-derived-rail-composition.md
- docs/adr/ADR-0006-reef-production-admission.md
- docs/adr/ADR-0007-rapp-declaration-contract.md
- docs/adr/ADR-0008-private-by-default-exposure.md
- docs/adr/ADR-0009-netkingdom-security-layer-interaction.md
- layer.yaml
Current Explorations
- history/260724-InitialExplorationOfOperationModels.md
- history/260724-InitialExplorationOfWrapperConcepts.md
Purpose
railiance-master is the canonical place to define:
- repo-family vocabulary such as
railiance-*,rail-*,rapp-*, andreef-* - cross-repo architectural boundaries
- the relationship between ownership, execution mode, workload packaging, and substrate realities
- the migration direction when current repos must be split or renamed
Implementation repos should follow the architecture recorded here rather than each inventing local meanings for the same terms.