Skip to content

Vault Platform — Trust Institution for Irreversible Human Transitions

Status: Planning Complete | Ready for Phase 0.5 Implementation Created: 2025-12-16 Last Updated: 2025-12-16

What This Is

A unified platform for building software that serves people during irreversible life transitions: - Death and estate execution - Active dying and end-of-life - Family care coordination - Escape from high-control groups - Identity protection and severance - Evidence preservation against adversaries

Core insight: This is not SaaS. This is a trust institution — a custodian for moments when people cannot verify that systems are acting correctly on their behalf.

Product Stack

End-of-Life Stack

Product Purpose Status
FinalFile Digital estate vault + executor management Planned
LastMile Active dying support (bucket lists, legacy recording) Planned
ParentTrap Sibling coordination for aging parent care Planned

Exit/Safety Stack

Product Purpose Status
ExitMap Leaving high-control groups (cults, abusive orgs) Planned
GhostProtocol Identity severance and protection Planned

Foundation

Product Purpose Status
WitnessVault Encrypted storage with conditional release (dead man's switch) Planned — Build First

Documentation Index

Planning & Process

Core Architecture

Products

Implementation

Validation & Testing

Operations

Key Principles

1. Process Fidelity, Not Truth Claims

We don't say "X is true." We say "On [date], [actor] submitted [artifact]. On [date], [action] executed per documented process."

2. Irreversibility is Delayed, Not Denied

Every irreversible action has challenge windows, abort paths, and staged execution.

3. Fail Safely (Product-Specific)

  • WitnessVault/GhostProtocol: Fail closed (don't release when uncertain)
  • FinalFile/LastMile: Fail open (honor intent even under uncertainty)

4. The Audit Trail IS the Product

Legal defensibility comes from process documentation, not truth assertions.

5. Design for Adversarial UX

Users are grieving, afraid, overwhelmed, sometimes coerced. Every interaction assumes emotional fragility.

Governing Questions (Answered)

Question Answer Rationale
Should Class C (zero-knowledge) be default? No, but per-product defaults Class C breaks many features; make it default only where protection > functionality
How do we verify death? Process recording, not truth claims "Executor submitted X" not "Person is dead"
How long are abort windows? Product-specific, always > 0 Balance protection vs. honoring intent
What if the platform dies? Guaranteed export + platform dead man's switch 90-day grace, multi-signal, encrypted export to users
US-only or international? US-only MVP, jurisdiction stored as data Don't hardcode; make room for expansion

Implementation Sequence

Phase 0.5: Thin Vertical Slice (1-2 weeks)

Validate the emotional/safety core: - One encrypted vault (Class B) - One dead man's switch (multi-signal) - One executor role - Email notifications only - Simulation mode - Abort windows

Success criteria: Does this make someone feel safer, or more anxious?

Phase 1: Foundation (Weeks 3-5)

Build corrected shared services: - Encryption Service (all three classes) - Key Management (M-of-N recovery) - Audit Logger (tamper-evident) - Trigger Engine (full state machine) - Notification Service

Phase 2: WitnessVault MVP (Weeks 6-7)

First product on the foundation.

Phase 3: FinalFile MVP (Weeks 8-10)

Consumes WitnessVault, adds estate-specific UX.

Phase 4+: Parallel Development

All products can develop independently on shared foundation.

External Consultations

This planning process included critique from GPT5.2 (OpenAI), which identified critical blind spots: - Cryptography boundaries were underspecified - Dead man's switch false positives are existential risk - Legal jurisdiction was missing entirely - Audit log tamper resistance was incomplete - Key escrow needed quorum, not single recovery

All identified gaps have been addressed in the architecture documents.

Files in This Directory

vault-platform/
├── README.md                          # This file
├── 00-planning-process.md             # Decision history
├── 01-foundational-vision.md          # Trust institution reframe
├── 02-ethical-charter.md              # 12 testable commitments
├── 03-crypto-classes.md               # A/B/C definitions
├── 04-trigger-state-machine.md        # States and transitions
├── 05-simulation-mode.md              # UX contract
├── 06-platform-continuity.md          # Platform continuity
├── 08-implementation-phases.md        # Phased approach
├── 09-infrastructure-audit.md         # Current infrastructure
├── 10-risk-analysis.md                # GPT5.2 critique integration
├── 11-acceptance-test.md              # North Star acceptance test
├── 12-invariants-and-gates.md         # Release-blocking invariants + PR gates
├── 13-event-schema.md                 # Audit event type definitions
├── 14-operational-runbooks.md         # Incident response + emergency controls
└── products/
    ├── witness-vault.md
    ├── final-file.md
    ├── last-mile.md
    ├── parent-trap.md
    ├── exit-map.md
    └── ghost-protocol.md

This documentation represents the output of a comprehensive planning session. The goal was to collapse ambiguity into explicit institutional commitments and failure modes before writing code.