Architecture constitution
The non-negotiable principles: identity separation, minimised trust, cryptographic evidence, determinism, protected retention, independent verification.
In one paragraph
Almost every step in handling a mail ballot is already written down. The trouble is that those notes are ordinary records — a person with the right access can change one afterward, and from outside the building nobody can tell. BB2G is the standard for building records that cannot be quietly changed, that reveal the exact place where someone tried, and that a stranger can verify without asking us for anything.
What it is
Five documents in one
It is not a product and not a page every user reads. It is the shared spine from which product specifications, repositories, deployment controls, evidence packages and public claims derive.
Security baseline
Which controls are mandatory before any component may be described as BB2G-grade.
Audit roadmap
Exactly which artifacts an assessor should ask for — manifests, key-ceremony records, build provenance, Merkle roots, retention records, threat models.
Integration contract
So separate projects interoperate without inventing incompatible notions of events, hashes, receipts, manifests, anchors and proofs.
Claims discipline
No document, page, deck or film may claim “immutable”, “zero-trust”, “verifiable” or “HSM-backed” unless the deployment can produce the evidence.
It was never really about the paper.
It was about the notes we keep about the paper.
The Envelope · 1:31
The architecture
Seven principles
Every component honours these, or states in its conformance record exactly why one does not apply. A blank is a finding, not an omission.
Domains that must not be joined are joined by no interface, schema, key or identifier. The separation is structural, so it survives a compromised operator and a badly aimed subpoena. In elections it is absolute: a token binds to an envelope — never to a voter, never to a selection.
As few parties as the function allows, trusted for as little as possible. Credentials stored as digests, never values. Private keys non-extractable and never persisted. Dual control wherever one actor could otherwise finalise something irreversible.
Anything asserted to have happened is a signed, canonically serialised event in an append-only hash-chained log. Canonicalisation before signing, always — so two honest implementations produce the same bytes.
Same inputs, same outputs, same hashes, same proofs — on any conforming implementation, any machine, any time. Without it, “verifiable” is decoration.
Held as long as law and contract require, in a form where alteration, deletion and reordering are detectable, then destroyed on schedule. Retention is a control, not an accident of storage.
A third party with the exported records and a public key — and no access to the running system — can verify the chain, the checkpoint and an inclusion proof. If it needs our cooperation, it is not verifiable; it is audited by its own author.
No public statement outruns the evidence. Every external claim maps to an artifact producible on demand. What is not yet true is published as an open gate.
The baseline
Fifteen mandatory controls
Nothing may be described as BB2G-grade until every applicable control is implemented and its evidence artifact exists. A perfect integrity core behind an unreviewed marketing page has failed this standard.
| Control | Evidence artifact |
|---|---|
| C-1 · Canonical serialisation before signing | Canonicalisation spec, cross-implementation byte-equality test |
| C-2 · Append-only hash-chained log | Verification result naming the first broken sequence position |
| C-3 · Signed Merkle checkpoints | Signed checkpoints with domain-separated root construction |
| C-4 · Standalone inclusion proofs | Proof verifiable against a root, with no tree and no server |
| C-5 · Digest-only credential storage | Schema with no field capable of holding a raw credential |
| C-6 · Non-extractable signing keys | Key-ceremony record; key manager or HSM attestation |
| C-7 · Dual control on irreversible steps | Transition table and per-transition attestations |
| C-8 · Structural domain separation | Data-boundary table; schema review showing no joinable field |
| C-9 · Reproducible builds, signed releases | Build provenance attestation, SBOM, release signature |
| C-10 · Least-privilege deploy credentials | Token scope inventory and rotation record |
| C-11 · Environment separation | Named environments with distinct credentials and data |
| C-12 · Retention and destruction schedule | Retention policy and destruction log |
| C-13 · Documented threat model | Assets, adversaries, residual risk |
| C-14 · Published limitation list | The component’s own “what this cannot do” |
| C-15 · Pre-publication claim review | Completed checklist with a named approver |
Scope
Where it applies — and where it does not
| Area | Applies | How |
|---|---|---|
| Election Command · Ballot Trail · Provable Custody | Directly | Anonymous eligibility, ballot-event integrity, append-only evidence, verification, audit proofs. |
| ProofCore · StrongRoom · LockChain | Directly | Implement the evidence, retention, anchoring, Merkle-commitment and custody portions. |
| SENTINEL · Cyber Sentinel | Adapted | Trust boundaries, signed event chain, evidence archive, isolation doctrine. No voting or ballot terminology. “Track back, never hack back” remains its own governing constraint. |
| Sovereign Control Tower · Guardian | Adapted | Signed policy decisions, model and input/output provenance, immutable audit trails, least privilege, verifiable configuration state. |
| FOIA Console · Public Record Ledger | Adapted | Custody, public-record integrity, versioning, tamper-evident logs, retention, public verification. |
| Secure Build Lab | Directly | Extends into the supply-chain standard: reproducible builds, signed releases, SBOMs, provenance. |
| General public sites | Partially | Naming, privacy, change control, provenance and secure build only. An informational page needs no Merkle proofs — and must not imply it has them. |
Hierarchy
Doctrine on top, evidence at the bottom
BB2G Integrated Architecture: Master Technical Manifesto
│
├── BB2G Security & Privacy Baseline
├── BB2G Cryptographic Protocol Standard
├── BB2G Evidence and Retention Standard
├── BB2G Secure Build and Deployment Standard
└── Product-Specific Specifications
│
├── BB2G Election Command Specification
├── Ballot Trail / Provable Custody Specification
├── ProofCore / StrongRoom / LockChain Specification
├── SENTINEL Evidence Architecture
├── Guardian Control Tower Architecture
└── FOIA / Public Record Ledger Architecture
│
└── Per-deployment manifests, test evidence,
audit reports, runbooks, key records
The manifesto says which principles every downstream system must honour. The product specification says how that product honours them. The deployment records prove it did.
The film
The Envelope
▶
Three minutes, no jargon, for people who will never read a specification. It explains the whole idea through one envelope: where it goes, who writes down what happened, why those notes can be changed today, and what changes when every step is sealed to the one before it.
Score, sound design and narration, with captions on screen throughout so it still reads muted. Every frame is drawn in code and every sound is synthesised — no stock footage, no photographs, no music library.
Claims discipline
Words we are not allowed to use for free
These are controlled vocabulary across the portfolio. Each may appear publicly only when the corresponding evidence exists and a named approver has signed the review.
| Word | May be used only when |
|---|---|
| Immutable | Records are append-only and hash-chained and alteration is detectable. We prefer tamper-evident, which is what is actually true. |
| Zero-trust | Boundaries are documented, every crossing is authenticated and authorised, no implicit network trust exists. |
| Verifiable | A third party can verify with exported records and a public key alone, without our cooperation. |
| HSM-backed | Production keys live in a hardware security module, with a key-ceremony record. |
| Certified | A named authority issued it and the certificate can be produced. |
| Audited | An independent party completed a review and a report exists. |
| Penetration tested | A test was performed and its report and remediation record exist. |
| In production | It has run in that capacity and the operating party agrees to the description. |
Limits
What this is not
Stating this plainly is a mandatory control, on the same footing as the cryptography.
Not a substitute for specification
Doctrine does not design a product. The product specification still has to be written.
Not proof of security
A system is not secure because it carries the name BB2G.
Not a certification
Not a voting-system certification, a penetration-test report, or an independent audit.
Not a blockchain requirement
Nothing here requires putting data on a public chain.
Not a reason to collect identity
It is never a justification to gather or indefinitely retain sensitive identity data.
Not the end of human trust
It changes what a person must be trusted for — from “trust that they did the right thing” to “trust that doing the wrong thing becomes detectable”. That is a smaller ask, and the only one we are entitled to make.
Open gates — stated on purpose
The mail-ballot lifecycle reference implementation is not certified, not penetration tested, not accessibility evaluated, not SOC 2 attested, not independently security reviewed, and not legally reviewed against any jurisdiction’s election code. It has not been used in a real election. Those are tracked as open release gates R-1 through R-18.
We publish the open gates because a vendor who hides them is telling you something about the ones they have not found yet.
MBLTS is election-supporting technology. It does not capture votes, interpret ballot selections, tabulate, determine official results, or control certified voting equipment. Whether a jurisdiction classifies a system of this type inside its regulated voting system, and what testing that classification requires, is a determination for that jurisdiction.
First principles
Paper decides. People decide.
- The paper ballot is the record of the vote.
- The jurisdiction’s procedure is the record of lawful acceptance.
- The software records that a step occurred and makes alteration of that record detectable. It does not decide whether a ballot counts.
- It replaces no seal, no inventory, no dual control, no trained staff, no observer, no reconciliation and no lawful audit.
- No smartphone, app, camera, email address or internet connection may ever be a condition of voting or of curing a ballot.
- There is no public lookup by token, digest or barcode. There is no receipt and no proof of how anyone voted — permanently, because such a proof is the precondition for vote buying and coercion.
These are not caveats appended to the architecture. They are load-bearing members of it.