zone-engine/docs/pip-claim-boundary.md

PIP claim boundary — zone identity and membership

This note maps the facts this Engine/PIP already emits onto the facts a future request-claim must carry. It is not a schema, not a wire format, and not estate canon.

Statute §17 assigns the request-claim schema to Taxonomy and records that ownership as proposed, not assigned. Statute §18 says zone stance enters a decision as a claim on the request or a rule in a versioned access-engine policy package, never as compiled registry content. Inventing a competing dialect here is the drift §17 exists to prevent.

Offered to gate-house / net-kingdom (Taxonomy publication) and to access-engine (currently flex-auth, the consumer of the claim). Assent is not required to keep the 2026-08-23 freeze.

Facts this PIP owns today

Emitted by tools/resolve_zones.py as a reference membership/admission record, given already-located declarations and already-resolved Repo Manager projections:

Field	Meaning
identity_bindings	Authoritative workload identity bindings
workload_ref	Explicit workload reference (rapp_id, name, deployable, applicability)
declared_zone	Responsible party's declared membership
effective_zone	Admitted zone, or unknown / none
admission	satisfied, unsatisfied, unknown, or not-applicable
admission_reason	Why that result, without inference
membership_revision	Digest bound to identity, membership, workload ref, and source revision
source	Declaration path or projection source
source_revision	Caller-supplied source revision; absence yields no source-bound digest
guarantees	What the record actually promises (non-inference, source binding, …)

Optional control-profile projection (policy_owner, pep_owner, policy_ref, stance, failure mode) is not a PIP fact. It is owner data copied through for evidence, and only the referenced owner policy or PEP configuration may change a live effect.

Input zones.reviewed / zones.review_due are validated and are not currently copied onto the output record. Freshness the resolver does bind is source_revision via membership_revision.

Mapping onto a future request-claim

Until Taxonomy publishes the schema, this is the contribution, not a type:

Claim slot (statute §17)	This PIP's field	Must not carry
Issuer	this repository, plus source / source_revision	a second PDP identity
Subject	identity_bindings and workload_ref	path, repo, reef, actor, or lane as a substitute subject
Zone membership	declared_zone, effective_zone, admission, admission_reason	stance, failure mode, allow/deny
Freshness	source_revision and membership_revision	an implicit "current" with no revision
Effect of the zone	—	not a PIP field; access-engine policy package or a versioned rule (statute §18)

A decision that turned on a zone must name the policy-package version that read it. Membership may be compiled into the registry access-engine already loads only as a fact. Compiled data that determines an outcome is still deciding (statute §6.1).

Forbidden

• Shipping a zone-engine claim JSON Schema, protobuf, or /claims endpoint.
• Encoding stance or failure mode as if they were membership.
• Compiling these facts into registry content that changes allow/deny without a policy-package revision.
• Treating a missing claim as permission. unknown and not-applicable stay distinct; absence is not z0.

The freeze in history/2026-08-29-layer-change-artifacts.md holds while this mapping waits on Taxonomy.