railiance-master/docs/netkingdom-security-consumption-contract.md

NetKingdom Security Consumption Contract

Date: 2026-08-29 Status: Adopted under ADR-0009 / RMASTER-WP-0026-T03

Purpose

Say what every Railiance rail, rapp, and reef owes when it consumes NetKingdom security, without copying engine schemas or turning this repository into a second decision point.

The statute is net-kingdom/canon/standards/security-layer-model_v0.7.md §20.2 and §6.4. The working companion is net-kingdom/SECURITY-COMPANION.md v0.2 §9. On disagreement the statute governs.

This contract does not decide:

• whether a binding may run in production — that is ADR-0006;
• who may reach a listener we control — that is ADR-0008;
• how the four Railiance axes map onto Taxonomy, Tooling, Engine, and Staff — that remains unset in the open-questions record.

Three distinct questions

Question	Owner	Must not be read as
May this binding run in production?	Railiance admission (ADR-0006)	permission for an actor to act
Who may reach the listener we control?	Railiance exposure (ADR-0008)	an authorization decision
May this actor perform this action on this resource?	access-engine	admission or exposure

production-approved and exposure: public MUST NOT be treated as authorization decisions. Compiled admission or exposure data that resolved whether an actor may act would be statute §6.1 — deciding early.

Consumption rules

For any Railiance consumer of NetKingdom security, without exception:

1. Authorization decisions come from access-engine and from nowhere else. No rail, rapp, reef, or ownership repo may render or cache an authorization verdict. A registry, schema, or cache that resolves a result before the engine runs has decided early (statute §6.1).
2. Approvals are objects in approval-engine, consumed as claims. They are not a Railiance axis and not an audit-core verdict. Callers needing current approval state ask approval-engine.
3. Credentials are materialized by secrets-engine after a decision, never as a substitute for one. A lease or certificate is an artifact of authority, not its source.
4. Evidence goes to audit-core under the bound in statute §9.6. An archive proves records were not altered or truncated after arrival. It does not prove an event was sent. Absence of a record is not non-occurrence.
5. A runtime that causes a protected side effect is PEP-shaped and owes statute §6.4 in its own repository: no side effect without a decision record or a recorded unreachable-engine stance; no replay outside the decision's binding and lifetime; a published stance map inventoried in statute §13.1; reconstructability within the evidence bound.

This repository is not PEP-shaped. layer.yaml records that. Implementation rails, rapps, and reefs that do cause protected side effects inherit these obligations themselves. This contract does not publish a stance map.

What this repository does not host

• a policy decision point
• an approval store
• a credential lifecycle API
• an evidence archive
• an actuation or containment surface

Observation-in-production and automatic containment are estate-wide zeros (companion §10). Do not plan Railiance operations as if they existed.

Engine schemas stay with their owners

This file names the engines and the rules. It does not restate their request, decision, approval, credential, or evidence schemas. Those contracts live in the owning repositories and, for shared claim vocabulary, in Taxonomy artifacts statute §17 still requires.

Related

• ADR-0009 — assent
• ADR-0006 — admission
• ADR-0008 — exposure
• Open questions — §20.3, unset