Framework architecture for railiance applications, railiance rails, railiance tooling. This repo explains and evolves the concepts in and around railiance.
schemas/rapp.schema.json defines one normative shape for the rollout, smoke and rollback contracts in place of the three mutually unreadable variants found across the live rapps, promotes contract_version, readiness_state, data_classification and criticality to required, and forbids the rapp- prefix on workload_identity.name. composition replaces the flat members list per amendment f88f938d: purpose, member_repos with deployables, and pinned upstream_components. Repos are many:many with rapps; deployables are 1:1, which is what makes the T06 coverage check well-formed. ownership_repo left permissive pending an architecture-owner call; the tighter alternative is written up in schemas/README.md. Validated against all three live declarations: openbao 10 errors, postgres 10, qonto 4 — precisely the reported drift and nothing else. Also found: three further rapp-* repos (secrets-engine, tenant-engine, user-engine) carry no declarations at all, which the routed survey missed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| activity-definitions | ||
| docs | ||
| history | ||
| schemas | ||
| tools | ||
| workplans | ||
| .custodian-brief.md | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| INTENT.md | ||
| 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.
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/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
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.