Design provenance labels with typed identity

[George-RD]

Part of #182

Question

Data carries provenance/visibility labels bound to typed identity; context assembly and egress consult labels deterministically (Bell invariant I4; the provenance-not-LLM-judgment decision). Design, not implementation.

Users: Bell, Auditor. Promise: Immune system.

Resolve per the handoff shape: grill + domain-model, then to-spec; link the spec issue here.

Blocked by

• Design the typed owner identity #188
• Research: design inputs for the Immune-system lane #190

[coderabbitai]

Coding Plan

Summary

• Resolve the external ticket taxonomy to canon (AD-002, D-008, D-119) first, then state the invariant precisely, because the literal ticket labels do not exist in this repository.
• Design the label-to-identity binding by generalizing the proven source_scope/erasure-marker pattern, which already binds a label to a typed identity field and consults it deterministically and fail-closed.
• Preserve the canon invariants: fail-closed, no LLM judgment, digest-only references, append-only provenance, and kernel-derived labels.
• Deliver only design artifacts (decision-log entry plus an OpenSpec change with proposal, design, delta specs, and tasks), and defer all runtime code and data migration to a later apply ticket.

Design Choices

Design Choice 1: How should the external taxonomy in the ticket map to this repository's canon?

Options Considered:

1. Treat the labels as new first-class vocabulary and introduce them into canon.
2. Map the labels to existing canon concepts and record the mapping in the design.

Chosen Option: 2

Rationale: The design must reuse AD-002 and D-008 vocabulary. The design.md records "Bell invariant I4" as the local invariant name, maps "Bell"/"Auditor" to owner and audit review roles, and maps "Immune system" to the existing AD-034 containment axiom, without adding conflicting new taxonomy.

Design Choice 2: What structure should bind provenance and visibility labels to typed identity?

Options Considered:

1. Extend ClassifiedBriefcaseItem/DisclosureProvenance with a typed identity origin reference.
2. Generalize the learned_artifacts::Provenance::ProducedBy { source_scope } pattern so the bound field can reference the broader typed-identity set (Identity, Principal, RelationshipKind), not only a counterparty scope Ulid.
3. Add a new provenance edge table keyed by a typed identity id.

Chosen Option: 2

Rationale: The source_scope: Ulid erasure-marker pattern already binds a label to a typed identity field and consults it deterministically through SQL predicates and DB triggers. The design generalizes this proven pattern rather than inventing a new abstraction. The design.md records Option 1 as a considered alternative and states why the generalized-lineage approach fits the fail-closed, digest-only, no-LLM constraints better.

Design Choice 3: Should the design reconcile the duplicate classification enums `DataClassification` (event.rs) and `DisclosureClass` (disclosure_policy.rs)?

Options Considered:

1. Define a single source of truth and a deterministic mapping, and mark the other enum as derived.
2. Keep both enums separate and document that they must not be conflated.

Chosen Option: 1

Rationale: At the design level only, the design must specify one authoritative label vocabulary and a deterministic, kernel-side mapping, because deterministic consultation requires a single source of truth. The design defers the code migration to a later apply ticket and records this in "Out of Scope".

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Frame and grill the design

This phase resolves the unknowns before any spec text is written. It maps the external ticket taxonomy to canon, states the invariant precisely, and fixes the scope boundary of a design-only change. This phase produces working notes and clarifying questions, not final artifacts.

Task 1: Map the external taxonomy to canon and state the invariant

Establish the exact meaning of the ticket terms inside this repository.

• Record that "Bell invariant I4" names the local invariant: data carries provenance and visibility labels bound to typed identity, and context assembly and egress consult those labels deterministically, never through LLM judgment.
• Map the invariant to canon anchors AD-002 (disclosure axis), D-008 (deterministic authority), and D-119 (kernel-derived, fail-closed disclosure provenance).
• Map persona "Bell" to the owner review role and persona "Auditor" to the audit review role. Map promise "Immune system" to the existing AD-034 containment axiom.
• Note that "#182", "W6", and "W8" are external tracking codes with no repository artifact. Record that "W6" and "W8" are stated blockers and that the design must state its predecessor changes in canon terms instead.

Task 2: Surface and resolve design unknowns

Use the repository grilling skills to reduce ambiguity before formalization.

• Apply .omp/skills/interview-me to ask one architecture-changing question at a time. Prioritize the three assumptions above.
• Apply .omp/skills/blindspot-pass to surface unknown unknowns, focused on fail-closed behavior, digest-only references, and the no-LLM-judgment constraint.
• Confirm which typed identity axes a label may bind to: Identity, Principal, RelationshipKind, RelationshipTier, ChannelTrust, EntityType, and counterparty scope Ulid.
• Confirm the design-only boundary. Record that no runtime code, schema struct, or SQL changes are in scope for this ticket.

Task 3: Fix the scope boundary and predecessor changes

Define what the design must cover and what it must exclude.

• Identify predecessor changes in canon: implement-identity-store-and-principal (typed identity, D-006), implement-overlay-model (AD-023 provenance links and invalidation), implement-counterparty-key-model (identity-keyed erasure), and the identity-resolved-versus-eligible distinction from mine-and-match-reusable-authority-by-scope and ship-recurring-gmail-draft-proof.
• Record the classification-duplication reconciliation as a design decision with deferred code migration.
• List explicit out-of-scope items: no runtime implementation, no data migration, no new connector or credential model, no second live-authority object.

🤖 Prompt for AI agents

This phase produces working notes, not code or final artifacts. Implement it as
a design-framing exercise.

- Record that "Bell invariant I4" names the local invariant: data carries
provenance and visibility labels bound to typed identity, and context assembly
and egress consult those labels deterministically, never through LLM judgment.
Map this invariant to canon anchors AD-002, D-008, and D-119.
- Map persona "Bell" to the owner review role, persona "Auditor" to the audit
review role, and promise "Immune system" to the existing AD-034 containment
axiom.
- Note that "`#182`", "W6", and "W8" are external tracking codes with no
repository artifact. State the predecessor changes in canon terms instead of
these codes.
- Apply `.omp/skills/interview-me` to ask one architecture-changing question at
a time, prioritizing the three assumptions in the plan.
- Apply `.omp/skills/blindspot-pass` to surface unknown unknowns, focused on
fail-closed behavior, digest-only references, and the no-LLM-judgment
constraint.
- Confirm which typed identity axes a label may bind to: `Identity`,
`Principal`, `RelationshipKind`, `RelationshipTier`, `ChannelTrust`,
`EntityType`, and counterparty scope `Ulid`.
- Confirm and record the design-only boundary: no runtime code, schema struct,
or SQL changes are in scope for this ticket.
- Identify predecessor changes in canon:
`implement-identity-store-and-principal` (D-006), `implement-overlay-model`
(AD-023), `implement-counterparty-key-model`, and the
identity-resolved-versus-eligible distinction from
`mine-and-match-reusable-authority-by-scope` and
`ship-recurring-gmail-draft-proof`.
- Record the classification-duplication reconciliation as a design decision with
deferred code migration.
- List explicit out-of-scope items: no runtime implementation, no data
migration, no new connector or credential model, no second live-authority
object.

Phase 2: Domain-model the label-to-identity binding

This phase captures the vocabulary and the load-bearing decision before spec text. It defines the label model, the binding to typed identity, the deterministic consult points, and the invariants that any later implementation must preserve. This phase produces a decision-log entry and design notes.

Task 1: Define the provenance-and-visibility label model

Describe the label concept and its required contents.

• Define a provenance-and-visibility label as an immutable, kernel-derived value carried by data. State that a worker or LLM never assigns or narrows it.
• Reuse the existing classification vocabulary. Name one authoritative label enum and describe the deterministic mapping from the second enum to it, per Assumption 3.
• State the required label contents by reusing the D-077 and AD-140 shape: the producing event reference, the producing exchange reference, and the bound typed-identity field.

Task 2: Define the binding to typed identity

Describe how a label binds to a typed identity field, following the generalized-lineage approach.

• Generalize the Provenance::ProducedBy { source_scope: Ulid } pattern so the bound field can reference the broader typed-identity set, per Assumption 2.
• State that authorization metadata is never provenance metadata (D-077). The bound identity field records origin, not authority.
• Describe how context assembly, in crates/openspine-schemas/src/briefcase.rs::pack and crates/openspine-kernel/src/briefcase.rs, derives the label from the resolved typed identity instead of a hardcoded per-section value.
• Describe how egress, in crates/openspine-schemas/src/disclosure_policy.rs::check_egress, consults the bound label deterministically together with RelationshipKind and EgressClass.

Task 3: State the invariants a later implementation must preserve

Record the constraints derived from canon that constrain any future code.

• Fail-closed: a missing, unresolvable, or unclassified label blocks the operation. It never defaults open (D-095, D-119, D-137).
• No LLM or agent judgment: the check compares typed fields or digests only, following the counterparty_erasure.rs SQL-predicate and DB-trigger precedent.
• Digest-only and durable references: a persisted record or marker is the single source of truth, never a live re-derivation (D-106, D-119).
• Append-only provenance: later authorization or reconfirmation events never rewrite the original label (D-077).
• Kernel-derived, not caller-supplied: a caller value can only widen scrutiny, never narrow it (D-119).

Task 4: Author the decision-log entry

Record the design decision in canon.

• Add a new D-0XX entry in .raw/openspine-decision-log.md for "provenance and visibility labels bound to typed identity, consulted deterministically".
• Include Decision, Rationale, Consequences, and "Would change if" fields, matching the existing D-0XX format.
• Cite AD-002, AD-023, AD-140, D-008, D-077, and D-119.

🤖 Prompt for AI agents

This phase produces a decision-log entry and design notes that capture the
domain model. Define the label vocabulary, the binding mechanism, the
deterministic consult points, and the invariants before writing spec text.

- Define a provenance-and-visibility label as an immutable, kernel-derived value
carried by data, never assigned or narrowed by a worker or LLM.
- Name one authoritative label enum and describe the deterministic mapping from
the second enum (`DataClassification` in event.rs) to it, per Assumption 3.
- State the required label contents, reusing the D-077 and AD-140 shape: the
producing event reference, the producing exchange reference, and the bound
typed-identity field.
- Generalize the `Provenance::ProducedBy { source_scope: Ulid }` pattern in
`crates/openspine-kernel/src/store/learned_artifacts.rs` so the bound field can
reference the broader typed-identity set, per Assumption 2.
- State that authorization metadata is never provenance metadata (D-077): the
bound identity field records origin, not authority.
- Describe how context assembly in
`crates/openspine-schemas/src/briefcase.rs::pack` and
`crates/openspine-kernel/src/briefcase.rs` derives the label from the resolved
typed identity instead of a hardcoded per-section value.
- Describe how egress in
`crates/openspine-schemas/src/disclosure_policy.rs::check_egress` consults the
bound label deterministically, together with `RelationshipKind` and
`EgressClass`.
- Record the following invariants as constraints on any later implementation:
fail-closed on missing/unresolvable/unclassified labels (D-095, D-119, D-137);
no LLM or agent judgment, comparing typed fields or digests only, following the
`counterparty_erasure.rs` SQL-predicate and DB-trigger precedent; digest-only
and durable references as the single source of truth, never live re-derivation
(D-106, D-119); append-only provenance, where later authorization or
reconfirmation events never rewrite the original label (D-077); kernel-derived,
not caller-supplied labels, where a caller value can only widen scrutiny, never
narrow it (D-119).
- Add a new D-0XX entry in `.raw/openspine-decision-log.md` titled "provenance
and visibility labels bound to typed identity, consulted deterministically",
with Decision, Rationale, Consequences, and "Would change if" fields matching
the existing D-0XX format, citing AD-002, AD-023, AD-140, D-008, D-077, and
D-119.

Phase 3: Formalize into OpenSpec change artifacts

This phase converts the domain model into the formal OpenSpec change. It produces the proposal, the design document, the delta specs, and the task list, and positions the change in the dependency graph. This phase produces the reviewable design deliverable.

Task 1: Create the OpenSpec change and proposal

Create the change directory and the proposal document.

• Create a new change directory under openspec/changes/ with a kebab-case name, for example bind-provenance-labels-to-typed-identity.
• Author proposal.md with the required sections: ## Dependencies, ## Problem/Context, ## Proposed Solution, ## Acceptance Criteria, ## Out of Scope.
• State in the proposal that the change touches OpenSpine core, that it affects private data and external communications, and that it states the classification-reconciliation non-goal.
• List the predecessor changes from Task 1.3 under ## Dependencies.

Task 2: Author the design document

Author the design.md that carries the load-bearing design.

• Include authority, containment, audit, and failure-mode considerations, per openspec/config.yaml.
• Record the invariant statement and the taxonomy mapping from Phase 1.
• Record the chosen binding approach and the rejected alternatives from Assumptions 1, 2, and 3, with rationale.
• Record the invariants from Task 2.3 as design constraints.
• Cite the PRD and the decision log, including the new D-0XX entry.

Task 3: Author the delta specs

Author the delta specs for the affected capabilities.

• Add or update delta text under openspec/changes/<change>/specs/disclosure-policy/spec.md to require that egress consults labels bound to typed identity, deterministically and fail-closed.
• Add or update delta text under specs/briefcase-packing/spec.md to require that context assembly derives the label from the resolved typed identity, not from a hardcoded per-section value.
• Reference the typed-identity model in specs/identity-store/spec.md as the binding target, without adding authority to identity.
• Write each requirement in MUST/SHOULD/MAY language and include at least one #### Scenario: block per requirement.

Task 4: Author tasks.md and position the change

Author the implementation task list and place the change in the dependency graph.

• Author tasks.md with small implementation slices for the deferred apply ticket, including explicit verification tasks for the authority, containment, and audit boundaries, and a decision-log update task.
• Add the change to openspec/openspine-change-sequence.md with its predecessor dependencies from Task 1.3.
• Validate the change with openspec validate --changes <change-id> --strict.
• Link the created OpenSpec change back to the source ticket, per the ticket handoff instruction.

🤖 Prompt for AI agents

This phase converts the domain model from Phase 2 into the formal, reviewable
OpenSpec change deliverable. It produces the proposal, design document, delta
specs, and task list, and positions the change in the dependency graph.

- Create a new change directory under `openspec/changes/` with a kebab-case
name, for example `bind-provenance-labels-to-typed-identity`.
- Author `proposal.md` with the required sections: `## Dependencies`, `##
Problem/Context`, `## Proposed Solution`, `## Acceptance Criteria`, `## Out of
Scope`. State that the change touches OpenSpine core, affects private data and
external communications, and states the classification-reconciliation non-goal.
List the predecessor changes identified in Phase 1 under `## Dependencies`.
- Author `design.md`, including authority, containment, audit, and failure-mode
considerations per `openspec/config.yaml`. Record the invariant statement and
taxonomy mapping from Phase 1, the chosen binding approach and rejected
alternatives from Assumptions 1, 2, and 3 with rationale, and the invariants
from Phase 2 as design constraints. Cite the PRD and the decision log, including
the new D-0XX entry.
- Author the delta specs: add or update delta text under
`openspec/changes/<change>/specs/disclosure-policy/spec.md` requiring that
egress consults labels bound to typed identity, deterministically and
fail-closed; add or update delta text under `specs/briefcase-packing/spec.md`
requiring that context assembly derives the label from the resolved typed
identity, not a hardcoded per-section value; reference the typed-identity model
in `specs/identity-store/spec.md` as the binding target, without adding
authority to identity. Write each requirement in MUST/SHOULD/MAY language and
include at least one `#### Scenario:` block per requirement.
- Author `tasks.md` with small implementation slices for the deferred apply
ticket, including explicit verification tasks for the authority, containment,
and audit boundaries, and a decision-log update task.
- Add the change to `openspec/openspine-change-sequence.md` with its predecessor
dependencies.
- Validate the change with `openspec validate --changes <change-id> --strict`.
- Link the created OpenSpec change back to the source ticket, per the ticket
handoff instruction.

Research

OpenSpine records architecture decisions in canon files, not in CONTEXT.md/ADR files. The canon sources are .raw/openspine-agentos-design-log.md (AD-0XX), .raw/openspine-decision-log.md (D-0XX), and .raw/openspine-prd-v9.md. Formal work lands as OpenSpec changes under openspec/changes/<kebab-name>/ with proposal.md, design.md, tasks.md, and delta specs under specs/<capability>/spec.md. The decomposition and dependency graph live in openspec/openspine-change-sequence.md.

The relevant existing model has three separate concerns. Typed identity lives in crates/openspine-schemas/src/identity.rs (Identity, EntityType, RelationshipKind), principal.rs (Principal), and event.rs (ChannelTrust); identity carries no authority by design (D-006). Disclosure classification lives in crates/openspine-schemas/src/disclosure_policy.rs (DisclosureClass, ClassifiedBriefcaseItem, DisclosureProvenance, check_egress) and drives the deterministic egress gate. Origin/trust lineage lives in crates/openspine-kernel/src/store/learned_artifacts.rs (Provenance::ProducedBy { source_scope: Ulid }), enforced by SQL triggers and the erasure-marker table in counterparty_erasure.rs. Context assembly is briefcase packing (crates/openspine-schemas/src/briefcase.rs::pack, crates/openspine-kernel/src/briefcase.rs), where disclosure_class is currently assigned per section kind and does not bind to the resolved typed identity.

The ticket's external labels ("Bell invariant I4", personas "Bell"/"Auditor", promise "Immune system", "#182", "W6", "W8") do not exist in this repository. They map onto real canon: AD-002 (disclosure axis), D-008 (deterministic authority, no LLM judgment), and D-119 (kernel-derived, fail-closed disclosure provenance).

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

This phase produces working notes, not code or final artifacts. Implement it as
a design-framing exercise.

- Record that "Bell invariant I4" names the local invariant: data carries
provenance and visibility labels bound to typed identity, and context assembly
and egress consult those labels deterministically, never through LLM judgment.
Map this invariant to canon anchors AD-002, D-008, and D-119.
- Map persona "Bell" to the owner review role, persona "Auditor" to the audit
review role, and promise "Immune system" to the existing AD-034 containment
axiom.
- Note that "`#182`", "W6", and "W8" are external tracking codes with no
repository artifact. State the predecessor changes in canon terms instead of
these codes.
- Apply `.omp/skills/interview-me` to ask one architecture-changing question at
a time, prioritizing the three assumptions in the plan.
- Apply `.omp/skills/blindspot-pass` to surface unknown unknowns, focused on
fail-closed behavior, digest-only references, and the no-LLM-judgment
constraint.
- Confirm which typed identity axes a label may bind to: `Identity`,
`Principal`, `RelationshipKind`, `RelationshipTier`, `ChannelTrust`,
`EntityType`, and counterparty scope `Ulid`.
- Confirm and record the design-only boundary: no runtime code, schema struct,
or SQL changes are in scope for this ticket.
- Identify predecessor changes in canon:
`implement-identity-store-and-principal` (D-006), `implement-overlay-model`
(AD-023), `implement-counterparty-key-model`, and the
identity-resolved-versus-eligible distinction from
`mine-and-match-reusable-authority-by-scope` and
`ship-recurring-gmail-draft-proof`.
- Record the classification-duplication reconciliation as a design decision with
deferred code migration.
- List explicit out-of-scope items: no runtime implementation, no data
migration, no new connector or credential model, no second live-authority
object.
===============================================================================

Task: 2

This phase produces a decision-log entry and design notes that capture the
domain model. Define the label vocabulary, the binding mechanism, the
deterministic consult points, and the invariants before writing spec text.

- Define a provenance-and-visibility label as an immutable, kernel-derived value
carried by data, never assigned or narrowed by a worker or LLM.
- Name one authoritative label enum and describe the deterministic mapping from
the second enum (`DataClassification` in event.rs) to it, per Assumption 3.
- State the required label contents, reusing the D-077 and AD-140 shape: the
producing event reference, the producing exchange reference, and the bound
typed-identity field.
- Generalize the `Provenance::ProducedBy { source_scope: Ulid }` pattern in
`crates/openspine-kernel/src/store/learned_artifacts.rs` so the bound field can
reference the broader typed-identity set, per Assumption 2.
- State that authorization metadata is never provenance metadata (D-077): the
bound identity field records origin, not authority.
- Describe how context assembly in
`crates/openspine-schemas/src/briefcase.rs::pack` and
`crates/openspine-kernel/src/briefcase.rs` derives the label from the resolved
typed identity instead of a hardcoded per-section value.
- Describe how egress in
`crates/openspine-schemas/src/disclosure_policy.rs::check_egress` consults the
bound label deterministically, together with `RelationshipKind` and
`EgressClass`.
- Record the following invariants as constraints on any later implementation:
fail-closed on missing/unresolvable/unclassified labels (D-095, D-119, D-137);
no LLM or agent judgment, comparing typed fields or digests only, following the
`counterparty_erasure.rs` SQL-predicate and DB-trigger precedent; digest-only
and durable references as the single source of truth, never live re-derivation
(D-106, D-119); append-only provenance, where later authorization or
reconfirmation events never rewrite the original label (D-077); kernel-derived,
not caller-supplied labels, where a caller value can only widen scrutiny, never
narrow it (D-119).
- Add a new D-0XX entry in `.raw/openspine-decision-log.md` titled "provenance
and visibility labels bound to typed identity, consulted deterministically",
with Decision, Rationale, Consequences, and "Would change if" fields matching
the existing D-0XX format, citing AD-002, AD-023, AD-140, D-008, D-077, and
D-119.
===============================================================================

Task: 3

This phase converts the domain model from Phase 2 into the formal, reviewable
OpenSpec change deliverable. It produces the proposal, design document, delta
specs, and task list, and positions the change in the dependency graph.

- Create a new change directory under `openspec/changes/` with a kebab-case
name, for example `bind-provenance-labels-to-typed-identity`.
- Author `proposal.md` with the required sections: `## Dependencies`, `##
Problem/Context`, `## Proposed Solution`, `## Acceptance Criteria`, `## Out of
Scope`. State that the change touches OpenSpine core, affects private data and
external communications, and states the classification-reconciliation non-goal.
List the predecessor changes identified in Phase 1 under `## Dependencies`.
- Author `design.md`, including authority, containment, audit, and failure-mode
considerations per `openspec/config.yaml`. Record the invariant statement and
taxonomy mapping from Phase 1, the chosen binding approach and rejected
alternatives from Assumptions 1, 2, and 3 with rationale, and the invariants
from Phase 2 as design constraints. Cite the PRD and the decision log, including
the new D-0XX entry.
- Author the delta specs: add or update delta text under
`openspec/changes/<change>/specs/disclosure-policy/spec.md` requiring that
egress consults labels bound to typed identity, deterministically and
fail-closed; add or update delta text under `specs/briefcase-packing/spec.md`
requiring that context assembly derives the label from the resolved typed
identity, not a hardcoded per-section value; reference the typed-identity model
in `specs/identity-store/spec.md` as the binding target, without adding
authority to identity. Write each requirement in MUST/SHOULD/MAY language and
include at least one `#### Scenario:` block per requirement.
- Author `tasks.md` with small implementation slices for the deferred apply
ticket, including explicit verification tasks for the authority, containment,
and audit boundaries, and a decision-log update task.
- Add the change to `openspec/openspine-change-sequence.md` with its predecessor
dependencies.
- Validate the change with `openspec validate --changes <change-id> --strict`.
- Link the created OpenSpec change back to the source ticket, per the ticket
handoff instruction.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[George-RD]

Resolution. Grilled (Q1–Q9, coordinator standing in for the owner per the map's owner ruling) and domain-modelled. All nine decisions accepted as recommended.

The gap this closes (fact): a BriefcaseSection carries a disclosure_class sensitivity + a payload digest but no typed-identity origin — so check_egress can tell "Private" but not whose Private, and cannot stop other-counterparty/internal data in a reply to a stranger (the Bell failure mode) or cross-counterparty leakage. Immune system promise; users Bell, Auditor.

Design: a kernel-minted, immutable provenance label binds each classified datum's typed-identity origin (ProvenanceOrigin { Owner(PrincipalId), Counterparty(IdentityRef), System }) to its sensitivity and lineage, generalizing the proven Provenance::ProducedBy pattern. It is consulted deterministically (no LLM judgment) at context assembly (packing derives origin from resolved identity; unresolved fails closed) and at egress (a new ordered origin-vs-recipient stage after disclosure-coverage). Binds to typed owner identity (#197: reuses PrincipalId; IdentityRef is a sibling newtype; identity ≠ authority, D-006). Fills the two extension points the disclosure-gating spec (#204) named: the grant-side Caveat::ProvenanceLabelAllowlist (+ SupportedCaveatKind + effectively_allows_provenance_label, exact mirror of the egress-class caveat) and the ordered label-matching stage in the core; the dead gate() EgressClassifier stays deleted. Visibility-class values (customer/staff/owner) and the inbound UntrustedContext<T> wrapper are out of scope (tenancy-fenced / distinct lane).

Spec: #220 (ready-for-agent).

Implementation tickets (ready-for-agent, native edges wired):

• Record D-0XX: provenance labels bound to typed identity #221 — Record D-0XX in canon (no blockers)
• Introduce ProvenanceOrigin and IdentityRef typed vocabulary #222 — ProvenanceOrigin + IdentityRef types (blocked by Introduce PrincipalId newtype and OwnerPrincipal aggregate #199)
• Reconcile sensitivity vocabulary to authoritative DisclosureClass #223 — Reconcile sensitivity vocabulary to authoritative DisclosureClass (no blockers)
• Bind provenance label to typed-identity origin (generalize ProducedBy) #224 — Bind label to typed-identity origin, generalize ProducedBy (blocked by Introduce ProvenanceOrigin and IdentityRef typed vocabulary #222)
• Context assembly derives label origin from resolved typed identity #225 — Context assembly derives origin from resolved identity (blocked by Bind provenance label to typed-identity origin (generalize ProducedBy) #224)
• Add grant caveat ProvenanceLabelAllowlist and narrowing helper #226 — Grant caveat ProvenanceLabelAllowlist + helper (blocked by Introduce ProvenanceOrigin and IdentityRef typed vocabulary #222)
• Egress origin-closure stage: block cross-identity data deterministically #227 — Egress origin-closure stage, the proving tracer bullet (blocked by Context assembly derives label origin from resolved typed identity #225, Add grant caveat ProvenanceLabelAllowlist and narrowing helper #226, Prefactor: extend EgressClass and split the disclosure core from web-search preparation #205)

DAG: #199→#222; #222→#224,#226; #224→#225; #225,#226,#205→#227; #221 and #223 independent.