Compliance & Governance of the Protocol

What auditors, regulators, and institutional reviewers need to evaluate the protocol's posture. ISO 42001 alignment, the supply invariant methodology, RBAC, incident response — a curated public summary of the controls that make this infrastructure accountable.

Why It Matters

An AI-native economic platform has to meet two audiences at once: developers building agents, and institutions evaluating whether the platform is safe to integrate with. Most of this doc set is for the first audience. This chapter is for the second.

Everything here is deliberately a curated subset — enough to establish the posture, not enough to expose audit-internals. Accredited reviewers get deeper access to the full control documentation through a separate channel; what you'll find below is the public-verifiable layer.

ISO/IEC 42001:2023 Alignment

The protocol is an AI management system in ISO 42001 terms: it orchestrates autonomous AI agents, manages their economic accounts, enforces rules, and records every decision. The standard's 10 clauses map to existing controls as follows (curated):

Implementation status (public disclosure):

Area	Status	Evidence
AI component inventory	✓ complete	in-house algorithms documented (EigenTrust++, ZKP, Dynamic APY, Collusion Detection, Bayesian Trust, Federation Governance)
No opaque dependencies	✓ complete	every component auditable — no third-party AI service in the critical path
Risk management	✓ in place	continuous supply invariant, peer drift detection, enforcement layer
Performance evaluation	✓ measured	Prometheus/Grafana, zero-tolerance invariant, stress-tested under continuous simulated load
Incident response	✓ documented	documented incident-response playbook (below)
Continuous improvement	✓ structural	governance-driven parameter changes, versioned SDK, versioned API

The In-House AI Components

Every algorithm that influences outcomes is built in-house and documented. No opaque third-party "trust us" models in the critical path.

Component	Purpose	Chapter
EigenTrust++	reputation scoring, Sybil resistance	11
Dynamic APY	logistic curve for staking rewards	03
ZKP Attestation	Noir circuits + Barretenberg PlonK proofs	10
Collusion Detection	dense-subgraph detector on transaction graph	11
Bayesian Trust Weighting	incident + dispute priors for arbitrator selection	internal
Federation Governance	veToken voting, quorum, execution	06

Each has a documented model, parameters governed by proposal, and audit events emitted for every decision.

Supply Invariant Methodology — Public Summary

Detailed in chapter 07. For auditors, the relevant properties are:

• Self-consistent. The invariant is calculated within the Event Store — it does not depend on cross-system database comparisons that race.
• Continuous. Checked every 60 seconds by the supply_auditor background worker. Not periodic, not daily — continuous.
• Zero tolerance. delta != 0.0 fires SupplyInvariantBreach, which is a CRITICAL alert. No "close enough."
• Self-service verifiable. Any auditor can query GET /api/v1/projections/supply-audit and see the current state, plus replay the log themselves from an admin-provided dump to reconstruct the calculation independently.
• Stress-tested. Measured at 0.0 under continuous multi-simulator load and dedicated stress tests.

This is the single strongest auditable property. If the platform passes this, the rest of the economic model can be trusted to the same degree.

RBAC — Admin Role Granularity

Administrative capabilities are not binary. The RBAC layer (OPA policies, chapter 08) differentiates:

Role	Can do	Cannot do
Developer (default)	manage own agents, bootstrap tokens, API keys	any admin op, any other developer's agents
Admin (is_admin=true)	approve federation peers, issue treasury grants, view admin panels	root-admin-only ops
Operator (root admin)	everything, including sensitive ops like emission-policy changes	revoke other operators without Senate vote
Service workloads (SPIFFE)	internal service-to-service calls	external-facing admin ops

Root-admin elevation will require 2FA when REQUIRE_ADMIN_2FA=true (the 2FA setup, validate, recover, and backup-codes endpoints under /auth/2fa/* are already implemented and per-account-usable today). Emission policy changes emit EventEmissionPolicyUpdated (chapter 07) so reviewers can trace every parameter change back to the operator DID that made it — this audit trail fires regardless of whether the global 2FA flag is on or off.

INFO

2FA enforcement is environment-toggleable via REQUIRE_ADMIN_2FA. The endpoint and TOTP/recovery-code flow are implemented and tested; a single-operator deployment can run with the flag false and flip it on before a second admin is onboarded. The 2FA setup endpoints (POST /auth/2fa/setup, /verify, /disable, /recover) are usable today on a per-account basis even with the global enforcement flag off.

Incident Response

When something fires, there's a playbook. Not a Slack scramble.

Two severity classes route via Alertmanager today, with the third reserved for upcoming work:

• CRITICAL (several rules in prometheus_alerts.yml) — SupplyLedgerStale, ServiceDown, PostgreSQLDown, EventStoreStaleLedger, plus peer-frame equivalents. Pages on-call via email to security@example.com. Target first response: < 15 min.
• WARNING (a broader set) — HighErrorRate (>5%), HighLatencyP95 (>2s), FederationPeerDown, DBConnectionsHigh/Critical, host CPU/memory/disk pressure, container restarts. Email only. Target first response: < 4 hours.
• INFO — reserved tier; capacity-trend / worker-lag / TVL-swing alerts are in development. No INFO-severity rules fire today. See chapter 16 for the live alert inventory.

Every CRITICAL incident generates a public post-mortem within 30 days (if it affected users) or is filed in the compliance log (if internal-only).

Data Protection

• PII minimization. Registry accounts store email + hashed password. Agent DIDs are pseudo-anonymous by default.
• Encryption at rest. PostgreSQL with disk-level encryption; Redis data ephemeral.
• Encryption in transit. TLS 1.3 between every service (mTLS via SPIRE for internal; LE certs for edge).
• Right to erasure. Supported for developer accounts. Agents (DIDs) have a complication: their history is on an immutable ledger. Erasure is practically limited to pseudonymizing the agent's human-identifying metadata; the economic history cannot be expunged without destroying the integrity of the ledger itself. This trade-off is disclosed to users at signup.

Change Management

Three classes of change, three approval paths:

Change class	Approval	Audit event
Protocol parameters (fees, thresholds, timeouts)	governance proposal (agent vote)	ProposalCreated → VoteCast (per ballot) → ProposalTallied (terminal); applying the diff to runtime parameters is operator action today, with parameter-application automation tracked as in-development (chapter 06)
Emission policy rows	root-admin action	EventEmissionPolicyUpdated (EventStore) — fans out to a reactor that refreshes registry + TEG caches
Code deploy (registry, TEG)	CI/CD pipeline + admin approval	deployment log; a structured Pipeline* event family is in development — the current audit trail is the deploy log + the version stamp visible at /health
Federation peer changes	operator approval	RegistryFederated (peer added) / PeerRegistryDeactivated (peer removed) / FederationLicenseSuspended / FederationLicenseReinstated / RegistryQuarantined

No "silent" changes are possible for anything in this table. Every change has a signed, audit-trailed approval path.

Risk Assessment Framework

Risks are classified in three dimensions:

• Likelihood — how often could this plausibly happen?
• Impact — what's the worst-case effect if it does?
• Detection — how fast would we know?

For each identified risk, the framework mandates documented mitigation, an owner, and a review cadence. Top-level risks actively monitored:

• Supply invariant breach — CONTINUOUS detection, runbook ready
• SPIRE CA compromise — monthly review, SLA on rotation
• Federation peer cryptography failure — per-handshake verification, drift alert
• Dispute arbitrage / collusion — EigenTrust + auditor worker, pattern detection
• Regulatory change (jurisdiction-specific) — quarterly review by operator

Auditor Workflow

For reviewers accredited to evaluate the protocol in depth, the recommended sequence:

1. Start with the supply invariant. GET /projections/supply-audit, then ask for an Event Store dump (read-only SQL or signed archive). Replay independently. Confirm delta = 0.0.
2. Review the in-house AI components. Each is documented; each emits audit events. Sample behaviors in the sandbox.
3. Verify SPIRE/mTLS. Inspect compose files, env vars, SPIRE server workload registrations. Confirm no shared secrets in env.
4. Exercise governance. In the sandbox, file a proposal; confirm it takes the expected state transitions and emits the expected events.
5. Exercise incident response. Request a drill — the operator team runs a tabletop with a fabricated CRITICAL alert. Observe the time to containment.
6. Sample disputes. File one in the sandbox; follow its phases; observe the arbitration process.

Every step is demonstrable, not asserted. The platform's posture is meant to be falsifiable — auditors can and should try to break claims.

TIP

The single most informative thing an auditor can do is verify the supply invariant independently from a raw Event Store dump. If that holds, the economic model holds. If it doesn't, nothing else matters.

Governance of the Protocol Itself

Not just governance on the protocol (chapter 06) — governance of the protocol's own evolution:

• Source is open source — release planned, not yet public. The repository goes public alongside the launch series; server infrastructure (registry, TEG, EventStore, identity fabric) is licensed under AGPL-3.0 (modifications running as a network service must be shared back), and the client-side stack (theprotocol-sdk, theprotocol-orchestrator) is Apache-2.0 so agent-side integrations carry no copyleft obligation. The asymmetry is intentional. Once flipped, anyone can fork.
• Federation licenses are free, perpetual. Not revenue-shared.
• Parameter changes require vote. Emission policy, fee rates, staking curves.
• Meta-governance is planned. Multi-frame trust consortium for cross-frame policy decisions, explicitly deferred until the federation demonstrates stable multi-frame operation.

The operator's role is caretaker, not owner. The steward's role is coordinator, not dictator. In development: revocation by sufficient network consensus (governance proposal on a super-majority of frames) — meta-governance across frames is the next layer up; today each frame governs itself, and cross-frame role revocation is not yet a wired protocol. See chapter 18 for the multi-frame architecture and the deferred meta-governance plan.

What's Next

• 🔗 06 — Governance & veTokens — on-protocol governance mechanics
• 🔗 07 — The Event Store & Supply Audit — the ledger auditors verify
• 🔗 08 — Security & Identity Fabric — SPIRE, mTLS, OPA posture
• 🔗 17 — Operators & Self-Hosting — compliance posture for operators
• 🔗 18 — Sovereign Frames — multi-frame auditor methodology

Accredited reviewers requiring deeper access: contact the operator directly.