1Purpose and scope
The prototype shows the Alatau Sovereign Transaction Proof Ledger as five people would use it: a licensing officer, a ledger operator, a validator administrator, an auditor and a member of the public. It follows the SIGN Foundation proposal of 25 August 2026 and cites the relevant articles of Constitutional Law No. 286-VIII on every operational screen.
This manual explains how to run a demonstration, what each screen shows, which parts of the proposal are interactive, seeded, represented or out of scope, and where the prototype stops. It is written for the SIGN delivery team and for the Alatau City Authority reviewers who will use the prototype during the design phase discussion.
Navigable screens
68
60 working screens across five views plus 8 entry and decision screens
Guided demonstration
10 steps
about 7 minutes, one licence end to end
Coverage rows
59
34 interactive · 4 seeded · 20 represented · 1 out of scope
External dependencies
0
one file, fonts and logo embedded, no network calls
Classification. Everything in the prototype is fictional. No external system is connected. Section 5 lists what is real and what is simulated; section 10 states the boundaries in full.
2Getting started
Opening the prototype
Open the prototype in a current desktop browser. It is one HTML file with no external dependencies and works from a local file, a static web server or the hosted copy. The dashboard has two tabs: Explore by role, with a card for each of the five views and the golden path, and Guided walkthrough, which lists the ten steps and starts the presenter tour.
Saved state and reset
State lives in the viewer’s browser (localStorage). Events you create, votes you cast, ceremonies you run and disputes you act on survive a reload and a deep link. Nothing is transmitted anywhere. Prototype menu → Reset demo returns everything to the seeded starting state; the guided demonstration and the golden path work again immediately after a reset.
Navigation
- Prototype menu (top right in the views; the floating pill on the dashboard) opens the dashboard, the screen gallery, each view, the pilot decision, this manual and the reset.
- Explain this screen (top right in the four signed-in views) opens the assistant dialog. It answers within the current role and case, cites the proposal section, schema or law it relies on, and refuses to sign, finalize, vote, approve or release anything; refusals are labelled.
- Menu (top left, below 860 px) opens the navigation drawer.
- Blue links in tables and cards move between views while keeping the record in focus: from an event to its block, batch, receipt or public status.
- Opening a screen directly signs you into its view. The sign-in and second-factor screens show the security boundary and never block the demonstration.
- Deep links use the form #/view/screen/identifier, for example #/audit/verify/EVT-2026-000391. Every route in this manual is a link into the prototype.
Guided demonstration
The guided demonstration is a presenter layer over the ordinary screens. A bar at the foot of the page shows the step, its narration and Previous, Next and Exit tour. → and ← move between steps. Each step prepares the state it needs, so the demonstration can be started from any point, repeated, or resumed after a reset. Opening the dashboard directly (outside the tour) ends the tour.
Time and clock
Times are shown in Alatau local time (UTC+5). Seeded data is anchored at 31 August 2026, 14:02. The demonstration clock starts there at each reset and advances with real time, so records you create follow the seeded history in one consistent timeline. The private chain is modelled with a 2-second block period; block heights, block times and event finality times agree with each other.
3Walkthroughs
Three scripts for three audiences. Each row is a link into the prototype. Reset the demonstration before a presentation.
Executive walkthrough about 3 minutes
| # | Step | Route | Narration |
|---|---|---|---|
| 1 | Dashboard | launcher | Read the headline and the five roles. The footer states the classification: prototype, fictional data, no external systems. |
| 2 | The proof ledger in one page | overview | The five layers, what the ledger holds, what stays in source systems, the two finality modes and the legal basis. |
| 3 | Public verification | public/result/ALT-BL-2026-0079 | The licence of Zhetysu Payments LLP shows Active, the issuing block, the validator quorum and the payload hash. Names of officers, documents and application content are withheld. |
| 4 | Independent verification | audit/verify/EVT-2026-000391 | Press Run verification. Eight checks run against the chain from Observer 2 and return VALID without contacting the Licensing Service. |
| 5 | Pilot decision | decision | The five launch decisions from proposal §9 and the proposed pilot shape: five domains, four validators, two observers, six sources, two finality modes, a 24-week pilot. |
Standard walkthrough about 7 minutes · the guided demonstration
Open the Guided walkthrough tab on the dashboard and press Start the guided walkthrough, or open tour/1. The ten steps and their narration are generated from the prototype itself.
| # | Step | Screen | Narration |
|---|---|---|---|
| 1 | The proof ledger in one page | overview | Source systems keep documents and personal data. The ledger keeps hashes, signatures, policy references and finality. The next nine steps follow one licence from the licensing desk to the pilot decision. |
| 2 | A licensing officer composes the event | source/compose | Aigerim Nurlanova, licensing officer, composes LIC.license_issued v1.2 for Alatau Nova Digital Assets LLP. The canonical JSON and its SHA-256 are computed in the browser and change with every field. |
| 3 | Documents stay off-chain; fingerprints are created | source/attachments | Three case-file documents are hashed inside the Licensing Service. Only the fingerprints enter the envelope. The files never leave ALT-LIC. |
| 4 | Two different officers sign the same canonical hash | source/cosign | Aigerim Nurlanova has signed the canonical hash. Daniyar Seitkali, a different authorising officer, now countersigns the same hash. The gateway refuses a second signature from the same certificate. Press Countersign, or Next to continue. |
| 5 | The gateway validates and routes the event | ops/gateway | ALT-LIC submitted the envelope over mutual TLS. The gateway re-ran validation, checked both signatures and idempotency, and routed the event to direct finality. The new event is highlighted in the intake table. |
| 6 | Validators provide direct finality | ops/block | Licence issuance is legally critical and low-volume, so it received direct finality: a transaction in this block, signed by four validators, a few seconds after acceptance. |
| 7 | The public portal exposes only approved status facts | public/result | Anyone can check the licence without signing in. The portal shows status facts and the proof reference: no documents, no names of officers or controllers, no application content. |
| 8 | An auditor independently verifies the package | audit/verify | The auditor verifies the package from an observer node without contacting the Licensing Service: schema, hash, certificates, signatures, lifecycle, chain commitment, validator quorum and timestamp. |
| 9 | Direct versus batched finality | ops/router | Critical, low-volume events go straight to the chain. High-volume events such as credential presentations and exchange receipts are batched under a Merkle root committed within 60 seconds. Each batched event carries an inclusion path to that root. |
| 10 | The five launch decisions | decision | The immediate action is to authorize the four-week governance and technical design phase. Five decisions: sponsor, domains, validators, sources, design. |
Technical walkthrough about 15 minutes · the guided demonstration plus the following
| # | Step | Route | Action and expected result |
|---|---|---|---|
| 1 | Batched finality and inclusion proofs | ops/batch/B-2026-08-31-0412 | Open batch B-2026-08-31-0412: 118 leaves, the tree shape and the root committed to the chain. Open leaf EVT-2026-000405 (a credential presentation) and verify it in the auditor workspace; the Merkle path check appears as a ninth step. |
| 2 | Root publication on demand | ops/batches | Open the batch marked Open and press Publish root now. The prototype commits a simulated root in the next block and finalizes every event in the batch. The pilot service does this automatically within 60 seconds. |
| 3 | Tamper detection offline | audit/offline/EVT-2026-000391 | Press Verify offline for VALID. Press Alter one character, then verify again: INVALID, with the failing checks named. Reset the package to restore it. |
| 4 | Inter-agency exchange | source/exchange/new | Submit the request. Three proof events follow: request, provider response fingerprint, consumer acknowledgement. No payload is stored. The three events sit in the open batch until its root is published. |
| 5 | Rejections with the rule quoted back | source/rejected | Three seeded rejections: signature quorum not met, canonicalization failure under RFC 8785, idempotency duplicate. |
| 6 | Validator admission vote | gov/proposal/GOV-2026-0009 | Cast Validator A’s vote. At 3 of 4 the proposal executes into a governance transaction in the next block. The vote persists across a reload. |
| 7 | Certificate rotation ceremony | gov/rotation | Seven witnessed HSM steps for Validator C. The old certificate is revoked only after the new one is active. Completion clears incident INC-2026-0031. |
| 8 | Emergency procedures | gov/emergency | The key-compromise tabletop: emergency quorum, suspension at 3 of 4, containment, rotation, re-admission and post-incident review. State persists across a reload. |
| 9 | Dispute and legal hold | audit/dispute/DSP-2026-0007 | A licensee disputes a revocation. The proof package verifies VALID; the dispute concerns the underlying decision. Request source evidence against the committed hash. |
| 10 | Supersession | source/amend/EVT-2026-000399 | Append-only correction: a new event names and supersedes the prior record once it is countersigned and finalized. The original stays readable and verifiable. |
| 11 | Evidence export | audit/export | Select records and compose a signed manifest that bundles proof packages, block headers and validator certificates. |
| 12 | Reset | launcher | Prototype menu, then Reset demo. Every created event, vote and ceremony returns to the seeded starting state. |
4Views and screens
The tables in this section are generated from the prototype’s screen registry, so titles, routes and counts cannot drift from the build. 68 screens are navigable: 60 working screens across the five views and 8 entry and decision screens. Routes marked /… take an identifier; the link opens the example used in the screen gallery. 5 internal transition routes (second-factor steps, the guided-tour routes and the screen gallery) are listed at the end and are not counted.
Entry and decision 8 screens
| Route | Screen | Purpose |
|---|---|---|
| launcher | Dashboard | Persona dashboard: choose a role, or open the guided walkthrough tab and follow one licence end to end. |
| overview | Overview | One-page overview: the five layers, what the ledger holds, what stays in source systems, the two finality modes and the legal basis. |
| source/signin | Licensing desk sign-in | Officer sign-in with eGov mobile digital signature or security key; two separate officer accounts. |
| source/mfa | Second factor · eGov mobile | Second-factor boundary before any desk access. |
| ops/signin | Operations sign-in | Operator sign-in for the TPL core platform console. |
| gov/signin | Validator secure sign-in | Hardware-key boundary for validator administrators; governance actions require signed proposals and quorum. |
| audit/signin | Auditor sign-in | Auditor sign-in through the observer node; read, verify and export only. |
| decision | Pilot decision | The immediate action and the five decisions that move the ledger into the four-week design phase (proposal §9). |
Licensing desk 19 screens
The Administration’s Licensing Service is the first source system. It keeps the application file, the decision memo and the licence certificate. It sends the ledger an envelope: canonical fields, attachment fingerprints, two signatures and a policy reference. Business licensing rests on Article 39 of Law 286-VIII; Article 51(3) requires the Administration to deliver such services through its digital objects.
Two officer accounts are available: Aigerim Nurlanova (licensing officer, ALT-LIC-OFF-0142) and Daniyar Seitkali (authorising officer, ALT-LIC-AUTH-0031). The officer who signs first cannot countersign; the desk offers an account switch.
| Route | Screen | Purpose |
|---|---|---|
| source/desk | Licensing desk | Queue of licensing events with their proof status; start the golden path from the reviewed application. |
| source/new | New proof event | Choose the governed schema; the schema fixes finality mode, required signatures, retention and confidentiality. |
| source/compose | Compose licence event | Structured fields become canonical JSON; the hash updates live as you type. |
| source/attachments | Attachments & hashes | Documents are hashed locally; only the fingerprints enter the envelope. |
| source/policy | Policy check & required signatures | Gateway pre-checks run before signing: schema, lifecycle, idempotency, signer eligibility. |
| source/sign | Sign · first signature | The officer signs the canonical hash with an Ed25519 certificate via eGov mobile or a security key. |
| source/handoff | Awaiting co-signature · handoff | The same account cannot co-sign; the event waits for the authorising officer. |
| source/cosign | Countersign · second signature | The authorising officer reviews the same hash and signs; quorum 2 of 2 is met. |
| source/submit | Submit to proof gateway | The complete envelope is submitted over mutual TLS with a signed request; the gateway responds with the event ID. |
| source/submitted | Gateway response · finality | Accepted, validated and finalized on the private chain within seconds; the event ID is now citable. |
| source/events | My events | All events submitted by the Licensing Service with filters by status and finality. |
| source/event/… | Event detail | Full envelope: identity, action, integrity, policy, lifecycle, signatures and finality. |
| source/amend/… | Supersede a record | Append-only correction: a new event references and supersedes the prior one; nothing is edited or deleted. |
| source/receipt/… | Proof receipt | Human-readable receipt plus the machine-verifiable proof package for one event. |
| source/receipts | Proof receipts | All finalized events from this desk with downloadable receipts. |
| source/rejected | Rejected submissions | Gateway rejections with the failing rule quoted back; nothing rejected reaches the chain. |
| source/exchange | Inter-agency exchange | Neutral evidence of which systems exchanged which response fingerprint and when. No payload is stored. |
| source/exchange/new | New exchange request | Request fields from a provider under a DSA; the policy engine declines unauthorised fields before the provider sees them. |
| source/messages | Messages | Official messages from the gateway and operations: co-signature requests, schema changes, rejections. |
Ledger operations console 17 screens
The operations console belongs to the city digital-platform operator. It shows the proof gateway, the evidence plane (schemas, finality routing, Merkle batches), the private chain (blocks, validators) and management functions (sources, keys, retention, drills, performance).
Signed in as Yerlan Abenov, ledger operations lead. Figures on the overview and performance screens are illustrative sample values.
| Route | Screen | Purpose |
|---|---|---|
| ops/overview | Operations overview | Live posture against the proposal’s performance targets: ingestion, latency, finality, freshness, availability. |
| ops/gateway | Proof gateway | Authenticated intake: what the gateway checks, what it accepted, what it rejected and why. |
| ops/catalog | Event catalog & schemas | Seven event domains, five in the pilot; every schema fixes finality, signatures, retention and confidentiality. |
| ops/schema/… | Schema definition | The proof event envelope for one schema: field groups, lifecycle states, finality and version history. |
| ops/event/… | Event detail (operations) | Operations view of an event envelope; identical record, different role. |
| ops/router | Finality router | Rules that send legally critical events straight to the chain and high-volume events into Merkle batches. |
| ops/batches | Merkle batches | Open and published batches with leaf counts, roots, chain transactions and freshness against the 60-second target. |
| ops/batch/… | Batch detail · inclusion proofs | One batch: its root, chain commitment and the leaves it proves. |
| ops/chain | Blocks & transactions | The private validator chain: head, recent blocks, proposers, quorum and the transactions each block finalized. |
| ops/block/… | Block detail | One block: hash chain, proposer, validator signatures and the finalized transactions. |
| ops/validators | Validator network | Four validators and two observers: health, height, latency, certificate expiry, HSM custody. |
| ops/sources | Source systems | Accredited systems and service identities: authentication, schema version, delivery, latency, validation rate. |
| ops/incidents | Incidents & alerts | Open and resolved incidents with severity, owner and effect on targets. |
| ops/keys | Keys & certificates | Certificate authority, validator and attester keys, HSM custody, rotation schedule and revocation. |
| ops/retention | Retention & legal hold | Retention classes per domain, legal holds, and two-person deletion with a tamper-evident audit event. |
| ops/drills | Drills & recovery | Backup, restore, validator loss, site failover, key compromise and incident drills with results. |
| ops/performance | Performance | Proposal targets T1 to T7 against measured pilot results. |
Validator governance 9 screens
Validator governance is the console of a validator administrator. Every governance action becomes a signed chain transaction subject to the charter quorum of 3 of 4.
Signed in as Madina Tulegenova, administrator for Validator A (Administration of Alatau). Votes, the rotation ceremony and the emergency procedure change stored state.
| Route | Screen | Purpose |
|---|---|---|
| gov/home | Governance home | Charter, membership, open decisions and the certificate that needs rotating. |
| gov/members | Members and roles | Validator and observer organizations, admission dates, node operators and HSM attestations. |
| gov/proposals | Proposals and votes | All governance proposals with tallies; executed proposals reference their chain transaction. |
| gov/proposal/… | Proposal · vote | Review a proposal, cast Validator A’s vote, and watch quorum turn it into a chain transaction. |
| gov/rotation | Certificate rotation ceremony | HSM key ceremony for Validator C: generate, sign CSR, issue, distribute, activate, revoke old. |
| gov/emergency | Emergency procedures | Tabletop: suspected key compromise at Validator B; emergency quorum, suspension, rotation and re-admission. |
| gov/parameters | Chain parameters | Consensus, block period, validator limits, batch interval and the cryptographic profile, all under governance. |
| gov/log | Governance log | Every governance transaction with its block reference. |
| gov/charter | Network charter | The seven charter sections from proposal §5.2 with approval status. |
Auditor and verifier workspace 11 screens
The auditor workspace verifies records independently from an observer node. It never contacts a source system. It also holds disputes, evidence export and the access log.
Signed in as Saltanat Bekova, auditor at the Alatau Audit and Oversight Office (Observer 2).
| Route | Screen | Purpose |
|---|---|---|
| audit/dashboard | Audit dashboard | Verification activity, finality outcomes, disputes and access: the operational and strategic view for oversight. |
| audit/search | Search proofs | Find events by ID, subject, hash, domain or status; every query is logged with role and purpose. |
| audit/event/… | Event detail (audit) | Auditor view of an event envelope. |
| audit/verify/… | Verify a proof package | Step-by-step independent verification: schema, hash, certificates, signatures, lifecycle, Merkle path, chain, quorum, time. |
| audit/receipt/… | Proof receipt (audit) | Receipt and proof package for one event, from the auditor’s role. |
| audit/offline/… | Offline verifier | Paste a proof package and verify it with no connection to the portal; tamper with a byte to see detection. |
| audit/disputes | Disputes | Open and closed disputes; a dispute marks the lifecycle and applies a legal hold, never alters the record. |
| audit/dispute/… | Dispute case | One dispute: the record, the verification result, the legal hold and the request for source evidence. |
| audit/export | Evidence export | Compose a signed evidence package for a court, regulator or foreign authority. |
| audit/access | Access log | Who queried, verified or exported which record, under which role and purpose. |
| audit/reports | Reports | Operational and strategic reporting: finality timing, volumes by domain, verification outcomes, assurance readiness. |
Public verification 4 screens
The public portal needs no sign-in. It answers one question: is this licence, permit or receipt reference backed by a final record, and what is its status. It returns approved status facts and the proof reference only.
Example references: ALT-BL-2026-0079 (active licence), ALT-BL-2026-0051 (suspended), ALT-BL-2025-0018 (revoked, under dispute), ALT-PRM-2026-0233 (permit), ALT-BL-2026-0087 (active once the guided demonstration or golden path has run).
| Route | Screen | Purpose |
|---|---|---|
| public | Verify a record | Enter a licence, permit or receipt reference, or scan the QR on a receipt, to check status and proof. |
| public/result/… | Verification result | Status facts and proof for one reference: active, suspended, revoked, completed or not found. |
| public/register | Public register | Every licence and permit with a final record, filterable by kind and status. |
| public/how | Inside a proof | Plain-language explanation of a proof, its disclosures, and offline verification. |
Internal transition routes 5 routes, not counted
| Route | Title | Purpose |
|---|---|---|
| gallery | All screens | Every navigable screen, grouped by view. |
| ops/mfa | Second factor · operations | Second-factor step of the operations sign-in (eGov mobile or security key). Internal transition route. |
| gov/mfa | Second factor · governance | Second-factor step of the governance sign-in (eGov mobile or security key). Internal transition route. |
| audit/mfa | Second factor · audit | Second-factor step of the audit sign-in (eGov mobile or security key). Internal transition route. |
| tour | Guided demonstration | Presenter layer over existing screens. |
5Real and simulated elements
Reviewers should rely on this table when judging what the prototype proves.
| Element | In this prototype | Notes |
|---|---|---|
| Canonical JSON and SHA-256 of the event envelope | Real | Computed in the browser with Web Crypto (crypto.subtle) over RFC 8785-style canonical JSON. The hash changes with every field. |
| Attachment fingerprints | Simulated documents, real hashing | The three case-file documents are fictional names and sizes. SHA-256 runs over their descriptors, not over file bytes. |
| Digital signatures, certificates, CA chain, CRL and OCSP | Simulated | Ed25519 signatures and X.509 references are deterministic placeholders. Separation of duties is enforced at account level in the prototype. |
| Validator consensus, blocks and transactions | Simulated | Block heights follow a fixed 2-second schedule from a demonstration clock; validator signatures are placeholders. No node exists. |
| Merkle batches, roots and inclusion paths | Simulated | Tree depth follows the leaf count; sibling hashes and roots are deterministic placeholders. The verifier checks structure and reference values, not cryptographic recomputation. |
| Verification results (VALID, INVALID, NOT FINAL, DISPUTED) | Simulated logic | Checks are evaluated against stored reference values. Any alteration of a package is detected because the stored reference no longer matches. |
| Source systems, mutual TLS, OAuth, eGov mobile, security keys, HSMs | Simulated | No network request leaves the page. Sign-in screens show the boundary and never block the demonstration. |
| Performance and availability figures | Illustrative | Sample values show the shape of proposal §6.3 targets. No load test, availability measurement or recovery drill has been executed. |
| Governance votes, ceremonies, emergency steps, disputes | Simulated state | Stored in the viewer’s browser only. Nothing is shared between viewers. |
| Personal data | None | All people, organizations, licences, permits, hashes and cases are fictional. |
| Legal citations | Real article numbers | Constitutional Law No. 286-VIII of 8 May 2026 as published on Adilet. Delegated regulations are shown as draft placeholders. |
| Demonstration clock | Fixed | Seeded data is anchored at 31 August 2026, 14:02 Alatau time (UTC+5). The clock advances from the moment of reset; records you create are stamped on that timeline. |
6Coverage of the proposal
Each row of the proposal is rated with one of four statuses. Interactive demonstration: the viewer performs the action and the state changes. Seeded example: the records exist in the starting data and can be opened and verified, but the flow that creates them is not included. Represented: the requirement is shown as content (tables, charter text, parameters, targets) without an operable flow. Out of scope: not included. The Where column links to the routes involved; the Note column records limits.
Reading the statuses. An interactive rating means the flow is operable in the prototype. It does not mean the underlying cryptography, consensus or infrastructure exists; section 5 governs that distinction.
Products · proposal §1.1
| ID | Requirement | Where | Status | Note |
|---|---|---|---|---|
| P1 | Proof gateway: authenticated intake, schema validation, canonicalization, hashing, signatures, idempotency, policy checks | source/policy · source/submit · source/submitted · ops/gateway · source/rejected | Interactive demonstration | Checks run on the golden-path event in the browser. Rejection reasons are seeded examples. |
| P2 | Append-only proof store: event history, lifecycle state, indexing, retention, evidence manifests | source/events · source/event · source/amend · ops/retention | Interactive demonstration | Supersession is interactive. Two-person deletion is described, not executed. |
| P3 | Merkle evidence engine: deterministic batching, trees, inclusion proofs, manifests, root submission | ops/batches · ops/batch · audit/verify | Interactive demonstration | Root publication on demand and path verification are interactive; roots and sibling hashes are placeholders. |
| P4 | Private validator chain: permissioned membership, BFT finality, governance transactions, root anchors, critical events | ops/chain · ops/block · ops/validators · gov/proposal | Interactive demonstration | Blocks follow a simulated 2-second schedule; consensus is not executed. |
| P5 | Verification portal and API: search, proof validation, export, offline verification, dashboards, auditor workflows | audit/search · audit/verify · audit/offline · audit/export · public | Interactive demonstration | The API itself is described on the public “Inside a proof” screen only. |
| P6 | Management and operations: validator admission, key rotation, schemas, roles, monitoring, backup, recovery, handover | gov/proposal · gov/rotation · ops/sources · ops/incidents · ops/drills | Interactive demonstration | Admission and rotation are interactive. Monitoring, backup, recovery and handover are represented. |
Proof product system · proposal §3
| ID | Requirement | Where | Status | Note |
|---|---|---|---|---|
| E1 | Envelope · identity and authority | source/event · ops/schema | Interactive demonstration | Populated by the golden-path event. |
| E2 | Envelope · action and subject | source/event · ops/schema | Interactive demonstration | |
| E3 | Envelope · integrity: canonicalization profile, payload hash, attachment hashes, previous-event hash, signatures, trusted timestamp | source/compose · source/attachments · source/sign · source/event | Interactive demonstration | Hashing is real; signatures and timestamps are placeholders. |
| E4 | Envelope · policy: legal reference, schema version, purpose, retention class, confidentiality class, quorum | source/policy · source/event · ops/catalog | Interactive demonstration | Policy names are draft placeholders pending the delegated regulations. |
| E5 | Envelope · lifecycle: received, validated, co-signed, finalized, rejected, superseded, revoked, expired, disputed | source/submitted · source/event · source/amend · source/rejected · audit/dispute | Interactive demonstration | Received to finalized and supersession are interactive; rejected, revoked and disputed are seeded; expired appears in the catalog only. |
| E6 | Envelope · finality: batch, leaf, path, root, chain transaction, block, quorum, finality time | source/submitted · source/event · ops/batch · ops/block | Interactive demonstration | |
| F1 | Direct finality for critical, low-volume events | source/submitted · ops/router · ops/block | Interactive demonstration | The golden-path licence finalizes directly in the next block. |
| F2 | Batched finality with Merkle roots for high-volume events | source/exchange/new · ops/router · ops/batches · ops/batch | Interactive demonstration | Exchange events enter the open batch; Publish root now finalizes them. |
| R1 | Evidence receipt readable by a person and verifiable by software, excluding payloads | source/receipt · audit/receipt · public/result | Interactive demonstration |
Event domains and lifecycle · proposal §4
| ID | Requirement | Where | Status | Note |
|---|---|---|---|---|
| D1 | Resident and credentials: issue, present, verify, revoke, issuer key change | ops/gateway · ops/catalog · ops/batch | Seeded example | Five seeded events with hashed subjects. No wallet or issuer interface is included. |
| D2 | Business and regulatory licences: accepted, reviewed, condition, issued, suspended, revoked, renewed | source/desk · source/compose · public/result | Interactive demonstration | Issue, condition, suspension, revocation and supersession are covered; renewal appears in the catalog only. |
| D3 | VASP supervision: return, incident, wallet bound, alert, remediation, inspection | ops/gateway · ops/catalog | Seeded example | Five seeded events including one idempotency rejection. No supervision interface is included. |
| D4 | Permits and inspections: permit, inspection, corrective action, certificate, closure | ops/gateway · public/register · audit/dispute | Seeded example | Seeded events and one closed dispute. No permits interface is included. |
| D5 | Investor and SEZ: approval, commitment, milestone, benefit eligibility | ops/catalog · ops/sources | Represented | Phase 2. One sandbox event and a sandbox integration. |
| D6 | Inter-agency exchange: request, response hash, acknowledgement, rejection, timeout | source/exchange · source/exchange/new | Interactive demonstration | Request, response fingerprint and acknowledgement are interactive; rejection and timeout are seeded. |
| D7 | Tokenized assets: issuance approval, attestation, mint, restriction, redemption, burn | ops/catalog | Represented | Phase 2. Draft schemas only. |
| L1 to L7 | Transaction lifecycle: submit, authenticate, validate, sign, finalize, commit, verify | source/compose · source/submit · source/submitted · audit/verify | Interactive demonstration | |
| V1 | Independent verification outside the production portal; valid, invalid, revoked, superseded, expired, disputed outcomes | audit/verify · audit/offline | Interactive demonstration | Verification logic is simulated against stored reference values. |
Validator network and governance · proposal §5
| ID | Requirement | Where | Status | Note |
|---|---|---|---|---|
| N1 | Four-validator pilot topology with two observers | ops/validators · gov/members | Represented | Organizations and roles are shown; no node exists. |
| N2 | Expansion to five validators by admission vote | gov/proposal | Interactive demonstration | GOV-2026-0009 executes at 3 of 4. |
| C1 | Charter · admission, suspension, removal, replacement, emergency quorum | gov/proposal · gov/emergency | Interactive demonstration | Admission and emergency suspension are interactive; removal and replacement are represented in the charter. |
| C2 | Charter · node ownership, hosting, maintenance, patching, backup, recovery | ops/validators · ops/incidents · ops/drills | Represented | |
| C3 | Charter · CA, HSM custody, key ceremonies, rotation, revocation, compromise response | ops/keys · gov/rotation · gov/emergency | Interactive demonstration | Ceremony and playbook steps are interactive; no HSM is involved. |
| C4 | Charter · consensus policy, upgrade approval, chain parameters, schema governance, change control | gov/parameters · ops/catalog · gov/log | Represented | Schema adoption GOV-2026-0007 appears as a seeded governance transaction. |
| C5 | Charter · permitted domains, write identities, read roles, export rights, retention, legal hold | ops/sources · ops/retention · audit/export · audit/access | Interactive demonstration | Export is interactive; access enforcement is simulated. |
| C6 | Charter · incident severity, notification, investigation, dispute, evidence, regulator access | ops/incidents · audit/disputes · audit/dispute | Interactive demonstration | The dispute case is interactive; incidents are seeded. |
| C7 | Charter · performance, availability, recovery, audit, annual assurance | ops/performance · audit/reports | Represented | |
| TP | Technology profile · permissioned BFT, certificate-based membership, implementation-portable | gov/parameters | Represented |
Architecture, performance, privacy and security · proposal §6
| ID | Requirement | Where | Status | Note |
|---|---|---|---|---|
| A1 | Layered architecture · source systems, gateway, evidence plane, private chain, verification, operations, infrastructure | overview · ops/overview | Represented | |
| K1a | Cryptographic profile · JCS canonicalization and SHA-256 | source/compose · source/attachments | Interactive demonstration | Real SHA-256 in the browser. |
| K1b | Cryptographic profile · Ed25519, X.509, mutual TLS, HSM/KMS, trusted time, revocation, signed releases | source/sign · ops/keys · gov/parameters | Represented | Placeholders only. |
| T1 to T7 | Performance targets · ingestion, acceptance latency, proof lookup, critical finality, batch freshness, availability, recovery | ops/overview · ops/performance · ops/drills | Represented | Illustrative sample values; no test executed. |
| PC1 | No personal data or business payloads on the private chain | source/attachments · source/event · public/result · public/how | Interactive demonstration | |
| PC2 | Domain separation and salting where dictionary risk exists | ops/catalog | Represented | Hashed subjects appear in seeded credential events. |
| PC3 | Role and purpose controls on queries and exports | audit/search · audit/export · audit/access | Interactive demonstration | Queries and exports are logged with role and basis; enforcement is simulated. |
| PC4 | Retention, legal hold, deletion, evidence preservation by domain policy | ops/retention · audit/dispute | Seeded example | Retention classes and one legal hold are seeded; deletion is described, not executed. |
| PC5 | Public and partner verification expose only approved status facts | public · public/result · public/register · public/how | Interactive demonstration | |
| SC1 | HSM-backed validator and attester keys with formal ceremonies | ops/keys · gov/rotation | Interactive demonstration | Ceremony steps are interactive; no HSM is involved. |
| SC2 | Segmented networks, mutual TLS, RBAC, ABAC, privileged access, session recording | ops/gateway · ops/sources · source/signin | Represented | |
| SC3 | Secure build pipeline, code signing, vulnerability management, independent testing | gov/parameters | Represented | |
| SC4 | Continuous node, consensus, queue, storage and integrity monitoring | ops/overview · ops/validators · ops/incidents | Represented | |
| SC5 | Incident playbooks for key compromise, split network, replay, corruption, data loss | gov/emergency · ops/drills | Interactive demonstration | Key compromise is interactive; the other playbooks are listed in the drill schedule. |
Pilot scope and acceptance · proposal §7
| ID | Requirement | Where | Status | Note |
|---|---|---|---|---|
| S1 | Five event domains, four validators, two observers, up to six source systems, two finality modes | decision · ops/catalog · ops/validators · ops/sources · ops/router | Represented | |
| M1 | End-to-end proof · valid events, signatures, lifecycle, finality, independent verification per domain | source/desk · source/submitted · audit/verify | Interactive demonstration | Interactive for licensing and exchange; seeded for the other domains. |
| M2 | Validator governance · admission, rotation, node replacement, quorum change, emergency suspension | gov/proposal · gov/rotation · gov/emergency | Interactive demonstration | Node replacement and quorum change are represented in the charter. |
| M3 | Privacy · payloads and personal data outside the chain; public verification returns only approved facts | source/attachments · public/result · public/how | Interactive demonstration | |
| M4 | Performance · ingestion, lookup, finality, freshness, availability at the agreed load profile | ops/performance | Represented | No measurement exists. |
| M5 | Evidence export · offline verifier validates hash, signatures, Merkle path, root, block, quorum | audit/offline · audit/export | Interactive demonstration | Simulated verification logic; tampering is detected. |
| M6 | Operational readiness · backup, restore, validator loss, failover, key compromise, incident runbooks | ops/drills · gov/emergency | Represented | Drills are scheduled, not executed. |
Legal and operating context · proposal §2 and Law 286-VIII; commercial terms · §8
| ID | Requirement | Where | Status | Note |
|---|---|---|---|---|
| LG1 | Digital records as a legally significant form and as evidence, subject to reliability, identification, traceability, data protection and cybersecurity (Art. 53(1) to (3)) | public/how · audit/verify | Represented | Cited in the Basis and source row of each screen. |
| LG2 | Sovereign position: private permissioned chain, restricted validators, accredited writers, role-based readers; services through Administration digital objects (Art. 51(3), Art. 52) with cybersecurity on integration (Art. 51(4)) | ops/validators · ops/sources · gov/members · audit/access | Represented | Access control is simulated. |
| LG3 | Timing: Art. 51(1) and (2) and Art. 54 from 1 July 2026; Arts. 38 to 41 and 47 from 1 January 2027; Arts. 12, 52 and 53 from 1 July 2027 (Art. 90) | public/how · overview | Represented | The demonstration clock (31 August 2026) runs ahead of the legal effect of digital records. |
| CM | Commercial options, milestones, partnership economics and safeguards | none | Out of scope |
7Legal basis and citations
Operational screens carry a Basis and source row that cites the proposal section and, where relevant, an article of the Constitutional Law of the Republic of Kazakhstan No. 286-VIII of 8 May 2026 “On the special legal regime of the city of Alatau”. Article numbers were checked against the official text on Adilet (Z2600000286).
| Article | Subject | Used on |
|---|---|---|
| Art. 53(1) to (3) | Digital records as a legally significant form of certifying rights, obligations and legal facts, and as evidence, where reliability, identification, traceability, data protection and cybersecurity are ensured | Every signed-in screen; verification and public screens |
| Art. 53(4) | Requirements for digital records set by the Administration | Placeholder policies; not yet published |
| Art. 52 | Digital objects and digital data | Sources, catalog, public portal |
| Art. 51(3) to (6) | Services through the Administration’s digital objects; cybersecurity on integration; recognised electronic signatures | Sign-in screens, sources, keys |
| Art. 12 | Digital primacy; the unified city digital platform; data protection and access rules; repository of acts | Retention, access log |
| Art. 38, 39, 41 | Residency, business licensing, regulatory licences and permits | Licensing desk, catalog, public register |
| Art. 47 | Digital assets | Tokenized-asset draft schemas (phase 2) |
| Art. 54 | Experimental legal regimes | Pilot framing |
| Art. 90 | Entry into force | Public “Inside a proof”, guided demonstration |
Timing and placeholders. Articles 51(1) and (2) and 54 apply from 1 July 2026; Articles 38 to 41 and 47 from 1 January 2027; Articles 12, 52 and 53 from 1 July 2027 (Art. 90). The Administration regulations delegated by Art. 38(4), 39(8), 41(10) and 53(4) have not been published. Policy names such as “Business Licensing Rules (draft under Art. 39(8))” are placeholders and are labelled as drafts in the prototype. A pilot that starts before 1 July 2027 runs ahead of the legal effect of digital records; the proposal’s design phase should settle this with counsel.
8Glossary
| Term | Meaning |
|---|---|
| Proof event | The unit of record. A structured envelope describing who acted, under which rule, at which time and with which final status. It carries hashes, signatures and references, never the underlying document or personal data. |
| Canonical hash | The SHA-256 digest of the event envelope after canonicalization (RFC 8785, JSON Canonicalization Scheme). Two systems that hold the same fields compute the same hash. |
| Source system | A government or partner system that owns the documents, personal data and business payloads (for example the Licensing Service). It submits proof events and keeps everything else. |
| Proof gateway | The authenticated entry point. It validates the schema and lifecycle, canonicalizes and hashes the envelope, checks idempotency and signature quorum, and routes the event to a finality mode. Rejections quote the rule back. |
| Direct finality | A legally critical, low-volume event is written as its own transaction on the private chain and is final once the validators sign the block, within seconds. |
| Merkle batch | High-volume events are grouped in deterministic order; their hashes form a Merkle tree whose root is committed to the chain within 60 seconds. Each event keeps an inclusion path to that root. |
| Inclusion path | The sibling hashes a verifier needs to recompute the Merkle root from one leaf, proving that the event was part of the committed batch. |
| Validator quorum | The number of validator signatures a block or governance transaction needs. The pilot uses four validators and a quorum of 3 of 4 for governance, tolerating one faulty validator. |
| Observer | A read-only node that follows the chain, verifies and exports evidence but does not sign blocks. The pilot has two. |
| Evidence receipt | A human-readable receipt and a machine-verifiable proof package for one finalized event. It excludes payloads and can be verified offline. |
| Proof package | The JSON bundle a verifier consumes: envelope fields, hashes, signatures, certificate references and, for batched events, the inclusion path and root transaction. |
| Supersession | The append-only way to correct a record: a new event names the prior one and marks it superseded once finalized. Nothing is edited or deleted. |
| Legal hold | A flag that suspends retention expiry for a record and its references while a dispute or investigation is open. |
| Idempotency key | A source-supplied key that lets the gateway recognise a resubmission and refuse to create a second record for the same action. |
| Trusted timestamp | A time value from an approved time source, recorded with the event and compared with the block time during verification. |
9Sources
Primary
- SIGN Foundation, Alatau Sovereign Transaction Proof Ledger: Strategic Implementation Proposal, 25 August 2026 (confidential discussion draft). Cited on screens as “TPL proposal §…”.
- Constitutional Law of the Republic of Kazakhstan No. 286-VIII of 8 May 2026 “On the special legal regime of the city of Alatau”. Official text: adilet.zan.kz, document Z2600000286. Cited on screens as “Law 286-VIII Art. …”.
- Law of the Republic of Kazakhstan “On Personal Data and Their Protection” (2013, as amended) and the AML/CFT legislation of the Republic of Kazakhstan. Art. 4(3) of Law 286-VIII keeps both outside the special regime and Art. 12(1) applies the personal-data law to platform access. This is the reason payloads remain in source systems.
Standards and references used for the technical profile
- RFC 8785, JSON Canonicalization Scheme (JCS) · rfc-editor.org/rfc/rfc8785
- RFC 6962, Certificate Transparency: Merkle tree construction and inclusion proofs · rfc-editor.org/rfc/rfc6962
- RFC 3161, Time-Stamp Protocol · rfc-editor.org/rfc/rfc3161
- RFC 8032, Edwards-Curve Digital Signature Algorithm (Ed25519) · rfc-editor.org/rfc/rfc8032
- FIPS 180-4, Secure Hash Standard (SHA-256) · csrc.nist.gov
- RFC 5280, X.509 certificates and CRLs · rfc-editor.org/rfc/rfc5280
- NIST SP 800-53 Rev. 5, security and privacy controls (audit and access design) · csrc.nist.gov
- ISO/IEC 27001:2022, information security management (deployment acceptance evidence)
- Hyperledger Besu, QBFT consensus documentation · besu.hyperledger.org; Hyperledger Fabric, BFT ordering service · hyperledger-fabric.readthedocs.io
- Sign, Sovereign Infrastructure for Global Nations: evidence layer, schemas and attestations · docs.sign.global
Comparable prototype
- GFSO Supervision and Financial Intelligence Platform prototype and guide (Gelephu Mindfulness City, Bhutan): the persona-launcher, golden-path and coverage-matrix pattern this manual follows.
10Boundaries and version
- Fiction. All names, organizations, licences, permits, hashes, signatures, blocks and cases are fictional. Any resemblance to real entities is coincidental.
- No connected systems. eGov mobile, NCA digital signatures, security keys, HSMs, the certificate authority, the six source systems, validator nodes and observer nodes are simulated. None of them is operational, and no integration has been built.
- Cryptography. SHA-256 over canonical JSON is computed in the browser on the compose and attachment screens. Signatures, certificate chains, consensus and Merkle paths are deterministic placeholders. The offline verifier compares a package with its stored reference; no live chain is consulted.
- Performance. All performance and availability figures are illustrative sample values. The prototype does not benchmark anything and claims no ISO 27001 controls, tested recovery objectives or throughput.
- Approvals and certifications. Nothing in the prototype records an approval, a published regulation, a certification, a test result or deployed infrastructure. Governance transactions, ceremonies and drill schedules are illustrations of the charter.
- Persistence. State lives in the viewer’s browser only. Nothing is shared between viewers or sent anywhere.
- Production acceptance requires architecture, security, certification, performance and operational evidence as set out in proposal §6 and §7.
Version. Prototype v1.2 and manual v1.2 · 1 September 2026 · prepared by SIGN. Questions and change requests go to the SIGN delivery team.