The SSST Substrate
24 September 2026 · John Stroh, Director, My Digital Sovereignty Ltd
What it is
SSST (Sovereign, Sealed, Signed and Timestamped) is the design MDSL applies across its products: AVA™ seals measurement runs on it, MIO° Conduct Record seals mandates and agent-identity records on it, and Attested Accounts™ seals invoices, quotes, recurring invoices, expenses and time entries on it. The Email Decision Record™ and Provenance™ seal their records on it too. It is not sold on its own — customers buy AVA, Conduct Record™ or Attested Accounts — but it is the reason each of those products can make an evidence claim that a dashboard score alone does not offer: a record sealed, signed and time-stamped by an outside authority, and held on infrastructure in a jurisdiction the customer chose.
Each product's own one-pager states its build status individually — this document describes the shared design and, specifically, the governance-and-audit substrate underneath Conduct Record and Attested Accounts, which the recent changes below directly hardened.
Recent changes, September 2026: two parts live, one built and verified
Every sealed record on this substrate keeps an append-only history of what happened to it and when. Three real gaps in how that history is checked were closed in September 2026, each fixed only after the failure it closes was reproduced, not merely reasoned about. Two are live today; one is built, tested and shipped as code that waits on a deliberate switch-on step rather than further build work:
- Live now: conflicting simultaneous writes to a record's history are detected. Two processes writing to the same record's audit trail at the same instant used to risk one silently overwriting the other, or recording an entry that claims the wrong predecessor. Most write paths refuse a conflicting write outright; one path (a document being saved directly, rather than updated by query) narrows the exposure window from unbounded to a single read-then-write rather than closing it completely — a scope decision made and recorded, not an oversight.
- Live since 24 September 2026 (11:30 NZST): a deleted or reordered entry becomes detectable, for records written from that time. Closes a gap where an internally-consistent but incomplete history could pass every check. Proven by testing the platform's own internal check against the independent, publicly downloadable verification tool a customer's auditor would use — the two now agree on every broken-link case tested, closing a real disagreement that existed before 24 September 2026.
- Built and verified: a history quietly truncated right after a scheduled compaction becomes detectable too — the one case link-checking alone cannot see, because nothing survives to point at what's missing. An independent, point-in-time attestation of the record's length closes it.
The concurrent-write safety above is live in production today, protecting the record types built on this substrate's governance-and-audit layer — Conduct Record's mandates, the wider governance platform, and, since 24 September, the five Attested Accounts finance record types. The truncation check is shipped as additive code and confirmed working in testing; turning it on needs one remaining design step and a separate approval, not further build work on what's described above.
Built vs roadmap
Status as of 24 September 2026 (signing-host and verifier entries updated 19 October), established by AI agents from the code and plans; no person has checked every line (see the status page).
| Capability | Status | What it means for a customer |
|---|---|---|
| Seal, sign and time-stamp (by an outside authority) the record types built on it | Available on request (deployed in production) for Conduct Record and Attested Accounts; built and tested end to end for AVA | The same design applied per product, not rebuilt from scratch each time |
| Offline verification, no account, no live query | Live | A third party checks a record on their own machine, with no account and no call to MDSL. Until the signing key is separated, the check still relies on MDSL not having rewritten and re-signed the record. |
| Concurrent-write safety on the governance-and-audit substrate | Live. Most paths refuse a conflicting write; direct document saves narrow the window to a single read-then-write | Ordinary concurrent use is detected on most paths; one path is narrowed, not closed |
| Attested Accounts: sealing of invoices, quotes, recurring invoices, expenses and time entries | Available on request on both production servers. The practice console follows a client-access rule and practice pricing | Finance records are sealed on the same design as the other products |
| Detection of altered history | Live on both production servers since 24 September 2026 (11:30 NZST), for records written from then; earlier records are not linked retrospectively | A deleted or reordered entry in the middle of a history becomes detectable, not just a bad signature |
| Truncation detection via independent length attestation | Built and verified in tests; not yet called in production | Would close the one gap hash-linking alone cannot close, once switched on |
| Unpredictable, publicly-verifiable audit sampling | Prototype: built and tested in development, not in production; the audit process is not yet designed | Not available to customers. The aim is a sample nobody can predict in advance; that is not established until the start and end of an audit period are settled. |
| eIDAS-qualified timestamping | 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) | A qualified timestamp under the EU's eIDAS regulation; how it is treated in any proceeding is a legal question we do not advise on. On top of the standard one |
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.