Shared Data and Evidence Layer¶

Every ministry holds data that others need. A registry knows who owns a company, a licensing authority knows whether a license is active, and a tax office knows what has been paid. Today that data moves between departments as files, emails, and one-off connections, each in its own format. When a decision built on it is disputed, the answer depends on whose log is believed, and that log usually belongs to one of the parties. Governments increasingly recognize digital records as legally significant evidence, provided that identification, traceability, data protection, and cybersecurity requirements are met, but few have a common way to produce that evidence.

Our view is that the data a state already holds should be usable by every department with a lawful need for it, and that each use should leave proof. We call this collect once, share with proof: the once-only principle that e-government programs aim for, with evidence built in. Sign DataHub is built for this. Each department keeps its own systems and records. Records are described by common, versioned schemas that the national digital authority sets, and other departments receive them through the DataHub under sharing rules that the national digital authority sets and the source department approves (Figure 2). Every exchange is recorded as evidence of who asked, for what purpose, under which authority, what was released, and when. Sign AI reads government data only through the DataHub, under the same checks (Sovereign AI Infrastructure).

Collect Once, Share with Proof¶

A source joins through an approved connector, or through the government’s existing interoperability route where one exists, and the connector checks the source’s identity, permitted fields, schema, and signature. The source department approves which record types each consumer may receive. Each request states a purpose, and access is checked by institution, role, case, and field, so a role grants a function and the context limits which records it reaches. The request, the response, and the delivery each produce an exchange receipt. If a source is unavailable, the request waits in a queue and is shown as pending, and it is never answered from a substitute source that lacks the same legal authority. The DataHub relays released records to authorized consumers but does not keep documents or record contents, which stay in the source systems; its evidence metadata is pseudonymized and protected as personal data. What it keeps is the signed evidence, references that point to each record in its source system, the versions of the sharing rules applied, and each record’s lifecycle history.

An authority can also publish a fact proactively. A release is a minimal signed statement, such as the current status of a license, sent to named recipients such as banks or to an independent oracle network that feeds smart contracts (From Verified Facts to Contract Actions). Each release has an audience and an expiry, and once it expires or is withdrawn, it no longer supports automated decisions.

A department connects in one of two modes. In audit-trail mode, its own system checks authorization and the DataHub records each step and its result as evidence. In pre-execution mode, an agreed action, such as a payment or a token issuance, goes ahead only after the required DataHub evidence has been verified.

How Evidence Works¶

Each department signs its records before they leave its system, and the DataHub checks every record against the approved schema for its type, which defines who may act, under which authority, and how long the evidence is kept. What it records about each exchange is a fingerprint, combined with a secret random value so that a record with predictable content cannot be guessed from it. A correction is a new signed record that points to the one it corrects, so the current view changes while the history stays traceable, and the DataHub is designed to send each correction or withdrawal to every department that received the record.

The DataHub anchors these fingerprints on a ledger network, so any later change to them can be detected. It is designed to record each anchor as a Sign Protocol attestation (Sign Protocol: Attestation Architecture), which carries only a fingerprint or a batch root, so evidence is checked with the same tools that already verify credentials and licenses. Records that must stand on their own, such as a license issued or revoked, are anchored one at a time, and high-volume records, such as routine data exchanges, are anchored in batches. Either way, the result is a receipt that a person can read and software can verify, even offline: it shows who signed the record, that the record has not changed, and that it was anchored. Before relying on a fact today, a verifier also checks online that it is still current. Signing a decision, signing its evidence, and anchoring it use separate keys held by separate parties.

The government chooses the anchoring network. Our default is a private network run by approved public and regulated institutions, and a public blockchain is an option once every field it would expose has been reviewed. Changes to the network’s membership, keys, and schemas are recorded as evidence too. Because evidence must outlast any one ledger platform, the DataHub is designed to move between networks without losing its proofs, and its operation is designed to be handed over to the state.

Uses and Direction¶

Any process that produces legally significant records can use the same DataHub: credential lifecycle events from the identity layer, business and regulatory licenses with a public status register, permits and inspections, investment approvals and milestones, data exchanged between agencies, and the issuance, transfer restriction, redemption, and burn of tokenized real-world assets (Real-World Asset Tokenization). For regulators, it is where licensing decisions and supervisory actions become evidence that courts and auditors can check (Real-Time Supervision).

Our direction is to run the DataHub as a shared public good: one layer through which every ministry shares data and records evidence under its own authority and the common schemas, so that data from different agencies can be combined and its use checked the same way. Over time, the design is built to extend to cross-border verification, in which a court or agency in one state checks a receipt issued in another against that state’s published keys and the fingerprints it has anchored, much as verifiable credentials are recognized across borders through shared standards.