Implementation Phases — From Thin Slice to Full Platform¶

Philosophy¶

Build the Smallest System That Can Fail Safely¶

We're not building features. We're building trust infrastructure.

The goal of each phase is to validate that the system: 1. Works correctly under normal conditions 2. Fails safely under abnormal conditions 3. Makes users feel safer, not more anxious

Security Before Features¶

Every phase starts with security foundations, not user features.

If encryption is wrong, everything is wrong. If triggers are unreliable, trust is gone. If audit trails have gaps, legal defense fails.

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

Goal¶

Validate the emotional and safety core with minimal infrastructure.

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

Implementation Status¶

Started: 2024-12-16 Location: /root/projects/vault

Component	Status	Notes
Next.js Project	Done	Standard stack with shadcn/ui
Database Schema	Done	`vault_core` schema applied to supabase-sandbox
Encryption Service	Done	Class B with tweetnacl (libsodium)
Audit Service	Done	Hash-chained, tamper-evident
Vault Data Layer	Done	CRUD with key material
Trigger Data Layer	Done	State management
Document Data Layer	Done	Envelope encryption
Executor Data Layer	Done	Assignment and tracking
Trigger Engine	Done	State machine with multi-signal
Release Engine	Done	Decryption and packaging
Landing Page	Done	Feature overview
Vault List UI	Done	With create dialog
Vault Detail UI	Done	Tabs for docs/trigger/audit
Simulation Mode	Done	Full flow testing
API Routes	Done	Vaults, triggers, documents, executors, check-in, cron
Email Notifications	Done	Resend integration with all templates
Authentik SSO	Done	Conditional auth (none/authentik modes)
K8s Deployment	Done	Dockerfile, manifests, CronJobs, deploy script

Scope¶

Build ONE complete path through the system:

User → Upload encrypted document → Configure dead man's switch →
Check in periodically → Miss check-in → Grace period → Execute →
Recipient receives access

Features¶

Feature	Include	Exclude
Vault	Single vault, Class B only	Multiple vaults, Class C
Documents	Upload, download	Version history
Trigger	Dead man's switch only	Scheduled, event-based
Check-in	Web-based only	SMS, app push
Notification	Email only	SMS, push
Recipients	Single recipient	Multiple, tiered
Audit	Basic append-only log	Hash chaining, signing
Simulation	Yes (essential)	Advanced scenarios
Abort	Yes (essential)	Reversal after release

Technical Stack¶

Next.js frontend (existing patterns)
Supabase backend (existing infrastructure)
Basic encryption (libsodium/tweetnacl)
Simple worker (cron-based check)
Email via Resend

Validation Criteria¶

[ ] User can complete full setup in < 10 minutes
[x] User understands what will happen (simulation works)
[x] Trigger fires correctly when check-in missed
[x] Trigger does NOT fire on single missed check-in (multi-signal)
[x] User can abort at any stage before execution
[ ] Recipient receives access when trigger executes (needs API routes)
[ ] User reports feeling "safer" in feedback (needs user testing)

Phase 1: Security Foundation (Weeks 3-5)¶

Goal¶

Build the corrected shared services that all products will use.

Components¶

Component	Week	Description
Encryption Service	3	All three classes (A/B/C), key derivation
Key Management	3	User keys, M-of-N escrow, recovery
Audit Logger	3-4	Hash chaining, sequence numbers, signing
Vault Service	4	Document storage, versioning, access control
Trigger Engine	4-5	Full state machine, all trigger types
Notification Service	5	Email, SMS, push, templates
Access Control	5	Multi-party, conditional, delegation

Encryption Service¶

// lib/security/encryption.ts
export class EncryptionService {
  // Class A: Server-managed keys
  encryptClassA(plaintext: Buffer): Promise<EncryptedData>;
  decryptClassA(ciphertext: EncryptedData): Promise<Buffer>;

  // Class B: User key + escrow
  encryptClassB(plaintext: Buffer, userKey: CryptoKey): Promise<EncryptedData>;
  decryptClassB(ciphertext: EncryptedData, userKey: CryptoKey): Promise<Buffer>;
  createEscrow(userKey: CryptoKey, contacts: Contact[], threshold: number): Promise<EscrowShares>;
  recoverFromEscrow(shares: EscrowShare[]): Promise<CryptoKey>;

  // Class C: Client-only
  // These methods exist in client-side library only
  // Server has no Class C decryption capability
}

Key Management¶

// lib/security/keys.ts
export class KeyManagementService {
  // User key lifecycle
  createUserKey(password: string): Promise<{ key: CryptoKey, salt: Buffer }>;
  unlockUserKey(password: string, salt: Buffer): Promise<CryptoKey>;
  rotateUserKey(oldPassword: string, newPassword: string): Promise<void>;

  // Escrow
  createEscrowShares(key: CryptoKey, config: EscrowConfig): Promise<EscrowShares>;
  requestRecovery(userId: string): Promise<RecoveryRequest>;
  submitRecoveryShare(requestId: string, share: EscrowShare): Promise<void>;
  completeRecovery(requestId: string): Promise<CryptoKey>;
}

Audit Logger¶

// lib/security/audit.ts
export class AuditLogger {
  // Append-only, tamper-evident
  log(event: AuditEvent): Promise<AuditEntry>;

  // Verification
  verifyChain(resourceId: string): Promise<ChainVerification>;
  getAuditTrail(resourceId: string, options?: TrailOptions): Promise<AuditEntry[]>;

  // Anchoring (periodic external witness)
  createAnchor(): Promise<Anchor>;
  verifyAnchor(anchor: Anchor): Promise<boolean>;
}

Validation Criteria¶

[ ] All encryption classes work correctly
[ ] Key recovery works with M-of-N threshold
[ ] Audit trail passes integrity verification
[ ] Trigger state machine handles all transitions
[ ] Notifications send via all channels
[ ] Access grants work with conditions

Phase 2: WitnessVault MVP (Weeks 6-7)¶

Goal¶

First product on the foundation. Defines patterns for all others.

Features¶

Full feature list from products/witness-vault.md MVP section: - Encrypted Vault (Class B default, Class C option) - Dead Man's Switch (full multi-signal) - Executor Access - Audit Trail - Simulation Mode

Technical Work¶

WitnessVault-specific UI components
Existence proof generation
Recipient onboarding flow
Dashboard and status views

Validation Criteria¶

[ ] Full WitnessVault flow works end-to-end
[ ] Class C encryption is truly zero-knowledge (code audit)
[ ] Multi-signal prevents false positives
[ ] Simulation accurately predicts execution
[ ] Existence proof verifies correctly

Phase 3: FinalFile MVP (Weeks 8-10)¶

Goal¶

Largest market opportunity. Consumes WitnessVault infrastructure.

Features¶

Full feature list from products/final-file.md MVP section: - Document Vault - Account Registry - Executor Management - Death Verification Trigger - Legacy Letters - Executor Checklists

Technical Work¶

Death verification trigger type
Account registry data model
Legacy letter editor
Executor dashboard
Guided workflows

Validation Criteria¶

[ ] Death verification flow works correctly
[ ] Executor can complete all tasks from dashboard
[ ] Legacy letters deliver correctly
[ ] User feels estate is "organized"

Phase 4: Platform Hardening (Weeks 11-12)¶

Goal¶

Production readiness. Security audit. Platform continuity.

Work¶

Area	Tasks
Security	Penetration testing, code audit, threat modeling
Continuity	Export system, platform dead man's switch, heartbeats
Observability	Monitoring, alerting, dashboards
Operations	Runbooks, incident response, on-call
Legal	Terms of service, privacy policy, charter publication

Validation Criteria¶

[ ] Security audit passes with no critical findings
[ ] Export system works completely
[ ] Platform continuity triggers correctly
[ ] Monitoring covers all critical paths
[ ] Legal documents reviewed by attorney

Phase 5+: Parallel Product Development¶

Goal¶

With foundation solid, develop products in parallel.

Track A: End-of-Life Stack¶

Product	Lead Time	Dependencies
LastMile	4 weeks	FinalFile integration
ParentTrap	4 weeks	Access control, collaboration

Track B: Exit/Safety Stack¶

Product	Lead Time	Dependencies
ExitMap	4 weeks	Class C encryption, safety features
GhostProtocol	6 weeks	ExitMap patterns, WitnessVault integration

Track C: Platform Enhancement¶

Enhancement	Lead Time
Mobile apps	8 weeks
API for partners	4 weeks
Advanced analytics	4 weeks
Multi-language	6 weeks

Resource Requirements¶

Phase 0.5 (Thin Slice)¶

1 full-stack developer
1 designer (part-time)
Duration: 1-2 weeks

Phase 1 (Foundation)¶

1-2 backend developers
1 security consultant
Duration: 3 weeks

Phase 2-3 (MVP Products)¶

2 full-stack developers
1 designer
Duration: 5 weeks

Phase 4 (Hardening)¶

1 developer
1 security auditor
1 legal consultant
Duration: 2 weeks

Phase 5+ (Parallel)¶

Scale team based on product priorities
Consider: 2 developers per track

Risk Mitigation¶

Technical Risks¶

Risk	Mitigation
Encryption implementation flaws	Use well-audited libraries (libsodium), security audit
Trigger false positives	Extensive testing, multi-signal verification
Data loss	Redundant storage, regular backups, export testing
Performance at scale	Load testing, architecture review

Business Risks¶

Risk	Mitigation
Users don't trust platform	Charter publication, transparency, security audit
Legal liability	Clear terms, process recording not truth claims
Competition	Focus on trust and security over features
Funding runway	Start with thin slice, validate before scaling

Operational Risks¶

Risk	Mitigation
Key person dependency	Documentation, knowledge sharing
Service outages	Monitoring, redundancy, incident response
Security incidents	Incident response plan, disclosure policy

Decision Points¶

After Phase 0.5¶

Go/No-Go: Do users report feeling safer? - Yes → Continue to Phase 1 - No → Iterate on UX, re-validate

After Phase 2 (WitnessVault)¶

Go/No-Go: Is the security model validated? - Yes → Continue to FinalFile - No → Invest more in foundation

After Phase 3 (FinalFile)¶

Go/No-Go: Is there market traction? - Yes → Scale team, parallel development - No → Focus on single product, validate PMF

This phased approach ensures we build trust infrastructure, not just features. Each phase validates the core before adding complexity.