Governance Policy
Who can do what, and what stops anyone from doing too much. This page defines the roles, thresholds, procedures, and failure modes that keep the system honest.
The cast
Five roles interact with the governance system. Each has specific powers and hard limits. The asymmetry is deliberate: stopping is easy, starting is hard, and expanding is impossible.
Trustee
Governors with constrained authority. They hold key shares and make collective decisions.
- Can do
- Suspend unilaterally. Participate in quorum votes. Narrow behavior post-mortem.
- Cannot do
- Unilaterally activate. Expand consent. View the archive directly. Delegate authority.
Auditor
Inspectors who verify system behavior under defined conditions.
- Can do
- Verify response bundles. Check logs. Request inclusion proofs.
- Cannot do
- Modify logs. Access the archive directly. Expand access beyond their scope.
Operator
Runs the infrastructure. Keeps the system available and correct.
- Can do
- Maintain systems. Deploy updates (with governance approval). Serve requests.
- Cannot do
- Override policy. Access plaintext archive content. Lower thresholds.
Decedent
The person whose archive exists. Defined everything while alive.
- Can do
- Set all consent. Choose trustees. Configure thresholds and delays. Revoke everything.
- Cannot do
- Act after death. Their consent is immutable once they are gone; scope only narrows.
Requestor
Someone seeking interaction with the persona.
- Can do
- Submit questions. View display citations. Export session receipts.
- Cannot do
- Access the archive directly. Bypass consent gates. Override coverage rules.
Permissions matrix
Every trustee action has its own threshold. The principle: the more irreversible or expansive the action, the higher the bar. The more protective the action, the lower the bar. For a trustee set of size N, here is what each action requires.
| Action | Threshold | Formula | Who can trigger | Reversible? |
|---|---|---|---|---|
| Suspend persona | Any single trustee | 1-of-N | Trustee | Yes (by quorum) |
| Flag anomaly | Any single trustee | 1-of-N | Trustee | N/A |
| Request assembly | Any single trustee | 1-of-N | Trustee | N/A |
| Lift suspension | Simple majority | >N/2 | Trustees (not original suspender alone) | N/A |
| Approve rotation | Simple majority | >N/2 | Trustees | No (swap is permanent) |
| Key assembly | Supermajority | ceil(2N/3), min 3 | Trustees | No |
| Dispute resolution | Supermajority | ceil(2N/3) | Trustees | No |
| Policy changes | Supermajority | ceil(2N/3) | Trustees | By another policy change |
| Archive inspection | Near-unanimity | N-1 of N | Trustees | Scope-bounded |
| Emergency override | Near-unanimity | N-1 of N | Trustees | Limited scope |
| Expand consent | Impossible | 0-of-N | No one | Never |
| Delete audit logs | Impossible | 0-of-N | No one | Never |
Procedures
Six governance actions illustrated step by step. Each procedure has a defined trigger, a sequence of operations, and a clear outcome.
Suspension
Any single trustee can freeze the persona immediately. The system halts all interaction, zeroes active key material, and logs the event with a reason code. Lifting the suspension requires a quorum vote that includes at least one trustee other than the one who pulled the switch.
A trustee detects a problem: anomalous responses, a breach report, or a governance concern. They submit a suspension with a reason code.
The system freezes immediately. All sessions end. Key material is zeroed. No interaction is possible.
To resume, a majority of trustees must vote to lift. The original suspender alone cannot lift it. The root cause must be addressed and logged.
Trustee rotation
Replacing a trustee without weakening governance. N never drops during rotation. The departing trustee's share is invalidated, and a fresh share is issued to the replacement. The secret is never reconstructed during this process.
Step 1: Propose. Any trustee submits a rotation proposal naming the departing and incoming trustees.
Step 2: Vote. Remaining trustees vote. Simple majority for standard rotation; supermajority if contested.
Step 3: Refresh shares. Proactive share refresh re-randomizes all shares. The departing trustee's share is invalidated. No secret reconstruction occurs.
Step 4: Onboard. New trustee completes identity verification, signs the role acceptance, and verifies their share against published commitments.
Step 5: Activate. Only after all phases complete is the new trustee marked active and eligible to participate in governance actions.
Key assembly
After the delay window completes, trustees convene to reconstruct the decryption key. The reconstructed key exists only inside sealed compute, is used immediately, and is then zeroed. Completion of the delay does not activate the persona; it only permits this step.
Delay complete. The system logs that the configured duration has elapsed with only clean time counted. No disputes or suspensions are pending.
Trustees submit shares. Each share is encrypted to the attested enclave's public key. The supermajority threshold must be met: at least ceil(2N/3) shares, minimum 3.
Sealed compute assembly. Shares combine inside the enclave. The key is used, then zeroed from memory. The persona is now operational.
Operator distrust
When the operator misbehaves, trustees have a five-level escalation ladder. Each level requires a higher threshold of agreement. The operator is a named threat actor in the governance model; trustee oversight is not optional.
- Inquiry. Any single trustee sends a formal, logged question. The operator has 7 days to respond. No system changes.
- Audit demand. A simple majority of trustees requests specific evidence. The operator must provide it. Failure to comply is itself a violation.
- Suspension. Any single trustee pulls the circuit breaker. The operator cannot lift it. All interaction halts until the quorum votes to resume.
- Distrust declaration. A supermajority declares the operator untrustworthy. The persona is suspended, key assembly is blocked for this operator, and migration to a new operator begins. The distrusted operator retains encrypted data but cannot decrypt it.
- Archive extraction. Near-unanimity authorizes a full export: content-addressed manifest, consent and policy history, transparency log with proofs, and a signed completeness statement. The archive moves to trustees or a successor operator.
Dispute Resolution
When a persona's authenticity or compliance is challenged, the framework provides three resolution paths scaled to severity.
- Liveness check. Automated re-verification of credentials and binding validity. Resolves within one delay window.
- Evidentiary review. An appointed auditor examines the challenger's evidence and the persona holder's response bundle. The auditor publishes findings to the transparency log.
- Trustee supermajority vote. For unresolved disputes, trustees convene a supermajority vote (
ceil(2N/3)). The outcome (sustained, dismissed, or escalated) is final and logged.
Archive Inspection
Archived personas remain queryable under strict scope-bounded access. Every inspection request must include a reason code.
| Reason Code | Access Scope | Approval |
|---|---|---|
| Legal hold | Full record | Trustee supermajority |
| Academic research | Anonymised extract | Single trustee + auditor |
| Compliance audit | Metadata only | Auditor credential check |
| Heir access | Designated subset | Near-unanimity (ceil(2N/3) + 1) |
Near-unanimity threshold ensures archived data is never disclosed casually. All inspection events are appended to the transparency log with requester identity and scope.
Failure modes
Trustees are humans. They disappear, get compromised, face coercion, conspire, or simply lose track of things. The system handles each case with a specific detection signal and a specific response. The universal principle: the system degrades toward safety, never toward access.
1. Disappearance
Detection: Non-responsive after missing an action window. Consecutive non-responses or missed liveness checks trigger a trustee-absent flag.
Response: The system does not reduce N. It does not route around absent trustees. Disappearance makes activation harder, not easier. The 1-of-N suspension power still works regardless.
Recovery: Rotation via the standard procedure. A trustee may also formally resign with a signed statement, immediately marking them absent and starting rotation.
A trustee stops responding. Action windows pass without their input.
The remaining trustees proceed with reduced numbers, but N stays the same. Thresholds become harder to reach.
Rotation begins. A replacement is proposed, voted on, and onboarded through the standard procedure.
2. Compromise
Detection: Unexpected actions, self-report, or external breach reports.
Response: Immediate suspension via circuit breaker. Flagged votes on pending actions. The compromised trustee's share is marked as tainted and cannot contribute to any threshold action or reconstruction until re-verified and reissued.
Recovery: Proactive share refresh for all non-tainted trustees. Forced rotation of the compromised trustee.
3. Coercion
Structural defense: Thresholds mean one coerced trustee is insufficient for anything beyond suspension. Geographic and organizational diversity is recommended. Share submission uses sealed compute.
Optional duress protocol: A trustee submitting under duress uses a duress key that is indistinguishable from a normal key to any outside observer. Duress-flagged votes do not count toward thresholds. The flag triggers a "coercion hold" that requires supermajority plus a cooling period to exit.
Recovery: Re-verification and share refresh, or rotation if coercion is ongoing.
4. Collusion
Detection: Audit patterns reveal identical or near-identical reason codes, identical vote timing, repeated safety-flag overrides, or repeated attempts at invasive actions. Consistent agreement is a soft hint only, not an automatic trigger.
Response: A collusion-suspected flag ratchets thresholds upward temporarily. Actions that are structurally impossible (0-of-N) remain impossible regardless. A non-colluding trustee can suspend, and an audit review begins.
Recovery: Rotation of suspected trustees if thresholds allow.
5. Incompetence
Detection: Empty reason codes, copy-paste duplicates, votes submitted without opening the evidence hash. High-impact actions require a read receipt.
Response: Lost key material triggers share refresh. Thin reason codes get flagged with a prompt for more detail. Security hygiene failures cause action rejection.
Recovery: Re-verification. Rotation for persistent incompetence at the same threshold as any standard rotation.
Appeals and deadlocks
Sometimes governance stalls. Trustees disagree, grieve, or simply cannot act. The system treats deadlock as a legitimate state, not a malfunction. The posture: wait safely, preserve everything, never force a resolution.
Backup trustees
The decedent can pre-enroll backup trustees while alive. These are identity-verified and recorded in the governance policy from day one, but inactive. Activating a backup trustee is a supermajority governance action. Their share is issued through a logged refresh event. There are no surprise trustees.
Refusal is legitimate
A trustee who believes the persona should not activate can submit a refusal attestation: signed, with a reason code, and logged. This is not permanent unless stated. Withdrawal of a refusal is also logged. When permanent refusals make a threshold mathematically impossible, the system acknowledges it: the action is foreclosed, all parties are notified, and the archive is not destroyed.
The long wait
If rotation is also foreclosed, the system enters permanent preservation mode. The archive exists as a sealed time capsule, preserved for posterity but never interactive. The transparency log persists independently.
Letter of intent
The decedent can leave a message to trustees stored in the governance record, visible at key assembly, explicitly labeled as non-binding. It is context, not a command. Something like: "I built this because I wanted my grandchildren to hear my voice. I hope you will let them, when it is time."