Layer declaration (gate-house). INTENT.md now carries the declaration in its own voice with layer.yaml as the machine-readable form, adapted from ops-warden's reference. railiance-platform is Staff: operating OpenBao is not a claim to the Tooling layer, because §4 is explicit that no operator-of-third-party-Tooling shape exists and that someone running it stays a declared gap. Six direct Tooling contacts are mapped by capability rather than by file — one §5.2 conduit, one §5.1 diagnostic, four §5.3 gaps with intended owners and review dates — and the uncatalogued contacts are listed so the check is total. We are PEP-shaped and the unreachable-engine stance map is NOT published; that is recorded as an open obligation to build against v0.8, not left silent. Placement admission. canned-prompts was added as a PostgresConsumer on platform-pg-2 in rapp-postgres 1b68b4c without a placement owner here, which is exactly the cross-repo drift the assurance check exists to catch; the check had been failing on it. Registered with its real boundary evidence, corrected the stale test expectation that pinned the overflow cell at one consumer, and updated the SCOPE occupancy line to 2/4. Also records owner input received today: key-cape's issuer view on CCR-2026-0020's presenting actor, and their confirmation that codex-railiance-platform correctly stays tenant:coulomb, so the flagged T02 discrepancy is closed as not-a-defect. The whynot-design npm field is NOT changed. Two dated live receipts here name NPM_AUTH_TOKEN as the field, including an attended founder fetch; that is recorded against the counterparty claim rather than either side being flipped before the session settles it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WLUjpv3ssxNRAEPPgLFnEB Assistant: claude-code Assistant-Model: opus Assistant-Process: 1275505@bnt-lap001 Assistant-Session: 97265baa-f08f-4032-b290-a1e2965a69c5
184 lines
6.4 KiB
Markdown
184 lines
6.4 KiB
Markdown
---
|
|
layer: Staff
|
|
role: null
|
|
security_layer_declaration: layer.yaml
|
|
standard_version: "0.7"
|
|
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.
|