Summary

I'd like to propose a data-contract attestation type for trustManifest.attestations[]: a content-addressed pointer to a machine-readable authorization policy that governs what a capability may do with a resource — e.g. which tables an agent may query, which operations are forbidden, resource/row limits, and per-principal row/column rules.

Unlike a compliance certification (what an org claims, e.g. SOC2-Type2) or a runtime-governance receipt (what an agent did), this attestation carries the policy itself — evaluated per operation, before execution — in a form a consumer can verify and, if it chooses, re-enforce independently.

This extends the Trust Manifest currently under review in #48 with a concrete, enforceable use-case.

The gap

The current attestation examples cover publisher identity (publisher-identity) and static compliance evidence (SOC2-Type2); emerging proposals cover runtime-governance receipts. None carries a per-operation authorization policy. So a registry can verify who a publisher is, but there's no standard, verifiable way to publish what a capability is permitted to do in a form a consumer can check — and enforce — for itself.

A data-contract attestation is evidence, not a verdict: it asserts only that a content-addressed authorization policy is published here — never that the resource is safe or compliant. The consumer dereferences, recomputes the digest, and decides.

Shape

{
  "type": "data-contract",
  "uri": "https://acme.com/contracts/warehouse.json",
  "mediaType": "application/json",
  "digest": "sha256:da783d4d1f6d…"
}

• Content-addressed + recomputable — the policy is canonical bytes; a consumer recomputes the SHA-256 offline, with no issuer callback (matches the existing digest/recompute pattern).
• Scope — the policy document declares the resources and operation classes it governs.
• Non-claim — it does not assert any individual operation complied; only that this is the policy. Per-operation compliance is established at enforcement time by whoever runs the policy.

Use case / provenance

agentic-data-contracts (on PyPI, v0.27.0) governs what SQL an AI agent may run against a data warehouse — allowed tables, forbidden operations, cost/row limits, per-principal row/column rules — and enforces it at query time (static SQL analysis + an EXPLAIN dry-run).

As of v0.27.0 it "freezes" a contract into a portable, content-addressed artifact and emits exactly the attestation above. A consumer fetches the policy, recomputes the digest, rebuilds the validator, and gets identical enforcement — the publish → verify → enforce loop closes with no trust in the publisher's assertion. It's in pilot use inside an enterprise industrial data platform.

This is a working reference implementation, not a sketch — I'm happy to contribute conformance examples (a sample frozen contract plus an independent recompute-and-enforce) under whatever the canonical bytes/digest conventions settle on.

Open questions

1. A distinct type: "data-contract", or a small "authorization-policy" evidence family with this as the first instance?
2. Preferred way to name the policy format? The contract is a declarative YAML/JSON schema; a dedicated media type for the policy document (e.g. application/vnd.data-contract+json) might be cleaner than application/json (related to the mediaType-as-discriminator discussion in mediaType field as type discriminator creates publisher burden #30).
3. Is there a registration process for new well-known attestations[].type strings, or is the field intentionally open?

Happy to draft the spec section + examples PR once there's directional agreement on the above.