Status
What is live, what is built, what is planned
Every claim these pages make about a product, with its status; each claim carries its own date, and the latest is 22 October 2026. This page is generated from the same register as status.json. Live means a customer uses it in production (today, Village™); available on request means built, tested and deployed and available to a customer on request; built, available on request means a feature built and tested and not yet switched on; built and deployed means built, tested and deployed and in use for named tenants only or not yet in use, as each entry states; a prototype is built and run in development, on our own machine or a test network, is not deployed to customers and is not audited; a statement describes the company, a standard, a definition or a policy and is not a product capability; planned and not built are not available. Statuses were established from the code and plans by AI agents working under John Stroh’s direction; no person has checked every line. MIO has not been formed and nothing here is an offer.
MIO and the platform
| ID | Statement | Status | Qualifier | As at |
|---|---|---|---|---|
| EST-01 | MIO is a proposed service company that would run and stand behind the commercial service around MDSL's products. | Planned | it is proposed and has not been formed; no investment, ownership, distribution appointment or legal right has been agreed | |
| EST-02 | MDSL owns the work and the infrastructure today, and the code is proprietary. | Statement | this describes today only; what MIO would hold, and on what terms, is not settled and would be documented and negotiated; MDSL's intention to move what it has built towards open source, in stages, is recorded as intent only in EST-30; MDSL states nothing further here | |
| EST-03 | No distributor has been appointed. | Not built | the first arrangement is meant to be built with the first distributor; it is an invitation to explore, not a franchise, an exclusive territory or an offer of employment | |
| EST-04 | No distributor margin, wholesale rate, portal or distributor terms have been published or agreed with any distributor. A draft agreement and share schedule exist and have not been sent to anyone. | Not built | terms are agreed directly with John Stroh under one standard share schedule; it is shown after a non-disclosure agreement and never at a first meeting; no distributor or practice rate is published | |
| EST-05 | Nothing is being offered: no investment, valuation, term sheet, exclusivity or commitment to appoint a distributor. | Not built | conversations are by invitation; any commitment would follow diligence, agreed terms, professional advice and signed documents; nothing here is legal, tax, accounting, securities, investment or financial advice | |
| EST-06 | Village is available by paid subscription through checkout; every other product is available on request from MDSL; nothing is free or open sign-up. | Live | there is no free tier, trial or anonymous demo; free evaluation is arranged directly by John Stroh, on a one-time token tied to a single address where a token is used | |
| EST-07 | Records are stored on OVH (France) and Catalyst Cloud (New Zealand); neither is US-owned. | Live | this covers where records are stored; TLS certificates come from Let's Encrypt (a US non-profit), AVA™ sends its questions to AI assistants run mostly by US companies, and the public-randomness network planned for audit sampling includes US operators | |
| EST-08 | No US-owned provider hosts or stores the records. | Live | this is a statement about hosting and storage of records only; it does not extend to every dependency | |
| EST-09 | The timestamp authority in use today is Certum (Poland), a non-qualified service. | Live | it is non-qualified: it carries no eIDAS qualified status; if it does not issue a stamp the record says so and the request is retried nightly | |
| EST-10 | Time stamps from outside time-stamping authorities under RFC 3161 are in use: Certum (Poland) stamps records, and Portugal's Cartao de Cidadao time-stamping authority stamps the estate root. | Live | the stamps show that particular bytes existed by a stated time, subject to the authority; they are not described as qualified; how a time stamp is treated in any proceeding is a legal question MDSL does not advise on; the arrangement still relies on authorities in one region | |
| EST-36 | The qualified Aruba PEC (Italy) time-stamping authority is contracted, built and tested, and available on request as an opt-in; it is switched on per customer because each stamp is priced. | Built, available on request | it is opt-in and arranged per customer because each stamp carries a cost; it has not been used on a live customer engagement; how a qualified timestamp is treated in any proceeding is a legal question MDSL does not advise on | |
| EST-11 | No New Zealand qualified time-stamp authority exists. | Not built | 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 | |
| EST-12 | Sealed records written from 24 September 2026, 11:30 NZST are hash-linked, so a deleted or reordered entry in the middle of a history can be detected. | Live | earlier records are not linked retrospectively; removal of the newest entries is not yet detectable (see EST-13) | |
| EST-13 | Detecting removal of the newest records after a compaction is built and verified in tests; compaction itself has no production caller yet. | Built and deployed | not available to customers: turning it on needs one further design step and a separate approval; until then removal of the newest entries is not detectable | |
| EST-14 | Conflicting simultaneous writes to a record's history are detected on the governance-and-audit substrate. | Live | most paths refuse a conflicting write; 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 | |
| EST-15 | MDSL holds the signing key for every tenant. For every active Village the proof-signing key sits on a separate signing host that MDSL also operates (EST-16). | Live | a customer does not hold the key, and MDSL could in principle write records under it; on the separate host the key sits in a different place but is still in MDSL's hands; no tenant count is stated here, and the form 'every active Village' is the operator's of 22 Oct 2026 | |
| EST-16 | Signing keys sit on a separate signing host, outside the process that writes records, for every active Village; a 2-of-3 split-key scheme (FROST) is built and deployed with no tenant on it. | Built and deployed | The separate host is operated by MDSL: the key is in a different place, but still in MDSL's hands, so a verified record is not protected against rewriting by the platform. The split-key scheme has no key holders chosen and no migration has been prepared, so no tenant can be moved onto it yet. No tenant counts are given; the form 'every active Village' is the operator's of 22 Oct 2026. | |
| EST-17 | A third party can check a downloaded record bundle offline without an MDSL account. | Live | the default check uses keys carried in the bundle; an optional check fetches keys from the customer's published identity document; the check shows the record is unchanged since signing, subject to key custody and the timestamp authority, not that its content is true | |
| EST-18 | A sealed record shows that particular bytes existed and were signed by a particular key at a stated time. | Statement | subject to key custody and the timestamp authority; it does not show the content was true, that a person was authorised, that a legal duty was met, or that any harm was prevented | |
| EST-19 | Spot-checks seeded from public randomness (drand): built and tested in development, not in production. | Prototype | not available to customers, not deployed and unaudited; when an audit period begins and ends is still to be decided; the randomness network’s operators include US-headquartered organisations | |
| EST-20 | MIO-STD-01 is MDSL's draft standard for how records are sealed and timestamped; no external standards body has adopted it. | Statement | it is a working draft; the timestamp arrangement in use today carries a disclosed non-conformance with section 5.3.2 (plurality: it relies on one authority, and a qualified second authority would sit in the same legal bloc) | |
| EST-21 | "Live" in MDSL's pages means a customer uses it in production (today, Village); a product that is built and deployed is "Available on request". Neither status proves that demand exists. | Statement | the architecture is the foundation, not proof of demand; paid deployments are how an early commercial phase would test it | |
| EST-22 | The status statements on the evidence page were checked by AI agents working under John Stroh's direction, against the code and, for sealing, hash-linking and concurrent-write, the live systems. | Statement | the checking was done by AI agents; no human reviewer is claimed | |
| EST-25 | The name MIO is used for three different things: the proposed company, the MIO° prefix on the Conduct Record™ product, and the draft standard MIO-STD-01. | Statement | The only sanctioned expansion of MIO in MDSL materials is "Machine Intelligence Omega". No other expansion is used. | |
| EST-26 | The downloadable offline verifier can check that a record's signer is named by a did:x509 identity whose certificate chain reaches a trust anchor the person checking supplies, at a time they supply. | Built and deployed | Present in the verifier served at mysovereignty.digital/downloads/verify-record.js and agenticgovernance.digital/downloads/verify-record.js (same file, observed 19 October 2026). Revocation is not checked, and the time used is the checker's. The platform does not yet sign with certificates, and nothing is wired into a route or customer record. did:x509 is a draft proposal published through the IETF, not adopted by any working group; the code passes all 220 vectors in Microsoft's published set, 65 of which fall within the draft's scope. The code was built by AI agents and reviewed by AI agents in repeated rounds; no person has audited it. | |
| EST-27 | A zero-knowledge proof that a certificate chains to a given root key and is in date, without showing the certificate, has been generated and checked in research prototypes on two proving systems. | Prototype | Research prototypes on our own machine for a fixed certificate profile, built on two third-party proving tools. No certificate check runs on any blockchain (EST-29 records a test-network attestation only). Unaudited and not deployed. Built and reviewed by AI agents only. | |
| EST-29 | An attestation contract on the Midnight Preview test network records that our own verifier accepted a proof; it does not verify the certificate chain. | Prototype | test data; nothing on mainnet; it does not verify a certificate chain; unaudited; reviewed by AI agents only | |
| EST-30 | MDSL's intention is to move what it has built towards open source, in stages. This is an intention only: nothing has been released, nothing is dated, no licence has been fixed and no stage has been named. | Planned | stated as intent only; the software is proprietary today and products are available on request (Village by paid subscription); no order, dates or licence are stated | |
| EST-31 | MIO, if formed, would earn by sharing in recurring service revenue and would manage the distributors it appoints and support implementation and customer success; MDSL would build and operate the platform and infrastructure. Distributors would be cooperative partners who keep what they charge for their own services and share in subscription revenue. | Planned | a proposal only: MIO has not been formed, no distributor has been appointed (EST-03), no share or terms have been published or agreed (EST-04), and how the revenue is shared between MDSL and MIO is not settled | |
| EST-32 | A conformance suite for the offline checker is being prepared; none exists yet. | Planned | being prepared means not built; no date; MIO-STD-01 remains a draft and none is adopted (EST-20) | |
| EST-33 | MDSL publishes three sites: amiomega.digital is the overview of the proposed MIO and the product portfolio, agenticgovernance.digital carries the research and the Tractatus framework the products draw on, and mysovereignty.digital is the community platform where Village runs and where members sign in, and MDSL's company pages. | Statement | this describes what the three sites are, not what MIO is; MIO is proposed and has not been formed (EST-01); no licence, date or stage is stated | |
| EST-34 | The software is built by AI agents under John Stroh's direction, and reviewed by AI agents; no person has audited it. | Statement | describes how the portfolio was built and checked, not its quality; the operator confirmed on 20 October 2026 that no person has audited the portfolio; see EST-22 | |
| EST-35 | A test-network attestation contract against the Midnight network, using test data, records that our own checker accepted a proof. | Prototype | test network only; test data only; there is no production anchoring and no partnership; built and reviewed by AI agents; no person has audited it | |
| DIR-01 | Our stated intention is to move what we have built towards open source, in stages: the checking programs and standards first, then the substrate, then the Governance API. The reason is continuity: a record that has to stay checkable for years should not depend on one company, one founder or an escrow agreement. | Planned | intention only: nothing has been released, no date is set and no licence is fixed; each stage is released by the operator in writing, and none has been; what MDSL sells is the running of it: hosting in New Zealand and the EU, key custody, assurance, accreditation, support and continuity | |
| DIR-02 | Our direction is a hybrid design: business records stay on infrastructure under New Zealand or EU control, and only fingerprints are committed to a public network. | Planned | direction only: not built for production; the only work so far is the test-network contract in EST-35; no date is set |
Village
| ID | Statement | Status | Qualifier | As at |
|---|---|---|---|---|
| VIL-01 | Village is a members-only community and organisation platform built and operated by MDSL in New Zealand, for families, clubs, small businesses and governance bodies. | Live | statuses come from the code and product documents, not from a check of the live systems; Village is available by paid subscription through checkout | |
| VIL-02 | Each Village's data is held in New Zealand (Catalyst, Wellington) or the EU (OVH, Strasbourg), and each Village is separate from every other. | Live | no US-owned provider hosts the records; see EST-07 for the dependencies outside that boundary | |
| VIL-03 | Every Village has a member directory, channels, events, polls and voting, documents, video calls on self-hosted Jitsi, a constitution log and a Village assistant. | Live | the assistant answers from the Village's own content (FAQ retrieval); a fuller AI is included at the top tier and is an add-on below it; GPU capacity limits AI workloads | |
| VIL-04 | Village is priced at NZ$44, NZ$79 and NZ$114 per month for the Families, Communities & Clubs and Village Small Business tiers, with 200 members included and no per-seat fee. | Live | these are the figures on the published pricing page; annual prices are NZ$422, NZ$758 and NZ$1,094; the tiers include 10, 10 and 50 GB of storage and 500, 500 and 2,000 video minutes a month | |
| VIL-05 | Published add-ons are 25 GB extra storage at NZ$26 a month, 250 extra video minutes at NZ$18, priority AI at NZ$44 and email at NZ$35. | Live | these four are the add-ons with a published price; the Sovereign Database is listed on the mysovereignty.digital pricing page from NZ$175 a month, available on request and subject to capacity (see VIL-06) | |
| VIL-06 | A dedicated Sovereign Database, with the customer's data in its own database on New Zealand infrastructure, is planned; a request can be discussed, subject to capacity. | Planned | depends on capacity; MDSL's pricing page at mysovereignty.digital lists it from NZ$175 a month, confirmed by the operator on 20 October 2026; the figure is MDSL's published price, and MIO quotes no price of its own | |
| VIL-07 | Governance and regulated Village tiers are priced per engagement, are not on the price list, and are arranged directly with MDSL for now. | Planned | governance queue, audit retention and assurance artefacts are planned, not a listed product; Village Kāhui Māori (for iwi, hapū and Māori organisations) is by arrangement | |
| VIL-08 | Direct messages are encrypted in transit but are not end-to-end encrypted; the server can read message content. | Live | direct messages are encrypted in transit but not end-to-end encrypted | |
| VIL-10 | Village Assembly puts a question to a Village: an AI-simulated assembly argues it with scrutiny, a contestability report shows where the argument is weak, and the group then takes it to a human phase to decide, with dissent kept word for word. | Live | opt-in per Village and set up by MDSL on request, with no self-serve checkout; it is listed on the published pricing page; at the 12 October count it was switched on for one demonstration Village only; the sealing route was deployed on 12 October but no real sealed deliberation is on record yet | |
| VIL-11 | Open Floor lets members raise ideas in their own words and keeps a minority idea whole instead of averaging it away. Breakdowns for groups below a minimum size are withheld, a result carrying a member’s identifier is refused before it is shown, and each member chooses whether a contribution appears under their name, a pseudonym or anonymously. | Live | opt-in per Village and set up by MDSL on request, with no self-serve checkout; it is listed on the published pricing page at a flat price per organisation; at the 12 October count it was switched on for demonstration Villages only; no real sealed result is on record yet | |
| VIL-12 | Village can read, check and file a Peppol-format (PINT A-NZ) e-invoice file that a signed-in Business user uploads. It does not receive invoices from the Peppol network, and live sending is not connected. | Built and deployed | delivery from the network, and live sending, depend on an approved Peppol access point being in place and are not on offer. | |
| VIL-14 | Village is built with five interface languages: English, German, French, Dutch and te reo Māori. | Live | this is Village only; AVA's language menu does not translate (AVA-05); statuses are from code, not a live check | |
| VIL-15 | Village handles cultural boundaries in code: content marked tapu or restricted can block AI processing, and the code states that AI cannot determine tapu status. | Live | this is a content-marking control; it is not an AI judgement of what is tapu | |
| VIL-16 | Deliberation Village gives a team a map of a topic, team strands, signed records and a ratification step, for working a topic through before it becomes a decision. | Live | priced per engagement and arranged with MDSL; at the 12 October count it was switched on for one Village only; no real ratification is on record yet | |
| VIL-17 | Consolidated Village Consensus draws the answers of several Villages to one question into a single map that keeps each minority position whole and attributed, and the sealed map can be checked offline. | Live | for a coordinating Village and its partner Villages, priced per engagement and arranged with MDSL; at the 12 October count it was switched on for demonstration Villages only; no real sealed consensus map is on record yet | |
| VIL-18 | The Civic Assembly App lets a council or agency run a consultation round: residents enter by an invitation token, contributions are kept whole, and the outcome is a sealed record that a resident can check with a verifier page. | Built and deployed | switched on in production on 13 October with one demonstration round; not on the price list and no price has been set; each Village also needs Open Floor switched on; no real sealed consultation is on record yet | |
| VIL-19 | Village subscriptions are paid through Airwallex (NZ) Limited, the only payment provider; checkout opened to real payments on 19 June 2026. | Live | Established from the go-live record of 19 June 2026; not re-tested since. | |
| VIL-20 | A Village member can file a data-rights request (access, rectification, erasure, restriction, portability, objection or withdrawal of consent); each carries a 30-day response deadline that the member can see, and the Village’s administrators are emailed when a request needs a person’s decision. | Live | Established from the code on 19 October 2026 by an AI agent; no person has audited it. The deadline is the one set in the code. Not re-tested against a live Village. | |
| VIL-21 | Villages can federate: two Villages that each agree can link, with agreements, a federation card that shows only a display name and village name, and, for each member, settings for who may call or message them, including a list of trusted people. | Live | Established from the code on 19 October 2026 by an AI agent; no person has audited it. It is off by default and works only when both Villages agree and each member opts in; not re-tested against a live pair of Villages, and the number of Villages using it is not stated. | |
| VIL-22 | A Village member files an access or portability request, confirms it from an email link, and when it is completed the member is emailed a link to the signed-in data-rights page, where a Download button collects the file (JSON). | Live | Established from the code and a headless render by AI agents on 20 October 2026; no person has audited it. No real request has completed in production yet, so the delivery path has not been seen working on a live Village. The data-rights page is only partly translated (the heading, title and download controls change language; the rest stays in English). Export files have no expiry yet. | |
| VIL-23 | A Village owner, administrator or moderator can export the Village's shared content records, one record type at a time, through the Village's programming interface. | Live | Established from the code by an AI agent on 20 October 2026; no person has audited it. There is no screen for it: it is used through the programming interface. It covers fourteen content record types. Records marked private or owner-only are left out unless the person exporting wrote them. A record type is refused whole if any record in the batch has no provenance hash, so an export can fail rather than return partial results. Ordinary members can get only hashes or counts; a request from them for full records is refused. Owners, administrators and moderators receive the full records. Not re-tested against a live Village. |
AVA, the AI Visibility Auditor
| ID | Statement | Status | Qualifier | As at |
|---|---|---|---|---|
| AVA-01 | AVA (AI Visibility Auditor) puts the questions an organisation's buyers ask to AI assistants, records each answer verbatim with the model and time, and compares it with what the organisation's own site publishes. | Available on request | a gap between an answer and the site is the finding; it is a measurement, not an official ruling or a score of ranking; available on request | |
| AVA-02 | AVA puts buyer questions to AI assistants through their published interfaces and records each answer with the assistant and the time. | Available on request | The set of assistants used in a run is recorded with that run; the measurement itself reaches mostly US-owned providers, so only the record is sovereign. | |
| AVA-04 | AVA compares answers with the site and produces findings and draft fixes. | Available on request | anything the tool suggests is labelled not an official ruling; verdicts are labelled non-authoritative in the data | |
| AVA-05 | AVA's interface is in English only; the language menu shows te reo Māori, German, French and Dutch but does not translate the pages. | Not built | other languages are planned; the interface works in English only | |
| AVA-06 | Sealing an AVA run (hash, signature, time-stamp from an outside authority) is built and has run once end to end in testing on a real site; no paying customer's run has been sealed. | Built, available on request | the seal works in testing; it has not been used on a customer's audit; MDSL holds the signing key; available on request (contracted and built means available on request: operator ruling of 19 August 2026) | |
| AVA-07 | An offline verification bundle for a sealed AVA run is built, so a third party can check a sealed run without MDSL. | Built, available on request | it applies only once a run is sealed, which has not yet been done for a customer | |
| AVA-08 | A qualified eIDAS timestamp for an AVA run, at NZ$5 each and opt-in, is contracted and tested against the provider’s live endpoint, and available on request as an opt-in; it is switched on per customer because each stamp is priced. | Built, available on request | how it is treated in any proceeding is a legal question MDSL does not advise on; see EST-10 | |
| AVA-09 | AVA has a self-hosted install kit, built and issued by MDSL on request, that lets crawling run from the customer's own network. | Built, available on request | it is not a public download; sealing stays with MDSL; the measurement still reaches US-owned assistants | |
| AVA-10 | AVA is priced at NZ$263 per project per month for ongoing tracking, NZ$526 for a one-off run, and NZ$5 per qualified timestamp (opt-in). | Available on request | sealing is built but not yet switched on for customers; available on request; no other price is published | |
| AVA-11 | The measurement itself is not sovereign, because the questions go to AI assistants mostly run by US companies (OpenAI, Perplexity, Anthropic); only the record is kept in New Zealand or the EU. | Available on request | AVA's own FAQ says the same | |
| AVA-12 | AVA evidences what AI assistants said and when; it does not prevent or change anything. | Available on request | its buyer is a governance, risk or regulatory lead who needs a record, not a marketing team wanting a dashboard score |
MIO° Conduct Record
| ID | Statement | Status | Qualifier | As at |
|---|---|---|---|---|
| CON-01 | MIO° Conduct Record is a sealed register of what an organisation's AI agents are authorised to do, and which agents exist. | Available on request | it records authority; it does not block, enforce or prevent anything; available on request | |
| CON-02 | A change to a mandate is a new dated record that supersedes the old one, and the old record is kept. | Available on request | the ordering relies on the platform's own clock, and the lookup says so | |
| CON-03 | A "mandate in force at time T" lookup is available through the API on both production servers (NZ and OVH). | Available on request | the lookup shows what was recorded, as recorded; for every active Village the proof-signing key sits on a separate signing host that MDSL operates (EST-16), and a verified record is not protected against rewriting by the platform operator | |
| CON-06 | An auditor can check a Conduct Record offline without an MDSL account. | Available on request | MDSL holds the signing key for every tenant; for every active Village the proof-signing key sits on a separate signing host that MDSL also operates (EST-16). | |
| CON-07 | Enforcement, checking an agent's action against its mandate before it runs, is not built and has not been started. | Not built | Conduct Record evidences authority; it does not yet block actions; the next step would be a census of where agents act, before any enforcement design | |
| CON-08 | Conduct Record is priced at NZ$526 for a Sealed Statement and NZ$263 per agent per month for a Standing Record pilot of up to five agents with a 90-day term. | Available on request | available on request; no other price is published | |
| CON-09 | Continuous monitoring of agents has no published price and is not offered. | Not built | it awaits an SDK that does not yet exist | |
| CON-10 | MDSL publishes a measured recognition rate for out-of-mandate acts of 100% for blatant, 92% for moderate and 58% for subtle acts, with zero false positives across 36 clean cases. | Available on request | the 58% subtle rate means low sampling rates would miss most isolated subtle acts, so it caps what can be promised; the audit regime is not switched on |
Attested Accounts™
| ID | Statement | Status | Qualifier | As at |
|---|---|---|---|---|
| ACC-01 | Attested Accounts is an evidence layer over the Business Village's invoicing, quoting, recurring invoicing, expense and time tracking. | Available on request | it is not an accounting system, an audit opinion or accounting advice; it sits alongside accounting, not in place of it; it is built into the Business Village and not sold as a separate product | |
| ACC-02 | Every write to an invoice, quote, recurring invoice, expense or time entry is signed under the tenant's key when it happens. | Available on request | alteration after signing is detectable; it says nothing about whether the figures are right, complete or lawful; the key is held by MDSL (EST-15) | |
| ACC-03 | Finance records written from 24 September 2026, 11:30 NZST are hash-linked, so a deleted or reordered entry can be detected. | Available on request | earlier entries are not linked retrospectively; see EST-12 | |
| ACC-04 | An invoice has an action-history view and a downloadable verification bundle that a third party can check offline. | Available on request | invoices only; the history names a person only for creation, otherwise a system note; quotes, expenses and time entries do not yet have these | |
| ACC-05 | Quotes, expenses and time entries are sealed but do not yet have a history view, a receipt or a verification bundle. | Not built | sealing covers them; the surfaces do not yet exist | |
| ACC-06 | Erasure requests report which finance records are held under a retention rule and scrub the erasable remainder. | Available on request | no retention period is stated on the pages | |
| ACC-07 | A qualified (RFC 3161, eIDAS) timestamp receipt for one invoice is built and available on request as an opt-in; it is switched on per customer because each receipt is priced. | Built, available on request | spend is gated by an allow-list that is empty by design; the paid path was verified by code trace, not live; available on request | |
| ACC-08 | Batch receipts of up to 1,000 records and ten included receipts a month are not available, although both are stated on the pricing page. | Not built | receipts exist for one invoice at a time and no monthly allowance is enforced | |
| ACC-10 | The practice-facing console, one view across many small clients, is not built. | Not built | it is held until a client-access rule and practice pricing are decided; until then a practice works inside one client's Business Village at a time; the distributor model deliberately grants no access to member content, so it needs a new capability | |
| ACC-11 | Agentic bookkeeping, and any MIO-STD-01 claim for it, is not built. | Not built | nothing on the Attested Accounts pages is a conformance claim | |
| ACC-12 | Attested Accounts has two published prices: NZ$263 per Village per month on the Attested Accounts page and NZ$114 per month for the Business tier on the Village price list; a pack of 100 Qualified Receipts is NZ$114. | Available on request | no distributor or practice rate exists; the receipt pack is priced although qualified receipts are not switched on for any customer; access is arranged directly with John Stroh | |
| ACC-13 | Sealing is switched on in the software for every Business-featured Village, and the product is available on request. | Available on request | there is no cheaper unsealed tier and no stripped accounts-only product; a separate SKU is a later build decision | |
| ACC-14 | Attested Accounts can read, check and file a Peppol-format (PINT A-NZ) e-invoice file that a signed-in Business user uploads. It does not receive invoices from the Peppol network, and live sending is not connected. | Built and deployed | Peppol is the international network for sending invoices directly between accounting systems; delivery from the network, and live sending, depend on an approved Peppol access point being in place and are not on offer. | |
| ACC-15 | Distributor provisioning for Attested Accounts is switched off by design. | Not built | the distributor model never grants member-content access; no distributor wholesale terms, portal or practice console exist | |
| ACC-16 | An Attested Accounts invoice can carry a lot reference, a quantity and a unit that are committed together, so that an invoice can be tied to a lot. | Built and deployed | built, tested and deployed 22 Oct 2026 (commit f49c61e5b3); the three lot fields are set together or none; an invoice without them behaves as before; the link shows that the invoice names the lot, not that the goods or figures are right; the invoice has no day root or outside time stamp; built and reviewed by AI agents; no person has audited it | |
| ACC-17 | An invoice can be shared as a redactable member: every field is held as a salted hash and only lot reference, quantity, unit, currency, total and date can be shown; an offline checker, served for download, recomputes the hashes and checks the signed record behind the invoice. | Built and deployed | built, tested and deployed 22 Oct 2026 (commit f49c61e5b3); the checker is served at mysovereignty.digital/downloads/invoice-bundle-verifier.js and agenticgovernance.digital/downloads/invoice-bundle-verifier.js, SHA-256 96ac2ac454da385d1f0b93ed2040e2bbb1959973135af57820161ad64da5111f; a hidden field shows that it exists and has not changed, not what it says; it does not show the figures are right, complete or paid; the invoice member has no day root or outside time stamp of its own; Attested Accounts day roots are not built, so invoices are not in the estate root; the consignment routes can include an invoice by invoice_id, switched on per Village on request (commit 29d321e1e0); built and reviewed by AI agents; no person has audited it |
Governance API
| ID | Statement | Status | Qualifier | As at |
|---|---|---|---|---|
| API-01 | The Governance API is an interface other software calls before an AI agent acts: a proposed action goes in and a verdict of allow, gate (a human decides) or deny comes back with coarse reason codes and an Ed25519-signed receipt. | Built and deployed | available on request, today as a sandbox only: access is a one-time token tied to a single address, and no production keys are issued (API-02, API-05); the caller's own system must act on the verdict | |
| API-02 | Sandbox access is by invitation from John Stroh, issued as a one-time token tied to a single address. | Available on request | a request form on the pricing page is an enquiry and creates no right to access; access is at MDSL's discretion, by one-time token; the sandbox is for building and testing an integration | |
| API-03 | In the sandbox the verdict comes from a simple rule table, and its receipts are labelled non-authoritative. | Available on request | sandbox receipts are not a governance decision a customer should rely on | |
| API-04 | The full decision engine, with action classification, is built and deployed, and switched off. | Built and deployed | it is not offered: sandbox verdicts come from a simple rule table and are labelled not authoritative, and the engine’s authoritative verdicts begin only when MDSL decides to switch it on; a corpus-based content check of kōrero claims is a second flag, also off | |
| API-05 | No production keys are issued. | Planned | they follow published terms of service and a data processing agreement, both still drafts, and a security review; no date | |
| API-06 | A receipt can be verified offline against the tenant's DID document with the client verifier, without any call to MDSL. | Built, available on request | sandbox receipts are non-authoritative; the 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 | |
| API-07 | The Governance API is offered only as an add-on to a Village subscription; there is no API-only plan. | Available on request | every customer must also be a Village | |
| API-08 | Governance API prices (Governance Standard, Governance Plus, Assurance) are given on request and none is published. | Planned | no production key can be issued yet and no figure is quoted | |
| API-12 | An independent penetration test of the API has not been done; its scope of work is drafted and has not been sent. | Not built | sandbox access is tied to it in the published wording | |
| API-13 | The Governance API sandbox was reviewed by an experienced architect, as an expert peer review. | Available on request | The reviewer is a design partner, so this is peer review and not arm’s-length assurance. It is not an independent penetration test (API-12). Adversarial review by AI agents that did not build the API, and automated scanning, were done as well. |
The SSST design
| ID | Statement | Status | Qualifier | As at |
|---|---|---|---|---|
| SST-01 | SSST is the design MDSL applies across its products; AVA, Conduct Record and Attested Accounts each seal records on it. | Available on request | it is not sold on its own; each product implements it separately; it is the reason a product can make an evidence claim, not a guarantee of one | |
| SST-02 | Sealing (hash, signature, time-stamp from an outside authority) is deployed in production for Conduct Record and Attested Accounts, and built and tested end to end for AVA without use by a paying customer. | Available on request | per-product status differs; see AVA-06 |
Email Decision Record™
| ID | Statement | Status | Qualifier | As at |
|---|---|---|---|---|
| EDR-01 | Signing keys are held apart from the application that writes records, for each tenant moved to the separate signing host. | Built, available on request | Only for tenants moved to the separate signing host. Not every tenant is on it yet, and the Order Schedule states which applies. | |
| EDR-02 | A held email is released or refused by an approver, through a route that records who decided. | Built, available on request | Built and reviewed by AI agents. No customer is live yet. | |
| EDR-03 | Each proposed email is checked against the owner's policy before it can be sent. | Built, available on request | The owner's policy is applied. A person still approves a held email. | |
| EDR-04 | Records are held in New Zealand or the European Union. | Built and deployed | On servers we rent from OVH (European Union) and Catalyst (New Zealand). Your Order Schedule states which applies to you. | |
| EDR-05 | Mail can be sent through a Microsoft or a Google account that the subscriber connects. | Built, available on request | Descriptive use only. Google's app is in testing mode, so it is available to named test users only. | |
| EDR-06 | The Email Decision Record may be introduced by an appointed distributor once MDSL has its first paying subscriber and has said so in writing; MDSL contracts and sets it up. | Planned | introduce only; no price is published; no distributor has been appointed, so this is not available through a distributor now |
Provenance™
| ID | Statement | Status | Qualifier | As at |
|---|---|---|---|---|
| PRV-01 | Provenance is priced at NZ$495 per exporting organisation per month (Chain: up to five signing organisations and 2,000 sealed records a month), NZ$1,650 per month (Chain Plus: up to 25 signing organisations, 10,000 sealed records and 250 per-record qualified time stamps a month), and from NZ$4,000 per month for an industry scheme; a further signing organisation is NZ$114 per month, a further 1,000 sealed records NZ$114, a per-record qualified time stamp NZ$5, the split-key key ceremony NZ$950 one-off, and a certifier or auditor NZ$263 per month with 1,000 attestations. | Available on request | available on request, with no self-service signup; no other price is published; no pilot or evaluation price exists; the dossier check is free of charge by design and is not a tier | |
| PRV-02 | Provenance is available on request; evaluation access is a one-time link issued at MDSL's discretion; there is no self-service signup, trial or free tier. | Available on request | the pricing page states this once, beside the plans | |
| PRV-03 | Checking a Provenance dossier needs no account and is free of charge: the check runs in the reader's own browser, offline. | Available on request | a property of the checker, not a plan or a tier; it says what was and was not established | |
| EST-28 | Provenance has been built to hold the signing key in three ways: by the platform, which MDSL operates, under a standing authorisation the owner gives (the default); split with the platform so the two must sign together; or split among the organisation's own key holders with no share held by the platform. In both split arrangements a missing share means nothing is signed. | Built and deployed | The default arrangement is in operation. The two split arrangements are built and tested and no tenant is on either. An owner can request a switch (passkey or two-step code); completing one needs the key holders named and the key generated with them, and that tooling does not exist yet. Established from code on 19 October 2026 by an AI agent; no person has audited it. |
The consignment file
| ID | Statement | Status | Qualifier | As at |
|---|---|---|---|---|
| CSN-01 | The platform can assemble a consignment file: a Provenance dossier and an Email Decision Record dossier in one file that can be checked offline, with a signed email record linked to the lot by its lot reference; with an optional invoice_id the same routes produce a three-member version 2 file that includes the invoice. | Built and deployed | built, tested and deployed 21-22 Oct 2026; the invoice option was deployed 22 Oct 2026 (commit 29d321e1e0), needs a lot reference the lot has offered, refuses uniformly and is switched on per Village on request; the invoice member has no day root or outside time stamp of its own and invoices are not in the estate root; Provenance and the Email Decision Record are on request and no customer is claimed; the file shows records are unchanged since signing and what they link to, not that goods match the paper, that any rule is met, that a record is complete or who wrote an email; membership of the file is not attested; built and reviewed by AI agents; no person has audited it | |
| CSN-02 | A stranger can check a consignment file offline with one readable JavaScript file, SHA-256 151ef62443703208f75cf5c9a569542a46eaf3f890f3385629bc4c3374615c16, served at mysovereignty.digital/downloads/ and agenticgovernance.digital/downloads/. | Available on request | needs Node.js; runs each member checker with no network and refuses a member checker whose bytes do not match the published SHA-256; this version checks the Provenance and Email Decision Record members; the invoice is checked with its own checker, or with version 2 (CSN-04); the checker was built and reviewed by AI agents; no person has audited it | |
| CSN-03 | An owner can propose sending a consignment file to one outside recipient through the Email Decision Record; the proposal is always held for a second approver, never the sender, and is released through the existing release machinery. | Built and deployed | built and deployed 22 Oct 2026 (commit dcb7d2a8a6); one recipient per proposal; the recipient class is recorded in the signed record, behind a flag that is off by default; a person still approves; the record shows which login or key was used, not who wrote the text; built and reviewed by AI agents; no person has audited it | |
| CSN-04 | Version 2 of the consignment checker folds the invoice member into the single offline check, alongside the Provenance and Email Decision Record members; it is served for download at mysovereignty.digital/downloads/consignment-verifier-v2.js and agenticgovernance.digital/downloads/consignment-verifier-v2.js, SHA-256 1ffb7fa4d51ea61af3cd02ce3e6c82dc9b5b57ce5892dcd8f962f852697597c5. | Built and deployed | built, tested and deployed 22 Oct 2026, with the download checked independently; the HTTP routes POST /api/consignments and POST /api/consignments/send take an optional invoice_id and then produce a three-member version 2 file, checked by consignment-verifier-v2.js (live since 12:50 NZDT 22 Oct 2026, commit 29d321e1e0); the invoice must carry a lot reference the lot has offered; every refusal is uniform; switched on per Village on request; a version 1 file is checked exactly as before; without a pinned key the invoice reads key_not_pinned, never verified; the invoice member has no day root or outside time stamp of its own; Attested Accounts day roots are not built, so invoices are not in the estate root; built and reviewed by AI agents; no person has audited it |