31 lines
1 KiB
Markdown
31 lines
1 KiB
Markdown
# 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.
|