# Governance & Operations

## 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](https://docs.sign.global/national-systems/new-money-system)
* [New Capital System](https://docs.sign.global/national-systems/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