Public source code proves exactly one thing: that the code can be read. It does not prove that the code you read is the code that ran, in the environment it ran in, with the update history it accumulated. That distinction is the whole drafting question for anyone writing a transparency mandate for high-risk AI systems, and Estonia’s ivxv i-voting repository states it more plainly than any policy paper. Its README says the repository “is not used for active development, but will be kept up to date, so the code that can be found here is the code that is used for election.” That sentence is both a transparency commitment and an admission: the equivalence between repository and production rests on the maintainers’ word. No build log, signed attestation, or independent audit establishing that linkage appears in the repository’s own description.
As regulators and procurement teams draft AI transparency obligations modeled on the EU AI Act, Estonia offers a long-running real-world example of a code-publication regime attached to a legally binding national system, with the i-voting system in use since 2005 per the analysis cited below. What it actually demonstrates about verification is narrower, and more instructive, than either its admirers or its critics tend to say.
What the README actually claims
Two sentences in the ivxv repository README do the work. The first is the equivalence claim quoted above. The second explains who stands behind it: “As the voting system used for legally binding elections must strictly follow the legislation, the actual development of Estonian I-voting system and I-vote verification application is supervised by State Electoral Office of Estonia.”
Read as a disclosure regime, this is a code dump plus a self-attestation, wrapped in institutional supervision. The supervision is real and it matters: a named public body oversees development, and elections conducted under it carry legal weight. But supervision is a process claim, not a checkable artifact. An outside reviewer who clones the repository cannot, from anything in the repository itself, confirm that the bytes on disk match the bytes that executed during any given election. The README does not claim otherwise, to its credit. It says the repo “will be kept up to date,” a promise about maintainer behavior, not a mechanism a third party can test.
There is also a nuance worth preserving: the README says the repository is not the development venue. That means the public repo is a downstream mirror of work done elsewhere. No CI records or attestation tooling appear in the repository description; that does not prove none exists in the maintenance process behind it. A mandate drafter should notice the asymmetry though. When the public artifact is a mirror, the chain from “code written” to “code published” to “code executed” has at least two hops, and only the first is observable.
What public code proves: reviewability
The strongest case for publishing source is empirical, and it comes from hostile review of this very system. Estonian Voting Verification Mechanism Revisited, by Koksalmus, Kiraz, Cenk and Sertkaya, summarizes an earlier independent analysis of that system. In a CCS 2014 study the revisited paper cites as reference [20], the authors write that Springall et al. “reported that the system is plagued by serious procedural and architectural weaknesses enabling client-side attacks that skew the results of the election undetectably bypassing the ID card system and smart device verification mechanism.” The same summary adds that “it is claimed that there are several inadequate procedural controls, lax operational security, insufficient transparency and several vulnerabilities in the published code.” Note the reporting chain: the revisited paper passes along Springall et al.’s findings secondhand, and the CCS 2014 analysis itself is not among the documents linked here. These are reported findings about the 2013-2015-era system; whether they hold against the current ivxv code is not established by the sources cited here. Treat them as the adversarial record of a specific period, not a verdict on the present deployment.
That record still proves something durable about publication itself. Because the code was public, outside researchers could read it, find weaknesses, and publish specific, contestable claims. The same paper notes the verification mechanism was first tested in the 2013 local elections and used in the 2014 European Parliament and 2015 parliamentary elections, so this was not a toy system receiving academic attention after the fact. Public code invited scrutiny of a running national system, and the scrutiny produced findings the maintainers had to answer.
There is even a publishability gradient inside the system worth noting for drafters. Per the same analysis, the vote-verification app (VerifApp) could be freely developed by NEC, an open-source community, or individuals, while the voting client (VoterApp) was developed only by NEC. One component was open to independent reimplementation; the other was not. “We published the code” can conceal exactly this kind of asymmetry, where the auditable surface and the trusted surface are different components.
So the first line of the ledger is genuine: publication converts trust into reviewability. Anyone with sufficient skill and time can check the logic.
What public code cannot prove
Reviewability is where the evidentiary value ends. Three properties of a deployed system escape any repository, however carefully maintained:
Build provenance. Even if the repository is exactly the election code, nothing in the source establishes that the deployed binaries were built from it, by a reproducible process, without modification. A mirror repository that is “kept up to date” has a provenance gap by construction: the development happens elsewhere, and the sync step is a human or pipeline operation no reviewer can observe from the outside.
Runtime environment and configuration. Elections and AI services alike run on servers with configurations, dependencies, keys and operational procedures that source code does not capture. The critique, as the revisited paper summarizes it, leaned heavily on operational security and procedural controls, which are precisely the properties a code dump cannot express. Reading the code tells you what the software would do if built and run as intended. It says nothing about whether it was.
Update path. Systems change. A repository snapshot, even a continuously updated one, does not record what version was live on which date, what changed between deployments, or whether a hotfix ever ran in production before it appeared in the public mirror. For a mandate aimed at accountability after an incident, the update history is often the entire question.
This is the ceiling Estonia’s example marks out, and it is not a criticism of Estonia. It is a property of the instrument. Code publication is a transparency floor, not a verification mechanism.
The gap is structural, and current AI governance sits inside it
If this were only a voting-system curiosity, it would not matter much to AI rule writers. It matters because current AI governance practice reproduces the same shape. A recent analysis of deployment assurance, Operational AI Deployment Assurance, puts it directly: “existing governance approaches remain heavily oriented toward documentation, reporting, monitoring, and compliance-centered oversight rather than operational deployment assurance.” The paper argues that the mechanisms for governing deployment-state transitions, the moments when a system actually changes in production, are thin.
That diagnosis matches what a code-only mandate would produce. A provider publishes source, or model documentation, or a system card. Reviewers may examine it. But the obligation is satisfied by the artifact’s existence, and the artifact does not bind the deployment. The verification burden moves wholesale onto external reviewers, who must fund and staff the effort of reconstructing what the provider already knows, with no cryptographic handle connecting the published material to production. Compliance theater is the rational response to a mandate that rewards artifact production over checkable linkage.
One more caution from the assurance literature belongs here. The CAVA framework for runtime governance of agentic systems, in arXiv:2607.13716, warns that observe-mode monitoring evidence “should not be described as equivalent to inline blocking.” The point transfers: a mandate that counts publication and monitoring as if they were enforcement is making the same category error. Observing is not constraining, and disclosing is not verifying.
Mapping the gap to EU AI Act duties
The EU AI Act already contains the hooks a stronger mandate could attach to; the Article citations that follow come from secondary legal analyses rather than the regulation’s own text, so treat them as scholarly readings, not legal advice. The interesting finding is that the Act’s checkable obligations are mostly not about publishing anything.
Technical documentation is broader than code. Per arXiv:2501.12962, Article 11(1) together with Annex IV(2)(g) requires that a high-risk system’s technical documentation include “information about the validation and testing data used and their main characteristics; metrics used to measure accuracy, robustness and compliance” with the relevant Chapter III requirements. Source code discharges none of that. A mandate that treats source publication as the centerpiece of transparency leaves the data and evaluation record, often the decisive evidence in a dispute about model behavior, entirely outside the checkable perimeter.
Article 12 is a capability obligation, not a paper obligation. The analysis in arXiv:2609.13535 is precise on this: “the primary obligations concern the design and operation of logging capabilities rather than the production of specific artifacts: high-risk AI systems shall technically allow for automatic recording, and logging capabilities shall enable the recording of relevant events.” The same reading ties logging scope to Article 9’s risk framework: logs must support identifying situations that may present a risk. And Article 9 obliges providers to identify all known and foreseeable risks, which means any fixed checklist of risk sources is a floor, not a safe harbor. For a drafter, this is the statutory template for deployment and update logging: the system must be built so that what happened can be reconstructed, rather than trusting someone to write down what happened afterward.
Provider duties span the system’s life. As summarized in a healthcare-case analysis of the Act, arXiv:2607.05402, a high-risk provider must carry out conformity assessment before market placement, conduct bias and fairness testing, document data and design choices, maintain human oversight, and run post-market monitoring “to track system performance and risks over time.” Publication is not on that list as a standalone duty. The Act’s architecture assumes ongoing obligations across a deployment lifecycle, which is exactly the span a code dump cannot cover.
What would make disclosure checkable
The tooling to close the provenance gap is not speculative. As arXiv:2607.13716 notes, “software supply-chain systems such as in-toto and Sigstore provide signed provenance and attestation patterns for build and release workflows.” Signed build provenance binds a released artifact to specific source, specific build steps and specific signers. If a mandate required that linkage, the ivxv README’s sentence would stop being a promise and become a verifiable claim: here is the repository, here is the signed attestation that the deployed artifact was built from this commit, here is the transparency log recording it.
The same paper describes an external-assurance pattern worth lifting directly into mandate language: “export selected proof bundles and attestations for buyer, auditor, or partner review.” This flips the economics of verification. Instead of every external reviewer independently reconstructing the provider’s pipeline, the provider exports a proof bundle an auditor can check mechanically. The burden of producing checkable evidence sits with the party that controls the pipeline, which is where it belongs, because that party is the only one who can produce it cheaply.
Three components, then, turn publication into something checkable: signed build provenance anchoring artifacts to source, automatic deployment and update logging in the line of Article 12’s capability obligation, and auditor-exportable attestation bundles. None replaces code publication; they complete it. Published source remains the substrate reviewers read when an attestation fails or a dispute opens.
A mandate-drafting checklist
The practical unit is the property you want to establish, mapped to the artifact that can actually establish it. Code publication fills exactly one row.
| Property a mandate might demand | Published source alone | Checkable artifact to require | AI Act anchor (analogical) |
|---|---|---|---|
| Reviewability of system logic | Yes | Public repository with versioned history | Supports Annex IV documentation duties |
| Data and evaluation record | No | Validation/testing data characteristics, accuracy and robustness metrics | Article 11(1) with Annex IV(2)(g) |
| Build provenance (source to artifact) | No | Signed attestations (in-toto/Sigstore-style) binding builds to commits | Complements Article 11 technical documentation |
| What ran, when (deployment and update history) | No | Automatic event recording built into the system | Article 12 logging capability |
| Risk-relevant incident reconstruction | No | Logs sufficient to identify risk situations | Article 12.2 tied to Article 9 risk management |
| Ongoing conformity after deployment | No | Post-market monitoring reports tied to logged evidence | Post-market monitoring duties |
| Auditability without insider access | Partially | Exported proof bundles for auditor review | External assurance pattern (attestation practice, not a codified duty in the articles reviewed) |
One condition on every row: the artifact must be checkable by someone who does not trust the provider. A log the provider can edit, or an attestation with no transparency log behind it, recreates the README problem one layer down.
The limits of the Estonian analogy
Honesty about this argument requires three concessions.
First, the repository-to-election equivalence is the maintainers’ assertion. No independent audit, build log or State Electoral Office document confirming it appears in the repository description, and this article neither confirms nor disputes it. The README is evidence of what a code-only regime looks like, not evidence that Estonia’s deployed system diverges from its repository.
Second, the Springall et al. findings arrive secondhand, summarized by the revisited paper rather than quoted from the CCS 2014 analysis itself. They demonstrate that hostile review of published code is possible and productive. They do not establish anything about the ivxv code as it stands in 2026.
Third, i-voting is not an AI system, and the EU AI Act citations here come from secondary legal analyses rather than the regulation’s text. The mapping from election-code publication to high-risk AI documentation duties is an analogy. I would call it a strong one, because the verification logic is identical: in both cases the question is whether a disclosed artifact binds a deployed system. But drafters should not cite Estonia as legal precedent for AI Act interpretation, and nothing here is legal advice.
The verdict
Mandate the attestation chain, not the code dump. Source publication is worth requiring: Estonia’s record shows it enables independent scrutiny that closed systems never receive, and the scrutiny found real problems. But publication establishes reviewability and nothing more, and an ivxv-style “this is the code that runs” sentence remains a self-attestation until signed build provenance, automatic deployment logging and auditor-exportable proof bundles make it checkable. A mandate that stops at publication shifts the entire verification cost onto external reviewers, proves nothing about what executed, and pays providers for artifact production rather than verifiable linkage. If you are drafting transparency obligations for high-risk systems, the question to write into the text is not “did you publish the code” but “show us the chain from repository to production, and make it something we can check without trusting you.” Anything less is the README.
Join the discussion
Share a useful perspective or ask a question about this article.