Define derived rail and Qonto readiness architecture
This commit is contained in:
parent
0b95c3029c
commit
8901ae4b15
9 changed files with 845 additions and 0 deletions
31
docs/adr/ADR-0005-derived-rail-composition.md
Normal file
31
docs/adr/ADR-0005-derived-rail-composition.md
Normal 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.
|
||||
29
docs/adr/ADR-0006-reef-production-admission.md
Normal file
29
docs/adr/ADR-0006-reef-production-admission.md
Normal 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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue