Risk Analysis — GPT5.2 Critique and Response¶
Overview¶
During the planning process, the architecture was reviewed by GPT5.2 (OpenAI). This document captures the critique, our response, and how identified risks were addressed.
Purpose: Ensure identified blind spots are documented and mitigated.
External Critique Summary¶
GPT5.2 assessed the initial plan as "unusually strong" with a "real unifying abstraction" but identified several critical blind spots that could "sink the project later."
What Was Validated¶
-
Unifying abstraction is real — "Data that must remain inaccessible until conditions are met" is a genuine common substrate, not forced.
-
Security-first ordering is correct — Encryption, audit, and key management before product UI is right for this domain.
-
Audit log design shows legal thinking — Append-only with hash chaining indicates optimization for evidentiary integrity.
-
Trigger engine centralization — Avoiding scattered cron job anti-pattern is the right architecture.
Critical Blind Spots Identified¶
- Cryptography boundaries underspecified
- Dead man's switch false positives
- Legal jurisdiction missing
- RLS + custom access control conflict
- Audit log tamper resistance incomplete
- Key escrow needs quorum
Detailed Risk Analysis¶
Risk 1: Cryptography Boundaries Underspecified¶
Original Problem: The plan mixed three different threat models without separation: - Server-side field-level encryption - True E2E (client-held keys) - Escrow/recovery/executor access
These cannot share the same primitives.
Specific Questions Unanswered: - Which data can NEVER be decrypted by the server? - Which data MUST be decryptable after death? - Which data supports "zero-knowledge optional"?
Resolution: Defined three explicit encryption classes:
| Class | Server Access | Use Case |
|---|---|---|
| A | Full access | Metadata, indexes, coordination |
| B | During trigger only | Estate docs, legacy letters |
| C | Never | Evidence, identity artifacts |
Documentation: 03-crypto-classes.md
Verification: - [ ] Every encrypted field tagged with class - [ ] No decrypt() for Class C in server code - [ ] Class B decryption only in trigger handlers - [ ] Code audit confirms boundaries
Risk 2: Dead Man's Switch False Positives¶
Original Problem:
Simple differenceInDays logic is naive. One wrong trigger destroys trust permanently.
Scenarios Not Addressed: - Hospitalization (no phone access) - Travel to connectivity dead zones - Mental health crisis - Deliberate silence without intent to trigger - Device loss/theft
Resolution: Implemented multi-signal verification requirement:
Trigger NEVER fires on single signal. Minimum:
1. Check-in missed
2. Email reminder unacknowledged
3. SMS verification failed
4. (Optional) Secondary contact confirms concern
Plus staged execution with abort windows at every stage.
Documentation: 04-trigger-state-machine.md
Verification: - [ ] Unit tests confirm single signal doesn't trigger - [ ] Integration tests for all false-positive scenarios - [ ] Abort works at every abortable state - [ ] User can always reach system to abort
Risk 3: Legal Jurisdiction Missing¶
Original Problem: Architecture assumed "trigger fires → authority transfers" which isn't universally true.
Variations Not Addressed: - Probate requirements before executor authority - Death verification standards (certificate vs court order) - Power of attorney rules - Data protection laws (GDPR, state privacy)
Resolution: Added jurisdiction abstraction to data model:
ALTER TABLE vault_core.triggers ADD COLUMN jurisdiction JSONB;
-- {country: 'US', state: 'CA', legal_notes: '...'}
Adopted "process recorder, not truth authority" principle: - Never say "legally binding" - Say "process support" and "custodial record" - Record actions and timestamps, not truth claims
Documentation: 01-foundational-vision.md
Verification: - [ ] API responses contain no truth assertions - [ ] Jurisdiction stored on all triggers - [ ] Copy never claims legal validity
Risk 4: RLS + Custom Access Control Conflict¶
Original Problem: Layering Authentik RBAC + Supabase RLS + custom grants + conditional triggers creates debugging nightmares and potential security gaps.
Resolution: Simplified access control model: - RLS: Owner isolation ONLY (you can never see another user's data) - Application layer: All conditional access (executor, time-locks, triggers)
RLS is a safety net, not the authorization logic.
Documentation: 03-crypto-classes.md (API Boundaries section)
Verification: - [ ] RLS policies only check owner_id - [ ] All conditional access in application code - [ ] Access grants checked before operations
Risk 5: Audit Log Tamper Resistance Incomplete¶
Original Problem: Hash chaining alone doesn't prevent: - Truncation (delete last N entries) - Reordering (swap entries) - History forking (alternate timelines)
Resolution: Enhanced audit log design:
- Sequence numbers — Every entry has monotonic sequence
- Hash chaining — Each entry includes previous hash
- Service key signing — Entries signed with platform key
- Periodic anchoring — Root hash published to external witness
- Separate DB role — No UPDATE/DELETE privileges on audit tables
Documentation: 04-trigger-state-machine.md (Audit section)
Verification: - [ ] Sequence gaps detected - [ ] Chain verification passes - [ ] Signature verification works - [ ] Anchoring implemented - [ ] DB role has no mutation privileges
Risk 6: Key Escrow Needs Quorum¶
Original Problem: Single recovery contact is a social engineering attack vector.
Resolution: M-of-N Shamir-style recovery: - Keys split into N shares - M shares required to reconstruct (typically 3-of-5) - Shares distributed to role-bound contacts - Time delay after reconstruction request (24-72 hours) - User notified if reconstruction attempted
Documentation: 03-crypto-classes.md (Key Management section)
Verification: - [ ] Key splitting works correctly - [ ] M-of-N threshold enforced - [ ] Time delay implemented - [ ] User notification on recovery attempt
Additional Risks Identified (Second Pass)¶
Risk 7: Platform Compromise Threat Model¶
Problem: What if K8s cluster, database, or operator is compromised?
Resolution: - Class C (zero-knowledge) provides protection for most sensitive data - Platform cannot decrypt Class C even if fully compromised - Class B requires trigger execution, limiting exposure window - Audit trail is tamper-evident, showing any manipulation
Verification: - [ ] Class C truly zero-knowledge (code audit) - [ ] Compromised server cannot access Class C plaintext
Risk 8: Death Verification Flow¶
Problem: Who tells system someone died? How do we verify? Death certificates can be forged.
Resolution: "Process recorder, not truth authority" approach: - Record that executor submitted certificate - Record that secondary confirmed - Record that challenge period elapsed - DO NOT assert that person is actually dead
Combined with: - Mandatory delay (7 days) - User notification (in case they're alive) - Challenge window (14 days) - Secondary confirmation option
Documentation: 04-trigger-state-machine.md (Death Verification section)
Risk 9: Reversibility Philosophy¶
Problem: Once trigger executes, can it be stopped? What if user recovers? What if certificate was wrong?
Resolution: "Irreversibility is delayed, not denied" principle: - Staged execution with abort windows at every stage - Reversal possible for 7 days after release - True finality only after explicit criteria met - All transitions logged with justification
Documentation: 04-trigger-state-machine.md
Risk 10: Platform Continuity¶
Problem: What if company dies? End-of-life software that dies with company is moral failure.
Resolution: - Guaranteed export in documented, open format - Schema designed for portability - Platform dead man's switch (multi-signal, 90-day grace) - Open-source consideration for core code
Documentation: 06-platform-continuity.md
Risk 11: Adversarial UX¶
Problem: Users are grieving, afraid, overwhelmed, sometimes coerced.
Resolution: Design for emotional fragility: - No irreversible action without typed confirmation - No dark patterns, ever - Visible state at ALL times - "Nothing has happened yet" reassurance - Plain-language copy for crisis contexts
Documentation: 05-simulation-mode.md
Risk Matrix¶
| Risk | Severity | Likelihood | Mitigation Status |
|---|---|---|---|
| Crypto boundaries | Critical | High (without design) | Resolved — 3 classes defined |
| False positives | Critical | Medium | Resolved — multi-signal |
| Jurisdiction | High | High | Resolved — data model field |
| Access control conflict | High | Medium | Resolved — RLS simplification |
| Audit tampering | High | Low | Resolved — enhanced design |
| Key escrow weakness | High | Medium | Resolved — M-of-N |
| Platform compromise | Critical | Low | Mitigated — Class C |
| Death verification fraud | High | Medium | Mitigated — process recording |
| Premature irreversibility | High | Medium | Resolved — staged execution |
| Platform death | Critical | Low | Resolved — continuity system |
| Adversarial UX | Medium | High | Resolved — design principles |
Outstanding Concerns¶
Operational Complexity¶
Building and operating this system requires: - Security expertise - Legal understanding - Emotional intelligence in design - Long-term commitment
Mitigation: Start with thin slice, validate before scaling.
Regulatory Uncertainty¶
Death, estates, and data privacy intersect multiple regulatory domains.
Mitigation: "Process support" positioning, not legal service claims.
Trust Building¶
Users must trust platform with their most sensitive information.
Mitigation: Ethical charter, transparency, security audits, gradual trust building.
Conclusion¶
The external critique identified real blind spots that have been addressed in the architecture. The key insight from GPT5.2:
"You stopped treating security as a feature set and started treating it as authority under incapacity."
This reframe — from SaaS to trust institution — is the foundation for all design decisions.
The remaining risk is execution: building what we've designed, correctly, with appropriate gravity.
This risk analysis will be updated as new risks are identified or mitigations are validated in implementation.