Enterprise IG: Enterprise Pain Points Catalog v0.1 (Draft for Review)

[raghu-chandra-mcp]

MCP Enterprise Interest Group - Enterprise Pain Points Catalog

Version 0.1 (Draft)

Date: May 20, 2026

Source: First Monthly Meeting + Discord Contributions

---

Overview

This catalog documents enterprise pain points identified by practitioners deploying the Model Context Protocol in production environments. It serves as the Enterprise IG's first deliverable and provides an evidence base for prioritizing MCP specification work.

Pain points are organized by category and attributed to the contributing organization. Each entry describes the problem, the real-world impact, and where applicable, the gap in the current MCP specification.

---

1. Enterprise Authentication and Identity Visibility

Champion: Aaron Parecki (Okta)

1.1 MCP Server Connections Are Invisible to Enterprise Admins

Contributed by: Aaron Parecki, Okta

Problem: Enterprise administrators can control who logs into SaaS applications (e.g., Jira, Salesforce) through their identity provider, but they have no visibility or control over who connects MCP servers to those same applications. An employee can connect an MCP server to Jira without the enterprise admin knowing it exists.

Impact: The enterprise loses its security boundary. Access control policies that apply to human users do not extend to MCP tool connections, creating an unmonitored data access path that bypasses existing governance.

Spec Gap: No protocol-level mechanism for enterprise administrators to discover, authorize, or revoke MCP server connections within their organization.

1.2 Shadow AI and Credential Mismatch

Contributed by: Varun Wadhwa, TraceForce

Problem: Employees sign into AI clients (ChatGPT, Claude) using enterprise credentials but connect to MCP servers using personal credentials, or vice versa. This creates an identity mismatch where the enterprise session and the MCP session are linked to different identities.

Impact: Audit trails cannot reliably attribute MCP tool calls to a specific enterprise user. Policy enforcement breaks because the MCP connection operates under a different identity context than the enterprise session.

Spec Gap: No standardized mechanism to enforce that MCP connections inherit and maintain the enterprise identity context of the parent AI client session.

---

2. Identity Propagation Across Agent Chains

Champion: Anishma Reddy (EmpowerID)

2.1 Recursive Agent Delegation and Identity Lineage

Contributed by: Anishma Reddy, EmpowerID

Problem: When a parent agent delegates tasks to child agents, and those child agents spawn further agents, there is no standardized way to maintain identity lineage across the chain. Least-privilege enforcement requires knowing which human or system identity authorized the original action, but this information is lost as delegation recurses.

Impact: If the parent agent's authorization is revoked, the entire chain of child agents must also be revoked, but there is no protocol-level mechanism to propagate revocation at the speed required for security enforcement. The problem compounds across trust domain boundaries.

Spec Gap: No identity lineage or delegation chain tracking in the MCP specification. No standardized revocation propagation across agent hierarchies.

2.2 Identity Propagation and Session Context

Contributed by: Varun Wadhwa, TraceForce

Problem: Verified identity is not reliably surfaced and conveyed across MCP clients, servers, and downstream services. When an MCP tool call reaches a downstream service, the service cannot verify which human identity authorized the action or whether the authorization is still valid.

Impact: Policy enforcement and audit at downstream services operate without reliable identity context, making it impossible to answer "who authorized this action" at any point in the chain.

Spec Gap: No standardized mechanism for identity propagation across MCP connection boundaries.

---

3. Audit, Compliance, and Verifiable Records

Champion: Aman Sharma (Blue Shield of California)

3.1 No Standardized Audit Record Format

Contributed by: Camilo Ayerbe Posada

Problem: Current audit capabilities in MCP are limited to operator-controlled server logs and gateway captures. These are first-party records that prove what the operator sees, but in regulated environments, enterprises need standardized records where the actor signs the action, including who, what, with what arguments, what results, and when, that are verifiable by an independent third party.

Impact: Regulated enterprises cannot produce audit evidence that satisfies third-party verification requirements. Compliance teams cannot reconstruct the full chain of actions across multiple MCP servers with confidence that the records have not been altered.

Spec Gap: No protocol-level standard for signed, verifiable audit records that include actor identity, action, arguments, results, and timestamps.

3.2 PHI Compliance Across Multi-Step MCP Chains

Contributed by: Aman Sharma, Blue Shield of California

Problem: In healthcare environments, a single user query can trigger a multi-step MCP chain: summarization, EHR data retrieval, de-identification, and other processing steps that may touch five to seven different tools or services. The entire chain must maintain PHI (Protected Health Information) compliance, but there is no protocol-level signal that identifies content as PHI when it crosses between chain steps.

Impact: Enterprise teams cannot clearly identify the boundaries of what PHI goes in and what comes out at each step in the chain. Audit trails for PHI-bearing workflows are incomplete. HIPAA compliance is difficult to demonstrate when the protocol itself provides no content classification mechanism.

Spec Gap: No protocol-level content classification or tagging mechanism (e.g., "this content contains PHI") that persists across MCP tool call chains.

3.3 Identity Primitives for End-to-End Process Tracking

Contributed by: Camilo Ayerbe Posada

Problem: Identity primitives do not follow the entire MCP process from initiation to completion. The human-to-agent and agent-to-tool relationships are not captured in a way that allows the full process to be reconstructed with cryptographic certainty.

Impact: Compliance with regulations like the EU AI Act (enforcement beginning August 2, 2026) requires attributable and auditable AI operations. Without identity primitives that persist through the full MCP chain, enterprises cannot demonstrate compliance.

Spec Gap: No end-to-end identity primitive that travels with the MCP request through all processing steps.

---

4. Gateway and Proxy Behavior

Champion: TBD (Derek Lewis, Silex Data Solutions and Lin Sun, Solo.io contributed via Discord)

4.1 OBO Token Exchange Patterns

Contributed by: Derek Lewis, Silex Data Solutions (via Discord)

Problem: Two conflicting patterns exist for On-Behalf-Of (OBO) token exchange in enterprise MCP deployments. Some gateways delegate the OBO token exchange to the MCP server itself, while others perform the exchange upstream of the MCP server. There is no standard for which approach is correct.

Impact: Interoperability between enterprise MCP deployments breaks when gateways and servers expect different OBO patterns. Enterprises building multi-vendor MCP infrastructure cannot guarantee consistent token handling.

Spec Gap: No specification for how OBO token exchange should be handled in gateway/proxy deployments.

---

5. Configuration Portability

Champion: TBD

5.1 Cross-Client Credential and Configuration Management

Contributed by: Elisheba Anderson, Mass Ave Labs

Problem: Deploying the same MCP server across different clients (VS Code, Cursor, Claude Code, Claude Desktop) requires setting up API credentials and configurations separately for each client. There is no shared or portable configuration format.

Impact: Developer experience degrades as MCP adoption grows. Enterprises deploying MCP servers to hundreds of developers must maintain multiple configuration formats, increasing the risk of credential exposure and misconfiguration.

Spec Gap: No standardized portable configuration format that works across MCP clients.

---

6. Scalability and Resilience

Champion: Peder H P (Saxo Bank, contributed via Discord)

6.1 Interceptors and Enterprise Middleware

Contributed by: Peder H P, Saxo Bank (via Discord)

Problem: Enterprises need middleware capabilities for PII redaction, hallucination detection, and compliance enforcement, but the MCP specification does not support standardized interceptor patterns. Saxo Bank built a non-MCP solution for this, but it is not portable or interoperable.

Impact: Every enterprise deploying MCP middleware builds a custom solution. These solutions are not portable across MCP implementations, creating vendor lock-in and increasing maintenance burden.

Spec Gap: No interceptor or middleware specification in MCP.

---

7. EU AI Act Compliance

Champion: Camilo Ayerbe Posada, cayerbe (GNS-Foundation contributed via Discord)

7.1 Attributable and Compliant AI Operations

Contributed by: Camilo Ayerbe Posada

Problem: The EU AI Act, with enforcement beginning August 2, 2026, requires that AI operations in regulated environments be attributable and auditable. MCP connections must be compliant with these requirements, but the protocol does not provide the identity, audit, or traceability mechanisms needed.

Impact: European enterprises deploying MCP in regulated environments face compliance risk. Without protocol-level support for EU AI Act requirements, each enterprise must build custom compliance layers.

Spec Gap: No alignment between MCP specification and EU AI Act requirements for attributable AI operations.

---

Participants Contributing to This Catalog

Name	Organization	Pain Point Categories
Aaron Parecki	Okta	Auth visibility, enterprise-managed connections
Aman Sharma	Blue Shield of California	PHI compliance, audit trails, healthcare workflows
Anishma Reddy	EmpowerID	Recursive agent delegation, identity lineage, revocation
Camilo Ayerbe Posada	(Decentralized identity startup, Rome)	Audit compliance, identity primitives, EU AI Act
Elisheba Anderson	Mass Ave Labs	Config portability, cross-client credentials
Varun Wadhwa	TraceForce	Shadow AI, identity propagation, session context
Peder H P	Saxo Bank	Interceptors, scalability (via Discord)
Derek Lewis	Silex Data Solutions	OBO token exchange, gateway behavior (via Discord)
Lin Sun	Solo.io	Gateway/proxy patterns (via Discord)

---

---

MCP Enterprise Interest Group
Co-facilitated by Raghu Chandra and Yann Jouanin
Charter PR: #2626

[cayerbe]

@raghu-chandra-mcp — following up on the enforced-vs-declared point from the thread. Three items for the v0.1 → v1.0 pass, all inside audit/identity (3.x) and my EU AI Act category (7). Place and number as you see fit.

1. Proposed new entry (suggest 3.4):

3.4 Governance That Passes Audit but Is Not Enforced on the Read Path

Contributed by: Camilo Ayerbe Posada

Problem: Data-handling obligations in MCP — erase-on-request, retention limits, PHI/tenant scoping — are declared (by labels, policy engines, or audit logs) but not verified as enforced at retrieval. Current mechanisms confirm an action was requested and logged, not that the data is absent or contained. Canonical failure: a deletion that passes its own audit yet returns the deleted content at full confidence on the next retrieval, because it survived in a derived or replicated store the action never reached — summaries, embeddings, KV-cache, replicas, or a downstream tool that re-derived it from raw. Every layer has an admission gate (content entering is classified, tagged, logged); none has an eviction gate (content leaving, provably, across derivations).

Impact: Compliance dashboards read "satisfied" off the declaration layer while the data is live at the retrieval layer. A classification or deletion applied at the first hop does not hold across a multi-step MCP chain — derived artifacts and downstream tools inherit the data without inheriting the policy. Regulated enterprises can show an obligation was requested, not met, which fails third-party verification. This is the enforcement-verification counterpart to the signed-record (3.1), PHI-classification (3.2), and identity-primitive (3.3) gaps: those make actions attributable and tagged; this makes the effect of a governance action verifiable.

Spec Gap: No protocol-level mechanism to verify, on the read path, that a declared data-handling obligation (deletion, retention, classification) was enforced across all derived and replicated stores — and to emit a record of that enforcement checkable by an independent party without re-disclosing the protected content.

Empirical demonstrator available: a "delete" that passes its own audit yet returns the content at confidence 1.0 on retrieval.

This threads 3.1/3.2/3.3 rather than duplicating them. It's also the use case @SamMorrowDrums' tool-annotations-ig asked for — I'm writing the annotation-facing version up for them separately and will cross-link.

2. Date corrections to my existing entries (the Digital Omnibus moved the AI Act timeline):

• 3.3 — Impact: replace (enforcement beginning August 2, 2026) with (high-risk obligations deferred to 2 December 2027 under the Digital Omnibus; core transparency obligations from 2 August 2026).
• 7.1 — Problem: replace with enforcement beginning August 2, 2026, with with high-risk obligations now applying from 2 December 2027 under the Digital Omnibus (provisional agreement, adoption expected before August 2026; core Art. 50 transparency obligations from 2 August 2026),.

The high-risk tranche (incl. Annex III credit scoring) shifted from 2 Aug 2026 to 2 Dec 2027; only the Art. 50 transparency obligations hold at Aug 2. The delay was granted because compliance standards/tooling aren't ready — which is exactly what 3.4 and Category 7 point at. GDPR Art. 17 remains the always-on driver underneath.

3. Attribution: please set my organization to Ulissy s.r.l. / GNS Foundation in both places it appears — the participants table (currently "Decentralized identity startup, Rome") and the Category 7 champion line (currently "GNS-Foundation").

Happy to draft spec-gap language or a worked example for any of these.

[Rul1an]

Camilo's (@cayerbe) 3.4 is the entry I'd most want kept in the v1.0 pass, because it names the gap 3.1 implies but does not close: a record can prove an action was requested and logged, and still say nothing about whether the effect held downstream.

The deletion that passes its own audit and returns at confidence 1.0 is the sharp version. The shape is more general: any declared boundary, retention, scope, PHI tagging, or a tool's own contract, can pass at the point of action and fail to hold across derivations or downstream tools that inherited the data without inheriting the policy.

What makes 3.1 and 3.4 one primitive rather than two asks is the record. For it to be verifiable by an independent third party, three things have to hold.

First, the verifier recomputes the result from the record's own bytes instead of trusting the emitter's "allowed" or "deleted" assertion.

Second, the record is addressed by a digest over those bytes. That is also how you get Camilo's "without re-disclosing the protected content": carry a content hash and structural facts, not the payload.

Third, the record states its own coverage: which stores, derivations, and steps it actually checked. Otherwise "absent" and "enforced" carry no information, and are indistinguishable from never-looked-for. The admission-gate-without-an-eviction-gate point is that same coverage question from the other side.

So it is one record: bounded by declared coverage, addressed by a content digest, carrying both what was declared and what was observed, recomputable by someone who was not in the room. 3.1 is that record supporting attribution and integrity; 3.4 is the same record supporting the effect claim.

One boundary I would keep explicit so the catalog stays clean: this is the record contract, not a position on who is trusted to issue or arbitrate those records. The protocol should not prejudge that layer here. If useful, I can sketch spec-gap language or a worked example for either entry.

[cayerbe]

Yes @Rul1an — collapsing these into one record is the right call, and the coverage requirement is the part I'd treat as load-bearing.

The recompute-from-bytes and digest-addressing points are what make 3.1 and 3.4 the same object: the digest that lets a third party recompute "allowed/deleted" without the emitter's assertion is the same digest that carries structural facts instead of the payload. So the no-re-disclosure property falls out of the construction rather than being a separate ask. Agreed on all three.

The coverage field is where the effect claim lives or dies. "Enforced" and "absent" only carry information relative to a declared scope — which stores, derivations, and steps were actually checked. The failure mode is always the store the action never reached (a summary, an embedding, a replica, a downstream re-derivation), so coverage has to be enumerated, not asserted: the record states what it looked at, and anything outside that set is explicitly uncovered rather than implicitly clean. A verifier can then distinguish "checked and absent" from "not checked" — which is the whole difference between an eviction gate and an admission gate.

On the boundary you drew: agreed, and worth keeping firm. The record contract — recomputable, digest-addressed, coverage-bounded, carrying declared-vs-observed — is separable from who is trusted to issue or arbitrate it. Prejudging the trust layer here would couple two things that version independently.

Happy to take the worked example. A delete that passes its own audit and returns at 1.0 is the natural fixture: same record format proving attribution (3.1) and the (failed, then enforced) effect (3.4), with an explicit coverage set so the second retrieval is checkable. If you sketch the spec-gap language for the record fields, I can build the demonstrator against it.

[Rul1an]

Camilo, this split works, and coverage is the right anchor: "enforced" and "absent" only carry information relative to the coverage they were measured against. So here is the field language to build against, with the demonstrator itself yours.

Minimal field set:

• declared: the obligation or boundary (deletion, retention, classification, tenant or PHI scope).
• observed: the read-path finding for it, present or absent, and where observed.
• coverage: the enumerated stores, derivations, and steps actually checked. Anything outside the set is explicitly uncovered, never implicitly clean.
• addressing: a digest over the record's canonical bytes, carrying content hashes and structural facts, not the payload. No re-disclosure follows from this, not a separate ask.
• verifier: identity and version of whatever computed the check, so the result is attributable.
• result: recomputable by a third party from the bytes, not read from the emitter's "deleted" assertion.
• non_claims: what the record does not assert, including every store outside coverage.

On your fixture it resolves cleanly: delete H, action record says accepted, effect record reports per store (primary absent, summary absent, embedding present, cache not checked). A verifier recomputes failed if any covered store still returns content from H, incomplete if a required store went unchecked (the cache), enforced only when all required coverage is checked and absent. The retrieval at 1.0 then stops being a surprise and becomes the predictable reading of a record whose coverage never included the store that kept the data. 3.1 attribution and the 3.4 effect claim fall out of the same bytes.

Same boundary as before: the record contract, recomputable, digest-addressed, coverage-bounded, declared against observed, is separable from who is trusted to issue or arbitrate it. That layer versions independently, and the catalog is cleaner if it stays out of scope here.

If useful, I can tighten this into a 3.x entry or PR text so you and Raghu can place it, demonstrator left with you.

[Rul1an]

Camilo, this maps cleanly. I would write the 3.4 record contract as the normative part, and keep the demonstrator as one implementation of it.

A governance-effect record carries:

• declared: the obligation or boundary being checked, such as deletion, retention, classification, tenant scope, or PHI scope.
• observed: the read-path finding for that boundary, including whether the target was present, absent, pending, or unchecked, and where that was observed.
• coverage: the enumerated stores, derivations, replicas, caches, and downstream steps actually checked. Anything outside this set is uncovered, not clean.
• addressing: a digest over the canonical record bytes, carrying content hashes and structural facts rather than the protected payload.
• verifier: the identity and version of the checker, plus the source class for the finding: re-derivation, issuer-attested receipt, or independent observation of the store.
• result: a single aggregate value, recomputable by a third party from the canonical bytes and the declared required coverage, not read from the emitter's deleted or allowed assertion.
• non_claims: the stores, derivations, or steps the record does not cover, including every store outside coverage and every covered store marked unchecked.

The aggregate result is coverage-bound, with precedence so it stays single-valued:

• failed when any covered required store still returns the target content or a covered derived form of it. failed takes precedence over incomplete.
• incomplete when no covered store fails but any required store is unchecked, pending, or outside coverage.
• enforced only when every required store or derivation is explicitly checked and absent.

Coverage gaps are reported independently of the aggregate: a failed record still carries every unchecked required store as a coverage gap in non_claims, so what was proven and what was never looked at are both legible.

On the fixture you described, primary: absent, summary: absent, embedding: present, cache: unchecked gives aggregate result = failed, because the embedding is a covered required store and still present, and failed takes precedence. Independently, coverage remains incomplete for the unchecked required cache, carried as a coverage gap in non_claims. A later erasure_pending state cannot read as clean; it stays a pending observation that keeps its store uncovered until checked and absent.

One boundary I would keep explicit in the catalog: this is the record contract, not the trust or arbitration layer. The record is recomputable, digest-addressed, coverage-bounded, and declared against observed. Who is trusted to issue, sign, host, or arbitrate those records can version separately.

[cayerbe]

Rulian, agreed, record contract as normative with the demonstrator as one implementation is the right split. Made the changes your version calls for:

pending is now a first-class observed state in the verifier, not an edge case I have to catch — it reads as a coverage gap by construction, never as clean.

On the verifier source class — my implementation does two of the three you list: re-derivation of the aggregate from canonical bytes, and independent observation of each store. The weak one is the issuer-attested receipt; naming the class per finding keeps that distinction legible instead of flattening all three into "checked." Worth having in the contract.

The independent coverage-gap reporting I'd only half-built — the verifier was short-circuiting on the first present store and returning a bare aggregate. Changed it: two passes now, returning {result, coverage_gaps} together, so a failed record still carries every unchecked required store. On the fixture: primary: absent, embedding: present, cache: unchecked → result: failed (embedding is a covered required store and present, precedence holds) with coverage_gaps: ['cache'] alongside. Obligation didn't hold, and here's what was never looked at — two separate facts, both legible. enforced only when the gap set is empty and every required store is checked-and-absent.

Confirmed the non-required case too: a present status on a store outside required_stores doesn't trip failed — matches your "covered required store" wording.

Agreed on the boundary: record contract here, trust/arbitration layer versions separately. That's the line that lets the record be adopted without prejudging who issues or signs one.

Write the normative text and I'll keep the implementation matched to it.

[Rul1an]

Camilo, this is the split I would want the catalog to capture: the record contract is the normative part, and your demonstrator is one implementation that exercises it.

For 3.4, I would phrase the protocol gap roughly this way:

A governance-effect record lets a verifier distinguish a declared obligation from an observed effect. It carries:

• declared: the obligation or boundary being checked, such as deletion, retention, classification, tenant scope, or PHI scope.
• observed: the read-path finding for that boundary: present, absent, pending, or unchecked, and where observed. pending is a first-class observed state, never read as clean.
• coverage: the stores, derivations, replicas, caches, and downstream steps actually checked. Anything outside this set is uncovered, not clean.
• coverage_gaps: required stores, derivations, or steps not checked: unchecked, pending, or outside coverage. Reported alongside result, not folded into it, so a failed record still states what was never looked at.
• addressing: a digest over the record's canonical bytes, carrying content hashes and structural facts rather than the protected payload. The contract fixes the recomputable-byte property, not a specific hash or canonicalization algorithm.
• verifier: the checker identity and version, plus the source class per finding: re-derivation, issuer-attested receipt, or independent observation of the store. An instance declares which classes it used; absent classes remain legibly absent rather than flattened into "checked."
• result: a single aggregate value, recomputable from the record bytes and the declared required coverage, not read from the emitter's assertion.
• non_claims: what the record does not assert, including anything outside coverage, scope, or freshness. coverage_gaps is the load-bearing subset for required-but-unchecked stores.

The aggregate result is coverage-bound and single-valued by precedence:

• failed: any covered required store still returns the target content or a covered derived form of it. failed takes precedence over incomplete.
• incomplete: no covered store fails, but a required store is unchecked, pending, or outside coverage.
• enforced: every required store and derivation is checked and absent, and coverage_gaps is empty.

On the erasure fixture: declared = erase H; observed = primary absent, summary absent, embedding present, cache unchecked; coverage = primary, summary, embedding checked; cache required but unchecked. The record reads as result: failed, because the embedding is a covered required store and present, with coverage_gaps: ["cache"] alongside. The obligation did not hold, and the unchecked cache remains a separate fact. A present status outside required coverage does not trip failed.

That keeps the catalog boundary clean: this is the record contract, not the trust or arbitration layer. The record is recomputable, digest-addressed, coverage-bounded, and declared against observed. Who is trusted to issue, sign, host, or arbitrate these records can version separately.

[cayerbe]

Rulian, that's the contract. Mine matches on the parts that carry weight: observed with pending first-class, coverage enumerated, coverage_gaps alongside result rather than folded in, the precedence with failed restricted to covered required stores, and the aggregate recomputed from bytes.

Two spots where your text is ahead of what I built, both small to close:

You have observed carrying where it was observed. Mine records the status per store but not the locus. That's a field to add, not a rethink — and it's worth it, since the locus is what lets a verifier tell two checks of the same store apart.

And non_claims is broader in your version — outside coverage, scope, or freshness — with coverage_gaps as the load-bearing subset. I've got the subset. Scope and freshness I'd add as the contract settles; freshness especially, once a record can be re-presented later and the verifier needs to know the observation is still current rather than stale.

The addressing framing is at the right level — recomputable-byte property fixed, the specific hash left open. Mine's BLAKE2b over canonical JSON, but good that the contract doesn't pin that, so something else can conform just as well.

Boundary's unchanged and I'm with you on it: record contract here, trust and arbitration separate. Land the normative text wherever it fits best in the catalog — I'll keep the reference implementation tracking it.

[Rul1an]

Proposed addition to 3.4: the governance-effect record

3.4 names the gap that 3.1 implies but does not close: a record can prove an action was requested and logged and still say nothing about whether the effect held downstream. The part that closes it is a single record shape. The same record that supports attribution in 3.1 also supports the effect claim in 3.4, so this is one primitive, not two asks.

A governance-effect record lets a verifier distinguish a declared obligation from an observed effect, and is checkable by an independent third party who was not in the room. It carries:

• declared: the obligation or boundary being checked, such as deletion, retention, classification, tenant scope, or PHI scope.
• observed: the read-path finding for that boundary (present, absent, pending, or unchecked), and where it was observed. pending is a first-class state and is never read as clean.
• coverage: the enumerated stores, derivations, replicas, caches, and downstream steps actually checked. Anything outside this set is uncovered, not clean.
• coverage_gaps: the required stores, derivations, or steps not checked (unchecked, pending, or outside coverage). Reported alongside result, never folded into it, so a failed record still states what was never looked at.
• addressing: a digest over the record's canonical bytes. When the record carries content hashes and structural facts rather than the protected payload, the no-re-disclosure property follows from that construction; it is not a separate trust claim. The contract fixes the recomputable-byte property, not one mandatory hash or canonicalization algorithm; a conforming record declares the algorithms it uses so another verifier can reproduce the same bytes and digest.
• verifier: the checker's identity and version, plus the source class per finding (re-derivation from the bytes, an issuer-attested receipt, or independent observation of the store). An instance declares which classes it used; absent classes stay legibly absent rather than flattened into "checked."
• result: a single aggregate value whose reduction is recomputable by a third party from the recorded findings, source classes, record bytes, and declared required coverage, not read from the emitter's "deleted" or "allowed" assertion.
• non_claims: what the record does not assert, including anything outside coverage, scope, or freshness. coverage_gaps is the load-bearing subset for required-but-unchecked stores.

The aggregate result is coverage-bound and single-valued by precedence:

• failed: any covered required store still returns the target content, or a covered derived form of it. failed takes precedence over incomplete.
• incomplete: no covered store fails, but a required store is unchecked, pending, or outside coverage.
• enforced: every required store and derivation is checked and absent, and coverage_gaps is empty.

On the canonical fixture, a deletion that passes its own audit yet returns at confidence 1.0, this resolves predictably. Declared: erase H. Observed: primary absent, summary absent, embedding present, cache unchecked. Coverage: primary, summary, embedding checked; cache required but unchecked. The record reads result: failed, because the embedding is a covered required store and still present, with coverage_gaps: ["cache"] carried alongside. The retrieval at 1.0 stops being a surprise: the record exposes a covered failure in embedding and still carries cache as an explicit coverage gap. A present status outside required coverage does not trip failed. 3.1 attribution and the 3.4 effect claim fall out of the same bytes.

Boundary, kept explicit so the catalog stays clean: this is the record contract (recomputable, digest-addressed, coverage-bounded, declared against observed), not a position on who is trusted to issue, sign, host, or arbitrate those records. That trust/arbitration layer versions independently and stays out of scope here.

Open for the v1.0 pass: a freshness field, so a record re-presented later reads as legibly current rather than stale, and a broader scope axis in non_claims. Flagged here rather than assumed.