# 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.