Define derived rail and Qonto readiness architecture

This commit is contained in:
codex 2026-07-26 11:45:07 +02:00
parent 0b95c3029c
commit 8901ae4b15
9 changed files with 845 additions and 0 deletions

View file

@ -0,0 +1,31 @@
# ADR-0005: Derived Rail Composition
Date: 2026-07-26
Status: Accepted
## Context
Knative provides distinct workload activation and revision semantics but runs
on Kubernetes. Treating it as an unrelated peer rail would duplicate generic
workload lifecycle and substrate assumptions.
## Decision
Railiance distinguishes base and derived rails.
`rail-kubernetes` is the default base rail for platform workloads.
`rail-knative` is a derived rail that inherits a versioned
`rail-kubernetes` common contract and overrides only Knative-specific
activation, revision, autoscaling, traffic, cold-start, and rollback semantics.
The detailed contract is
[`docs/rail-composition-contract.md`](../rail-composition-contract.md).
## Consequences
- New platform workloads continue to use `rail-kubernetes` unless a specialized
rail is justified.
- Derived rails declare base-rail compatibility rather than copying lifecycle
contracts.
- Fabric and conformance tooling must understand rail dependency and readiness.
- Knative installation stays with the S2 substrate owner.

View file

@ -0,0 +1,29 @@
# ADR-0006: Reef Production Admission
Date: 2026-07-26
Status: Accepted
## Context
Fabric topology can say that a reef hosts a rail or binds a workload, but that
does not demonstrate capacity, isolation, recoverability, or approval for a
critical internet-facing service.
## Decision
Rail and `rapp` bindings use explicit readiness states: `declared`,
`installed`, `verified`, `production-approved`, and `deprecated`.
Critical workloads require machine-readable conformance evidence plus explicit
acceptance of residual risks that cannot be automated. Mixed-rail reefs use
defined split triggers.
The detailed contract is
[`docs/reef-production-readiness-contract.md`](../reef-production-readiness-contract.md).
## Consequences
- `hosts_rail` and `binds_rapp` no longer imply deployability.
- `reef-railiance` may host Knative in wave 2, but Qonto cannot be called
production-approved solely from that declaration.
- Repeated evidence collection should become functional automation.