Framework architecture for railiance applications, railiance rails, railiance tooling. This repo explains and evolves the concepts in and around railiance.
Record the founder's Kubernetes change-gate decision (2026-09-21, GOVERN @ estate) as revision accepted-3. At production-approved, changes go through CONSTRUCT @ manifest repository, reconciled by ArgoCD, which is external-audited. A direct ADMINISTER is allowed only with activation=BREAK_GLASS. The change path is still not an authorization decision. Four open points are referred to the custodian and not resolved. 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.