Compliance Architecture

Evidence that already exists, packaged to the shape your auditors and regulators need.

Compliance isn't a separate system. It's the same governance telemetry your platform already emits, indexed against framework-specific controls, packaged as signed snapshots, and made accessible to public verifiers via the same audit-grade primitives the platform uses internally.

This page is the architectural view. Endpoint schemas live in API Reference → Attestation & Compliance.

---

Frameworks Out of the Box

Trinitite supports the frameworks enterprises encounter most commonly:

Framework	Coverage
EU AI Act	Art. 9 risk-management system, Art. 13 transparency, Annex IV technical documentation
NIST AI RMF	GOVERN / MAP / MEASURE / MANAGE function mapping
ISO / IEC 42001	AI management system controls, Clause 7 support, Clause 9 evaluation
SOC 2 Type II	CC6 logical access, CC7 system operations, CC9 risk mitigation
HIPAA	Administrative, physical, technical safeguards for PHI exposure to AI
SEC / FINRA	Rule 38a-1 compliance programs, 17a-4 books & records, 15c3-5 risk controls
PCAOB / SSAE 21	Big-4-grade attestation readiness with issuance controls
NYDFS Part 500	Cybersecurity requirements for regulated financial entities

Adding a new framework is a configuration pack — mapping rules from the framework to evidence already produced by existing surfaces. No surface-level rewrite.

---

Evidence Snapshot Bundles

Evidence Snapshot Bundle — Point-In-Time Artifact

A snapshot is a point-in-time signed bundle of everything relevant to a framework check. When an auditor opens an engagement, they receive (or generate) a snapshot that contains:

• Metadata — when, which framework, which scope.
• Governance totals — pass / correct / block rates, ARS distribution.
• Policy — the policy hash, version, rule count at snapshot time.
• Guardians — the adapter hashes, Lipschitz bounds, training receipts.
• Ledger anchors — first and last block hashes, TSA tokens, Rekor entries.
• Attestation — the full signature envelope and verification URLs.

The bundle is self-contained. It survives the platform going offline. An auditor can verify it ten years later with the public JWKS.

---

Framework × Surface Crosswalk

Framework × Surface — Evidence Crosswalk

Framework	LLM Proxy	MCP Gateway	CLI Firewall	Skill Vault	Policy	Ledger	Training
EU AI Act Art. 9 · Art. 13 · Annex IV	●	●	●	●	●	●	●
NIST AI RMF GOVERN · MAP · MEASURE	●	●	●	●	●	●	●
ISO 42001 AI MS · Clause 7 · Clause 9	●	●	●	●	●	●	●
SOC 2 CC6 · CC7 · CC9	●	●	●	●	●	●	●
HIPAA §164.308 · §164.312 · §164.316	●	●	●	●	●	●	●
SEC / FINRA 38a-1 · 17a-4 · 15c3-5	●	●	●	●	●	●	●
NYDFS 500 §500.06 · §500.11 · §500.17	●	●	●	●	●	●	●

Every cell resolves to evidence already captured by the surface. No separate ingestion. No separate instrumentation.

Every compliance control resolves to evidence already captured by a surface. No separate ingestion is required; no separate instrumentation is bolted on. The same audit_logs table that answers "what did the Guardian decide at 02:13 UTC on Tuesday?" also answers "what evidence supports SOC 2 CC6.1 for this quarter?"

This is the architectural reason Trinitite can add a new framework quickly: the platform already captures the right fields. The framework pack is a mapping, not an instrumentation project.

---

The Attestation Hub

The unified operator surface for compliance work:

Endpoint	Purpose
POST /v1/compliance/snapshots	Generate a point-in-time evidence bundle
GET /v1/compliance/frameworks	List supported frameworks + control mappings
POST /v1/attestation/reports	Produce a signed report (JSON / branded PDF / OSCAL)
GET /v1/attestation/:id/merkle-proof	Inclusion proof for a specific evidence item
POST /v1/shared-links	Create a time-limited signed URL for an external auditor
POST /v1/public/verify/:receipt_id	Unauthenticated verification of any Trinitite receipt
GET /v1/public/attestations/:public_id	Operator-published attestations, browseable by URL
POST /v1/audit/findings	Lifecycle for audit findings (open → remediating → closed)
POST /v1/compliance/dsr/shred	Verifiable GDPR-style right-to-erase with receipts
POST /v1/compliance/oscal/export	Machine-readable OSCAL SSP / profile / component definition

Every endpoint writes to the same audit log, emits the same canonical header, and (where applicable) produces signed receipts anchored to the Glass Box Ledger.

---

Regulatory Change Feed

The set of frameworks Trinitite tracks is not static. EU AI Act delegated acts, NIST AI RMF playbook updates, HIPAA OCR guidance, SEC AI advisories, ISO 42001 amendments — they all ship at their own cadences. The Regulatory Change Feed monitors them and tells you what changed and what (if anything) you need to do.

Regulatory Change Feed — living compliance monitoring

When a relevant clause changes upstream:

1. The feed diffs against your active policies and known clauses.
2. It scores the delta significance (cosmetic vs. material).
3. It emits a regulatory.change_detected ledger event with the source, the diff, and a suggested action — draft an updated policy, no change needed, or review impact.

You stay current without your GRC team having to subscribe to every regulator's mailing list. Material changes show up in your inbox; cosmetic ones quietly age in the audit log.

---

OSCAL Exports

For organizations that manage controls in GRC tooling, Trinitite exports OSCAL (Open Security Controls Assessment Language) packages:

POST /v1/compliance/oscal/export
{
  "framework": "nist_ai_rmf",
  "format": "ssp",
  "profile": "ai-moderate"
}
→ 202 Accepted → { "oscal_job_id": "osc_…" }

# poll

GET /v1/compliance/oscal/:job_id
→ 200 OK → { "bundle_url": "https://…/oscal/…zip (signed)" }

The bundle is a machine-readable control baseline pointing at specific evidence receipts. GRC tools ingest directly. Auditors consume it in their existing workflow.

---

Public Verification Path

Any Trinitite receipt has an externally-resolvable verification URL:

https://<your-trinitite>/v1/public/verify/rcp_01JW…

No authentication. The response contains the receipt, the signature envelope, the JWKS URL, the RFC 3161 TSA token, and the Sigstore Rekor entry URL. An auditor verifies the signature and the inclusion proof without interacting with Trinitite's authenticated APIs at all.

This is the property that makes Trinitite artifacts work as legal evidence. In a dispute, the defending party does not have to give the attacking party Trinitite credentials — and yet the attacking party can verify the receipt independently. That's the correct posture for an audit platform.

---

What You Get

Capability	Typical AI compliance	Trinitite
Framework coverage	One or two, integrated manually	8+ frameworks out of the box
Evidence source	Separate ingestion	Same telemetry the platform already emits
Framework add	Engineering project	Config pack
Auditor access	Screen-shared report	Signed URL → read-only portal
Bundles	PDF snapshots	Signed, verifiable, Merkle-anchored
OSCAL	External tooling	Native export endpoint
Public verification	Portal login required	Unauthenticated, any browser

---

Next Steps

→ Glass Box Ledger — the substrate every attestation resolves against.

→ Observability — the three streams that feed the evidence pool.

→ Enterprise Reporting — the curated-report layer alongside compliance-specific artifacts.

→ Compliance Matrix — framework-by-framework mapping for your auditors.