What is running, what is next, and what a record does and does not show
Checked by AI agents working under John Stroh’s direction: the sealing, hash-linking and concurrent-write rows against the live systems on 24 September 2026, the separate-signing-host and did:x509 rows on 19 October 2026 (tenant counts as at 14 October). The research-prototype rows were built and reviewed by AI agents only; no person has audited them. Updated as that changes.
The records are given a digital fingerprint, signed, and stamped with the time by an outside authority, so a later reviewer can check, on their own machine and without an MDSL account, that a record is unchanged since signing. The signing key is MDSL’s (see ‘Separate signing host’ below). Below, in four groups, is what works now, what is built and not yet in use, what exists only as a prototype, and what is still ahead. The status page uses “built” for something built, tested and deployed that is in use for named tenants only or not yet in use, as each entry states. On this page “built” covers anything built and tested, deployed or not; each row says which.
Two newer offerings follow the same design. The Email Decision Record™ keeps a sealed record of each decision about an email (what was proposed, who decided, what was sent or held); it is available on request and no customer is live yet (EDR-01 to EDR-05). Key custody is set out under ‘Separate signing host’ below. Provenance™ lets an organisation export sealed records that a reader can check in their own browser, offline, with no account; it is available on request (PRV-01 to PRV-03; EST-28 for the key arrangements).
Operating now
| Capability | What that means |
|---|---|
| Sealing | Each record is given a unique digital fingerprint (a hash), signed with a key issued to the customer’s identity and held by the platform by default or, for every active Village™, on a separate signing host (see “Separate signing host” below), and submitted for an RFC 3161 timestamp from an outside authority when sealed. The authority in use is a non-qualified service (Certum, Poland). If it does not issue a stamp, the record says so and the stamp is retried nightly. |
| Offline verification | A third party can check a downloaded record bundle without an account, on their own machine, calling nothing home. The default check uses the keys carried in the bundle; an optional check fetches the keys from the customer’s published identity document. |
| Separate signing host | A separate signing host, outside the process that writes records, is in use for every active Village. A verified record shows what was recorded and is not protected against rewriting by the platform. MDSL operates the separate host too: the key is in a different place, but still in MDSL’s hands, and no outside party holds it. |
| Hash-linked history | Since 24 September 2026, records written from that date are linked to one another, so a removed or reordered entry in the middle of a history is detectable. Removal of the newest entries is a separate matter (see “Detecting removal of the newest records” below). Earlier records are not linked retrospectively. |
| Concurrent-write detection | Most append paths refuse a conflicting simultaneous write to a record’s history. One path, a document saved directly, narrows the exposure window to a single read-then-write rather than closing it; that is a recorded decision. |
| Offerings | Village is live and available by paid subscription. Conduct Record™, AVA™, Attested Accounts™, Provenance, the consignment file and the Email Decision Record are available on request. The Governance API is available on request as a sandbox; evaluation access is a one-time link issued at MDSL’s discretion. “Live” is used only for what a customer uses in production; take-up is addressed under “Demand”. |
| Blocking an agent’s action | Conduct Record evidences authority. A pre-action verdict is what the Governance API returns (sandbox today); acting on it is the caller’s system. |
| Where things sit | Records are stored on OVH (France) and Catalyst Cloud (New Zealand); neither is US-owned. Timestamps come from Certum (Poland), and from Aruba PEC (Italy) on request. TLS certificates are issued by Let’s Encrypt, a US non-profit. AVA sends its questions to AI assistants through their published interfaces; most are run by US companies. The public-randomness source planned for audit sampling is an international network whose operators include US organisations. No US-owned provider hosts or stores the records. |
Built, not yet in use
| Capability | What that means |
|---|---|
| Qualified EU timestamp authority | Built. Aruba PEC is contracted, built and tested against its live endpoint. Available on request, opt-in; switched on per customer because each stamp is priced (NZ$5 per stamp for AVA; NZ$114 per 100 receipts for Attested Accounts). |
| Split-key signing | A 2-of-3 split-key scheme is built and deployed, with no customer on it. It would mean no single holder can sign alone. Moving a customer onto it needs the key holders chosen and a migration, and neither is done. |
| Detecting removal of the newest records | Deployed, but compaction has no production caller yet, so the check is not in use. Built and verified in tests. Switching it on needs one further design step and a separate approval. |
| Signer identity by did:x509 in the offline checker | Built and deployed, not wired to any route or record; the platform does not sign with certificates. The offline checker, served as a download, can confirm that a signer named by a did:x509 identity chains to a root certificate you supply, at a date you choose. The code passes all 220 of Microsoft’s published test vectors (65 within the IETF draft’s scope). The draft is not adopted by any working group; revocation is not checked; the time used is yours. AI agents wrote and reviewed it. |
| Spot-checks seeded from public randomness (drand) | Built; not running. Weekly examination periods are committed and time-stamped before they start. The units to examine are chosen from a public drand beacon round, the unit list is bound to the time-stamped daily roots, and an offline script that anyone can run recomputes the selection. It runs only once it is switched on. |
Prototypes
Built and run in development, on our own machine or a test network. Not deployed to customers and not audited.
| Capability | What that means |
|---|---|
| Zero-knowledge research prototypes | Research prototypes, run on our own machine on two third-party proving tools, show for a fixed certificate profile that a certificate chains to a root without revealing it. Unaudited and not deployed; no certificate check runs on any blockchain. Built and reviewed by AI agents only. |
| Attestation contract on a test network | An attestation contract on Midnight’s Preview test network records that our own verifier accepted a proof; it does not verify the certificate chain. Test data only, nothing on mainnet, not deployed to customers, unaudited, built and reviewed by AI agents only. |
Still ahead
| Matter | What that means |
|---|---|
| A New Zealand time-attestation authority | MDSL would welcome a New Zealand organisation in that role. It is a separate initiative and is not assumed to be part of any MIO round. |
| A practice-facing console for Attested Accounts | Not built; it follows a client-access rule and practice pricing. It would be a single screen for an accountant or bookkeeper who looks after many small clients: every client in one place, whether each client’s records are being sealed, the history and verification bundle of any invoice, and a way to add a new client without setting each one up separately. Two things shape it. A practice console needs a rule, agreed with each client, for what the practice may see of their financial records, because the platform’s distributor machinery is designed to give a distributor no access to a client’s content. And it needs a decision on how practices are priced. Until then a practice works inside one client’s Business Village at a time, which is what the Attested Accounts site describes. |
| Demand | The architecture is the foundation, not proof of demand. Paid deployments are how an early commercial phase would test it. |
| MIO-STD-01 | MIO-STD-01 is MDSL’s draft standard for how records are sealed and timestamped. It is a working draft, not adopted by an external standards body. The timestamp arrangement in use today does not yet meet its plurality requirements: it relies on one authority, and the qualified authority would be a second inside the same legal bloc (both EU), which the draft’s jurisdictional-diversity rule does not count as diverse. |
What a sealed record does and does not show
A signed, time-attested record shows that particular bytes existed and were signed by a particular key at a stated time, subject to key custody and the timestamp authority. It does not show that the content was true, that a person was authorised, that a legal duty was met, or that any harm was prevented. These words are not used about any product here: tamper-proof, court-defensible, legally admissible, compliant, certified, immutable, safe, or “prevents agent harm”.