Governance & Operations

Governance and operations model for sovereign deployments including roles, key custody, change management, SLAs, and audit readiness.

Purpose

S.I.G.N. deployments are not “just software.” They are sovereign systems that must be governable, operable, and auditable.

This page provides a reference governance + ops model that can be adapted per country.

---

Governance model (three layers)

Successful deployments separate governance into:

1) Policy governance

Defines:

• what programs exist,

• what rules apply (eligibility, caps, schedules),

• what privacy level each program requires (public vs private mode),

• which entities are authorized.

Outputs:

• program policies

• rule definitions

• legal/regulatory approvals

2) Operational governance

Defines:

• who runs systems day-to-day,

• what the SLAs are,

• how incidents are handled,

• how audit exports are produced.

Outputs:

• runbooks

• escalation paths

• monitoring dashboards

• maintenance windows

3) Technical governance

Defines:

• upgrade policies,

• emergency controls,

• key custody,

• change approval workflows.

Outputs:

• change management process

• release cadence

• rollback plan

• key rotation policy

---

Roles and responsibilities (reference)

Sovereign Authority (root)

• owns high-level policy and oversight

• approves:

  • system upgrades

  • emergency actions (pause/freeze)

  • bridge parameter changes

Central bank / treasury operator (money rail)

• governs CBDC policies and settlement operations (if applicable)

• controls CBDC network membership and compliance requirements

Identity authority (ID system)

• accredits issuers

• governs schemas and revocation policies

• defines trust registry procedures

Program authority (capital/distribution)

• defines eligibility rules and distribution policies

• approves large batch distributions

• manages program budgets and reconciliation

Technical operator (SRE/Infra)

• runs nodes, indexers, APIs, monitoring

• executes approved changes

• maintains uptime and incident response

Auditor / supervisor

• reviews evidence

• reconciles distribution outputs

• investigates exceptions and disputes

Principle: separation of duties. The entity running infra should not be the entity issuing credentials.

---

Key management (minimum expectations)

Key categories

• Governance keys

  • used to approve upgrades, emergency actions, parameter changes

• Issuer keys

  • used to sign credentials or attestations

• Operator keys

  • used to run infrastructure components and access restricted systems

• Audit keys

  • used to decrypt or access lawful audit datasets (when applicable)

Baseline requirements

• Governance keys should be multisig and/or HSM-backed

• Issuer keys should be HSM-backed where possible

• Rotate keys on schedule and after incidents

• Document and test recovery procedures

Example approval policy (reference)

• Routine upgrade: 2-of-3 multisig (technical governance committee)

• High-risk upgrade: 3-of-5 multisig (policy + technical)

• Emergency pause: 2-of-3 “emergency council” + post-incident review

• Bridge parameter change: 3-of-5 + monitoring escalation requirement

---

Change management

A change should not be “merged and shipped.” It should be governed.

Change categories

• Doc-only

• Config-only (limits, schedules, whitelists)

• Software upgrade (contracts, nodes, APIs)

• Emergency action

Required artifacts for each change

• change request + rationale

• impact assessment (security, availability, privacy)

• rollback plan

• approval signatures

• deployment log entry (time, operator, version)

---

Operational readiness

Monitoring

Minimum recommended dashboards:

• issuance volume (by issuer)

• verification volume (by verifier)

• distribution volume (by program)

• bridge conversion volume and error rates

• API latency / error rates (SignScan / SDK endpoints)

• node health (public/private rails)

Incident response

Define:

• severity levels (SEV1–SEV4)

• on-call schedule

• communication plan (internal + public)

• postmortem template

• evidence export process for incident investigations

Business continuity

Define:

• backups of off-chain stores

• disaster recovery procedure

• degraded-mode operations (read-only, limited issuance, etc.)

• manual override policy (with evidence logging)

---

Audit operations

What auditors need

Auditors typically require:

• rule definitions and versions

• identity and eligibility proof references

• revocation/status check logs

• distribution manifests

• settlement references

• reconciliation reports

Recommended audit export format (reference)

• Program metadata

• RuleSet hash/version

• Distribution batch manifests (pseudonymous IDs)

• Settlement references (tx hashes / commit IDs)

• Signed approvals

• Exceptions log

See examples in:

• New Money System

• New Capital System

---

Deployment methodology (phased)

A common sovereign pattern:

1. Assessment & planning

   • map stakeholders and systems

   • define privacy requirements per program

   • define governance and key custody

2. Pilot

   • limited scope, limited users

   • strong monitoring + manual controls

3. Expansion

   • multiple agencies/operators

   • production-grade SLAs and audits

4. Full integration

   • connect to broader government service ecosystem

   • mature governance, stable operations, standard audits