Governance API
20 October 2026 · John Stroh, Director, My Digital Sovereignty Ltd
What it is
The Governance API is an interface other software calls before an AI agent acts. The caller submits a proposed action, optionally with the deliberation behind it (a kōrero: the proposal, the AI inputs, and each person's engagement with them in their own words). It returns a verdict (allow, gate for a human decision, or deny), coarse reason codes, and an Ed25519-signed receipt the customer can verify offline against the tenant's DID document. A record of the deliberation is held in the customer's own tenant, in New Zealand or the EU, and can be exported as a self-verifying dossier.
It is deliberately narrow: what goes in and what comes back is the whole surface, and how a verdict is reached does not cross the wire.
Where it runs today: as a sandbox, available on request: John Stroh issues a one-time token tied to a single address, where an integrator can build and test against the real contract. Production keys follow published terms, a DPA and a security review. The API is offered only as an add-on to a Village™ subscription; there is no API-only plan. Prices are on request.
Built vs roadmap
Status as of 20 October 2026, established by AI agents from the code and plans; no person has checked every line (see the status page). Which features are switched on in production is stated per row.
| Capability | Status | What it means for a customer |
|---|---|---|
| Verdict endpoint, signed receipts, fetch/verify endpoints, per-key scopes and rate limits (about 18 routes) | Built; runs in the sandbox | An integrator can build and test against the real contract today |
| Sandbox verdict engine (deterministic rule table) | Built, switched on for the sandbox. Its receipts are marked non-authoritative | Good for integration testing; not a governance decision a customer should rely on |
| Real verdict engine (with action classification; unclassified write-shaped actions gate by default) | Built; switching it on is MDSL's decision | The sandbox returns rule-table verdicts; authoritative verdicts come from this engine |
| Corpus-based content verification of kōrero claims | Built; second flag, off by default | Would let a verdict escalate when a claim contradicts the tenant's own material |
| Kōrero records: open, add segments, seal; object attestations | Built; runs in the sandbox | The deliberation, not a tick in a box, is what is recorded |
| Per-director signing (each engagement individually signed) | Built | Attributable signatures per participant |
| Receipt time attestation: RFC 3161 timestamp from Certum (Poland), a non-qualified authority, or a marked fallback (grade A or grade O) | In the sandbox, available on request; grade O when no stamp arrives, retried nightly | A receipt states whether an outside authority timestamped it, which one, and that it is not qualified |
| Qualified timestamp from Aruba PEC (Italy), beside Certum | Built; available on request as an opt-in, switched on per customer because each stamp is priced | Not used on a live customer engagement |
| Hash-linked proof chain | Live for entries written from 24 September 2026; earlier entries are not linked | A removed or reordered entry in the middle is detectable; removal of the newest entries is not yet detectable |
| Downloadable offline verifier (verify-record.js) | Live | Checks signatures, links, the stated time attestation and, for a did:x509 signer, a chain to a trust anchor the checker supplies |
| Signing-key custody | MDSL holds the key; a separate signing host is in use for every active Village | The customer does not hold the key; a verified receipt shows what was recorded, not that the platform could not rewrite it |
| Mandates and agent inventory, with "in force" lookup (five routes, one of them a committed-seed lookup with no writer yet) | Built; runs in the sandbox | Same capability as MIO° Conduct Record™, reachable through this API; records, does not enforce |
| Usage endpoint, metering, billing module | Built; the link from usage to invoices is not confirmed | Metered overage cannot be relied on until confirmed |
| OpenAPI spec, user guide, versioning policy, JS client with offline verifier | Written; the announcement is published and a pricing page is drafted | Integration can be designed now |
| Security review of the API | Reviewed by AI agents; no external security audit; an independent penetration test has not been done and its scope of work is drafted, not yet sent | Sandbox access is at MDSL's discretion, on a one-time token; production keys follow published terms and a security review |
| Terms of service and DPA | Drafts; to be published before any production key | No production key until both exist |
| Pre-action verdict on a proposed action | Returned by the API; sandbox today | Acting on the verdict is the caller's system |
Coming, or built and not yet deployed (as at 20 October 2026). Hybrid post-quantum attestation (ML-DSA-65 beside Ed25519): built, off by default, enabled for no tenant, not deployed. A verifier change that refuses DID hosts written as numbers, and a --require-pq option: built, not yet deployed. Further tenants' keys on the separate signing host: not yet deployed. Platform signing with an X.509 certificate (did:x509): not available; the offline verifier's did:x509 check is deployed. Anchoring on the Midnight test network: prototype, test data, not part of this API.
The full participant one-pager, with the competitive landscape and the risks and open decisions, is shared in the private room, to named people, with a record of who opened it. Write to john.stroh@mysovereignty.digital to be invited.