# 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](/national-systems/new-money-system.md)
* [New Capital System](/national-systems/new-capital-system.md)

***

## 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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.sign.global/s.i.g.n./governance-ops.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.