Integration and Deployment¶

A government should be able to show that it holds its own keys, that its data stays under its own law, that significant actions leave evidence it can verify, and that it can leave a supplier without losing its records. It should also be able to start quickly, adopt the infrastructure in stages, and accept each stage on evidence it checks itself. The methods and controls below are our reference design for meeting them.

Integration with National Systems¶

The national systems that already hold legal authority, such as the identity register, the central bank ledger, and the land registry, remain the authoritative sources. We connect to them through standard APIs and issue credentials and evidence from their records. Data migration tools and hybrid deployment let an agency run existing and new systems side by side and modernize at its own pace without interrupting services. Many countries already run open-source DPI building blocks, such as MOSIP for foundational identity, X-Road for government data exchange, and Mojaloop for interoperable instant payments. The SIGN Stack is designed to work with them rather than replace them: the DataHub can use an existing data exchange as its connector, Sign ID can issue credentials from an existing identity register, and payments can settle into an existing instant payment scheme. The stack adds sovereign digital money, ledger-verifiable evidence, and governed AI, with the identity and data layers where a country does not yet have them, all under common controls, with each institution holding its own keys. We support integrators with documentation, defined customization points, and 24/7 on-call technical support. Table 4 lists the typical integrations for the DataHub, each building block, and asset tokenization.

Table 4: Typical integration points

Deployment Timeline¶

The core of each building block is built; integrations, national workflows, and the capabilities we describe as designed are delivered for each program. A standard deployment without customization, meaning the core software on prepared hardware and without registry integration, can be running within about one month, most of which goes to preparing hardware and network connections; the software itself installs in days. Integration with national registries and payment systems, custom workflows, and the hardware for in-country AI add time, which the initial assessment sets for each program. A national program also needs any legislation it depends on, procurement, and the staged pilot described below, which take longer.

Adopting in Stages¶

Each program moves from an assessment of existing systems to a prototype built with frontline users on public sources and synthetic data, then to a pilot with fixed scope, duration, and acceptance criteria, and grows service by service once accepted. Functional, integration, security, performance, resilience, and operational criteria are agreed before each stage. Results come from a frozen release with raw evidence and a record of defects and retests, and the government signs acceptance before the next stage starts. A pilot ends with an explicit decision to scale or stop. In operation, each service is measured against indicators the government approves, such as review time from valid submission to decision and the share of applications returned for correction.

Keys and System Security¶

Whoever holds the signing keys controls the system, so keys stay with the institutions accountable for them. Keys are held in Hardware Security Modules or, for anonymous-credential secrets, hardware-backed secure enclaves (Wallets, Custody, and Key Management), and are created and rotated through recorded key ceremonies. Each institution operates its own key-management domain under a tiered PKI with an offline root, and revocation status is checked on every connection. Smart contracts and protocol components are independently audited before deployment. Restricted DataHub evidence, operating logs, backups, and keys stay in approved in-country hosting, divided into separate zones for public access, application services, restricted data, and the service that submits fingerprints for anchoring. Every administrative session is recorded.

Privacy and Data Control¶

Ledgers hold no documents or record contents, which stay with the institutions responsible for them. They hold commitments, hashes, signatures, anonymous representations, and references, together with whatever a public-path program deliberately makes transparent. Because these can still relate to a person, they are protected as personal data, with retention periods the government sets. Access is limited by role, purpose, and legal authority, linking a record to a person requires a governed process, and a missing authorization, unavailable policy check, or invalid proof blocks the operation. The government owns its records, decisions, and audit history, which stay in the country unless it approves another location. Every external service, from payment providers to blockchain analytics and AI models, is entered in a processing register before it is enabled, stating what data it receives and why, who processes it and where, and how long it is kept. Supplier staff act only on authorized tasks, with access that is limited in scope and time, logged, and revoked when the task ends. Records, decisions, and audit history can be exported in open formats with an integrity manifest, a list of file fingerprints that shows whether anything was altered. Our view is that a government should test this exit path before it needs it, for example by running and verifying a full export as part of acceptance.

Oversight and Redress¶

The platform supports the audit rights the law gives: the data protection authority, the national audit office, and any other body the law names receive read-only audit access across every building block, and new data-sharing rules can be held for the data protection authority’s review before they take effect. The purposes for which records may be shared come from a closed list tied to the law, and the DataHub has no access path for law enforcement other than the one the law provides. Each resident can see who accessed their records, when, and for which purpose, and one complaint and correction channel serves every service on the stack. The operator publishes regular statistics on access requests, refusals, complaints, and corrections. When an automated step on the stack goes against a person, whether an AI flag, a rule refusal, a freeze, a recall, or a revoked credential, the platform is designed to send them a notice that names the reason and the rule version applied, with a route to review by a person and to appeal. No right or benefit depends on holding Sign ID or a digital wallet: a staffed route that does not require digital tools stays open for every service.

AI Safety Controls¶

The AI principles of Sovereign AI Infrastructure apply across the stack. In addition, text that citizens or applicants submit is treated as data, never as instructions, so it cannot change access rights or permissions, and the government can suspend any AI function while standard workflows remain available.

Ownership and Financing¶

We contract through entities in several major jurisdictions, and we are ready to register locally or form a joint venture where a government prefers a domestic counterpart. We deliver under the contract models that governments already use for infrastructure. They differ in who finances the system, who builds and runs it, and when it passes to the government (Table 5).

Table 5: Delivery and financing models

DBFOM, DBFO, and BOT are themselves forms of public-private partnership. The PPP row describes the continuing form, a long-term partnership in which we share the investment with the government. We also license the platform for deployment, support, and updates, which development partners may co-finance. In every model, the controls over records, keys, and exit above apply in full.

The stack combines open-source components with code we build. The open-source components are published under permissive licences that let any party use, modify, and run them, and we use each one within the terms of its licence. In our usual arrangement, we keep ownership of the platform and of general improvements, so that every government benefits from them, and each government owns its own configuration and data; other arrangements can be agreed. The code we build is licensed to the government as Knowledge Transfer and Handover describes.

Knowledge Transfer and Handover¶

Many government systems leave the state relying on one vendor for every change. Ours are built to be handed over, so that national teams can run them. From the first day, the government’s engineers work in joint teams with ours on design, integration, and operation, and we train them on every component they will run. Operation then moves to them in stages: first they work alongside our operators, then they run the system while we support them, until they run it on their own.

We can share the source code of the components we build with the government from the first day, under a licence that lets it use, modify, and extend the code as it wishes within government. The licence has two limits: the code may not be resold or published. It is perpetual and irrevocable, carries no fee after handover, and survives the end of any service contract. It also covers the contractors and successor operators who act for the government, under confidentiality, and the auditors and security testers it appoints; for voting, the electoral authority and independent evaluators may inspect the code. Our preferred model ends in a full handover: when the project is complete, the government receives the full source code, and with it the configurations, evidence archives, documentation, runbooks (step-by-step operating procedures), and operational control. Other models remain available: a government can keep us as operator under a service contract, or license the platform with updates and support.

In every model, the government holds governance and audit rights from the start and receives current documentation and a tested export during operation. Where it chooses handover, the transfer is planned as part of delivery, rehearsed before launch and reviewed every year, and it is complete only when the system has been rebuilt from the transferred materials and a witnessed change of operator has succeeded. The government can then run the system itself, keep us as operator, or appoint another qualified one. After handover, it can still buy from us what it does not want to build itself: certified releases and security patches that track the open-source projects underneath, new modules, conformance testing, and support.

A Shared National Utility¶

Our direction is for a country to run its sovereign infrastructure as a shared national utility. Identity and trust services, the ledger networks, the public services platform, the AI control layer, and the DataHub that joins them would be operated once under common security controls, with each institution holding its own keys and the central bank alone holding the keys of its currency ledger, and each agency would connect to them instead of commissioning its own stack. A new service would start with verified identity, signed evidence, and the government’s data-control rules in place, and records issued by one agency could be verified by every other. Technical governance would accept each release on evidence before it reaches production, operational governance would handle incidents and supplier access, and policy governance would decide which services run on the infrastructure and which agencies may access which records. In a shared utility, our view is that policy governance should sit with a body in which the participating agencies are represented. A country can begin with one agency’s pilot under any of the models above and widen use as other agencies join.