# Zones, temperature, and environment

zone-engine is retained offline reference conformance for security-zone identity
and membership. It provides fixtures, lineage checks, explicit profile projection,
and exception checks. It does not expose a live zone API, authorize actions,
choose a PEP stance, or place workloads. A question about whether a live zone
authorization endpoint exists goes to zone-engine. That endpoint is absent, and
offline conformance is the whole answer. The PEP owner keeps the authorization
stance when an actual allow or deny is requested.

Security-zone identity, tenant scope, target environment, and HOT/WARM/COOL/COLD
temperature are separate facts. Resolve each from authoritative declarations.
Do not infer them from a hostname, repository path, model, or a fixture result.
Temperature describes change costs and guarantees, not a permission multiplier.
No implicit mapping from a Railiance reef or runtime to a security zone exists.

Use the owner-provided offline manifest and profile only for conformance checks.
A proposed live claim mapping remains a gap until its owner publishes it.
Missing membership or expired exception evidence must not be repaired by an
agent inventing scope or extending a lease. Route the gap to the declaration
owner; stance remains with the policy/PEP owner.

Source owner IDs (cite the relevant owner, not an invented umbrella): `zone-engine`, `net-kingdom`.