Compliance Reports

Available report kinds

Erasure confirmation (the GDPR Art.17 four-step proof) is a scope-subset of the GDPR Art.17 attestation rather than a separate kind. The engine verifies GC-3 destroyDek, the GC-4 tombstone, the GC-5 CID blacklist, and a post-forget recall returning “no memories stored”.

What makes the evidence checkable

Most compliance documentation asks a reader to trust the party that wrote it. Three properties of the protocol change what a SAIHM report can assert.

• Erasure is destruction, not deletion. Forgetting a memory destroys the key that decrypts it. The ciphertext that survives in storage is unreadable by anyone, the operator included, so an Art.17 attestation reports a cryptographic fact rather than a policy commitment.
• The audit trail is append-only and public. Tombstones and receipts are published, so a claim in a report can be checked against a record the reporting party cannot quietly revise.
• The operator stores what it cannot open. Cells are sealed client-side before egress, which is why the same evidence holds whoever is running the operator endpoint.

Framework-by-framework mappings are published separately as standards crosswalks. Those are evidence-of-design documents, not certifications.

Authorization paths

Four authorization paths, each emitting a GC-14 audit receipt with the full chain:

• Public — registry-attestation only; anyone can request; output contains only public-record fields.
• Self — agent or wallet-owner generates own report. Web: EIP-712 wallet-sig over fresh challenge nonce (replay window 30 min). MCP: ML-DSA signature by the requesting agent's identity.
• Operator self — operator pulls reports about their own MCP-instance scope (operator-customer-list, operator audit history). ML-DSA signature.
• Operator for downstream — operator pulls reports about a downstream customer; two-of-two authorization required: operator's ML-DSA signature plus either a downstream-customer-signed access grant or legal-basis evidence (subpoena hash + jurisdiction + public-record URL).

Operator-ToS obligation: operators using operator-for-downstream paths disclose to their customers in their own ToS that reports may be pulled. SAIHM provides audit-trail integrity; operator owns ToS clarity. The GC-14 audit chain is the post-hoc accountability mechanism.

Examples

Eleven anonymized synthetic PDF/A-3 example documents will be published as each kind’s generator lands, and linked here for download. None are published yet — the table names what is planned, so you can judge the coverage before committing to anything.

Synthetic example data: fully fabricated agent IDs, redacted financial values, public-domain placeholder narrative content, no internal-only fields. Synthetic cellId hashes follow 0x000…example pattern.

Format and integrity

Default format: PDF/A-3 (ISO 19005-3) archival, with embedded source data per spec, XMP metadata, and ICC color profile. Alternative formats: JSON or CSV (per request). Every report bundle is signed with the engine’s GC-14 receipt seal. Receipts are retained per the registry-cell-protection policy (at least 17 months for any cited receipt).

Caps: time-window per query 1 year, result-size per report 50 MB, field-projections per template 200, customer-IDs per scope 10,000. Per-operator rate-limit defaults to 100 reports/hour; per-customer-ID rate-limit defaults to 10 reports/hour. Soft-cap behavior: escalate-on-exceed with operator notification and GC-14 receipt.

Common questions

Is the report engine actually available, or only specified?

The engine itself ships with the client, published as a library alongside the MCP server. Registry attestation generates end-to-end today. The other nine kinds ship their field definitions and authorization coupling but do not yet have generators, and no example documents are published yet. For timing on a specific kind, email ops@saihm.coti.global.

Does SAIHM produce evidence that a memory was actually erased?

Yes. The GDPR Art.17 attestation reports a four-step proof rather than a claim: the per-cell key was destroyed (GC-3), a tombstone was published (GC-4), the content identifier was blacklisted (GC-5), and a recall issued after the erasure returns “no memories stored”. Erasure here is destruction of the key that decrypts the record, so the ciphertext that remains in storage cannot be opened by anyone, the operator included.

Can an operator pull a report about a downstream customer?

Only with two-of-two authorization: the operator’s ML-DSA signature plus either an access grant signed by the downstream customer or legal-basis evidence recorded as a subpoena hash with jurisdiction and a public-record URL. Every path emits a GC-14 receipt carrying the authorization chain, so the pull is accountable after the fact.

Can I get a report without an account?

Only the registry attestation, which is a public proof-of-existence for an agent or cell registration and contains public-record fields only. It requires no authentication and is rate-limited to 1000 requests per hour per IP. Every other kind requires an authorization path that identifies the requester.

How is a report verified as authentic?

Each bundle carries a GC-14 receipt seal, and the receipt is retained in the audit ledger for at least 17 months for any receipt the report cites. A reader checks the seal against the ledger entry rather than trusting the document itself.

Independent implementations

SAIHM is Apache-2.0. Independent developers building on the protocol may publish additional report kinds, alternative output formats, or bespoke templates of their own. The kinds listed here are the ones generated directly by SAIHM.