ad88639a53
INTENT.md frontmatter governs; layer.yaml is marked derived (derived: true, derived_from: INTENT.md) per amendment A11. standard_version removed from both forms per A12. Layer values are not re-spelled: INTENT.md 'Staff' and layer.yaml 'staff' agree after ASCII case-fold. This repository has no conformance checker yet (gaps.conformance-check-script), so no checker change was needed. pep-stance.yaml does not exist here and is untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 63291@bnt-lap001 Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
183 lines
6.4 KiB
Markdown
183 lines
6.4 KiB
Markdown
---
|
|
layer: Staff
|
|
role: null
|
|
security_layer_declaration: layer.yaml
|
|
declared_at: "2026-09-09"
|
|
---
|
|
|
|
# INTENT
|
|
|
|
> This file captures **why this repository exists**,
|
|
> the **direction it is moving toward**, and
|
|
> the **kind of system it is meant to become**.
|
|
> It is intentionally **aspirational and stable**, not a description of current implementation.
|
|
|
|
---
|
|
|
|
## One-liner
|
|
|
|
**The shared platform-services layer — the dependable foundation of stateful services (data, cache, secrets, object storage, messaging) that everything else builds on.**
|
|
|
|
---
|
|
|
|
## Why This Exists
|
|
|
|
Applications should not each reinvent, operate, and secure their own
|
|
databases, caches, secret stores, object storage, and message brokers.
|
|
|
|
When every application carries its own copy of these services, the result
|
|
is:
|
|
|
|
* duplicated operational burden,
|
|
* inconsistent durability and backup guarantees,
|
|
* and a sprawling, hard-to-secure surface.
|
|
|
|
This layer exists to provide those stateful services **once, operably, and
|
|
consistently**, so that everything built above it can assume a reliable,
|
|
backed-up, secure substrate instead of building one each time.
|
|
|
|
---
|
|
|
|
## The Mission
|
|
|
|
> *Where we are going.*
|
|
|
|
To become the **canonical home for shared, stateful platform services** —
|
|
where data persistence, caching, secret custody, object storage,
|
|
messaging, and their backup and recovery are provided as well-operated,
|
|
independently evolvable services behind stable interfaces.
|
|
|
|
This means:
|
|
|
|
* Stateful services are operated to clear **durability, availability, and
|
|
recovery** guarantees
|
|
* Secret material has a **dependable custody and delivery** mechanism
|
|
* Consumers depend on **stable service interfaces**, not on internal topology
|
|
* The layer can **evolve** — operators, engines, versions, topologies —
|
|
without breaking what is built on it
|
|
|
|
---
|
|
|
|
## Core Principles
|
|
|
|
### 1. Shared, Not Duplicated
|
|
|
|
Provide each stateful service once and well, rather than letting every
|
|
application carry and operate its own.
|
|
|
|
### 2. Stable Interfaces over Internal Detail
|
|
|
|
Consumers bind to service contracts. The operators, engines, and
|
|
topologies behind those contracts can change underneath without forcing
|
|
changes above.
|
|
|
|
### 3. Durable by Default
|
|
|
|
Persistence, backup, and **tested** recovery are part of providing a
|
|
service — not an afterthought added later.
|
|
|
|
### 4. Secure Custody
|
|
|
|
Secret material is held and delivered through a dependable authority,
|
|
never scattered across the consumers that need it.
|
|
|
|
In OAS terms this layer carries **Q1 Security and Compliance** on the Quality
|
|
dimension — approval gates, delegated apply, revocation semantics, and
|
|
front-door readiness. That practice was built before the dimension was named;
|
|
naming it does not change what S3 does, it makes the responsibility legible to
|
|
the rest of the fleet.
|
|
|
|
### 5. Operable and Observable
|
|
|
|
Every service is monitored, recoverable, and diagnosable as a first-class
|
|
property.
|
|
|
|
Observability itself is **not** this layer's to own. It is **Q2** and belongs to
|
|
`railiance-telemetry`; S3's obligation is to *emit* through the standard
|
|
contract rather than to build its own monitoring. The recoverability half is
|
|
**Q3**, currently unowned across the fleet.
|
|
|
|
### 6. Independently Evolvable
|
|
|
|
The layer can adopt new operators or engines, and migrate between them,
|
|
without forcing rewrites in the things that depend on it.
|
|
|
|
---
|
|
|
|
## What This Is (Conceptually)
|
|
|
|
This layer is:
|
|
|
|
* a **shared platform-services layer**
|
|
* a dependable **substrate of stateful infrastructure**
|
|
* a **custody and delivery point** for secret material
|
|
* a **backup and recovery home** for platform data
|
|
* a **stable interface surface** for the services consumers depend on
|
|
|
|
---
|
|
|
|
## What This Is Not
|
|
|
|
This layer is not:
|
|
|
|
* an application or business-capability provider
|
|
* the infrastructure or cluster runtime beneath it
|
|
* an identity or authorization authority
|
|
* a place for application-specific logic
|
|
|
|
It is the **stateful foundation** that other systems rely on.
|
|
|
|
---
|
|
|
|
## Direction of Evolution
|
|
|
|
This layer is expected to evolve toward:
|
|
|
|
* **Consolidation** of stateful services behind well-operated operators
|
|
* Stronger **durability, backup, and disaster-recovery** guarantees
|
|
* Dependable **runtime secret custody and delivery**
|
|
* Clear, **versioned service interfaces** for consumers
|
|
* **Self-healing and observable** platform services
|
|
|
|
---
|
|
|
|
## Guiding Question
|
|
|
|
> **How can the stateful foundation an entire landscape relies on be made dependable, secure, and recoverable — while remaining free to evolve underneath everything built on it?**
|
|
|
|
---
|
|
|
|
## Security layer declaration
|
|
|
|
Declared in our own voice, per §2 of the NetKingdom Security Layer Model v0.7.
|
|
The machine-readable form is [layer.yaml](layer.yaml).
|
|
|
|
**railiance-platform is Staff.** What this repository produces is
|
|
specifications, decisions, workplans, credential-change requests and acceptance
|
|
evidence. It is not deterministic in the §1 sense: the work here is judgment
|
|
about what should be provisioned, for whom, under what custody, and that is
|
|
Staff work however much of it lands as YAML.
|
|
|
|
The obvious objection is that we operate OpenBao and the shared databases, and
|
|
operating a store looks like producing state. §4 answers it directly and we
|
|
accept the answer: there is deliberately no operator-of-third-party-Tooling
|
|
shape, because a clean operator shape would turn a tracked gap into a permanent
|
|
allowance. Someone must run OpenBao. That we are the someone is a declared gap
|
|
whose review keeps returning, not a claim to the Tooling layer.
|
|
|
|
**We are PEP-shaped** (§5, §6.4). Applying a policy, seeding or rotating a
|
|
workload credential, and activating a delivery lane are protected side effects
|
|
caused on this side. Our unreachable-engine stance map is **not yet published**,
|
|
and that is recorded as an open obligation in `layer.yaml` rather than left
|
|
silent. Every protected side effect here is currently attended and
|
|
founder-gated, so no unattended branch has had to decide without a reachable
|
|
engine — which is why the gap has not bitten, and is not a substitute for the
|
|
map.
|
|
|
|
**Conformance state: declared gap.** Six direct Tooling contacts, one of them a
|
|
§5.2 conduit and one a §5.1 read-only diagnostic; the rest are §5.3 gaps with
|
|
named intended owners and review dates. The uncatalogued contacts — the cluster,
|
|
State Hub, the forge and the backup destinations — are listed too, so the check
|
|
is total rather than selectively silent.
|
|
|
|
If any of this is wrong, contest it. A correction is worth more than a label.
|