emergent-security/knowledge/cards/deployment.md

Protected deployments and production targets

Railiance workload owners own deployment and the authoritative target/runbook; NetKingdom supplies security contracts. Resolve the target and its consumers before deciding which guarantees apply. Build mode for the estate does not make an existing production cluster a disposable sandbox.

For a live production change obtain the founder's decision for that change and use the owner's current route. Local tests, a workplan marked done, a reference AUTONOMOUS result, or this knowledge package are not evidence of runtime authorization. Use the owner's current PDP/approval/credential integration and exact request binding, lifetime, rollback and evidence requirements.

Read-only diagnosis and inert dry runs can prepare a concrete proposal inside the task envelope. Missing context, engine outages, stale routes or missing approval must not turn into wider credentials or direct bypasses. Follow the PEP owner's published outage stance and record it. Never invent a stance.

Source owner IDs (cite the relevant owner, not an invented umbrella): railiance-master, the-custodian, access-engine, approval-engine.