41 lines
1.2 KiB
Markdown
41 lines
1.2 KiB
Markdown
---
|
|
id: RMASTER-ADR-0005
|
|
title: "Derived Rail Composition"
|
|
status: accepted
|
|
revision: "accepted-1"
|
|
owner: railiance-master
|
|
last_reviewed: "2026-07-26"
|
|
review_interval: 6m
|
|
---
|
|
|
|
# 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.
|