Companion to PR #470 canonical deck. Renders the full top-to-bottom stack with EmberGraph slotted into its actual position. Built 2026-06-24 to give Lydo visual clarity before committing to the multi-quarter build.
Color convention (matches PR #470):
EmberKeep mediates third-party access to records the principal owns. Three things make this unusual:
The standard "Clerk + RLS + app code" pattern most SaaS products use doesn't fit because the matrix of (record × role × state) decisions is too large to encode inline at every consumer.
So we built a matrix. We have it. The question isn't "should we build EmberGraph" — it's "should we let the 3 parallel engines that drifted apart stay drifted, or converge them."
| Question | Database (Supabase) | EmberGraph |
|---|---|---|
| What does it own? | The bytes | The decision |
| What's its primitive? | Rows, columns, JSONB blobs | Access decisions + audit entries |
| Example question it answers | "Give me row 12345" | "Should viewer Anne see row 12345 right now, and in what form?" |
| Stays the same across products? | Yes (Postgres is Postgres) | Yes (matrix is matrix) |
| What goes in/out? | SQL → rows | (viewer, record, state) → projected payload + audit log entry |
| What it does NOT know | What "Cat 1" means; what "incapacitated" means; what a "role" is | Where the bytes physically live; how indexing works |
The shortest answer: the database is the filing cabinet. EmberGraph is the librarian who knows which documents each visitor is allowed to see, in what state the owner is in, and whether to hand over a full document, summary, or refuse.
┌──────────────────────────────┐
│ WHO USES THE APP │
│ Member · Advisor · Heir · │
│ AI agent · Attorney │
└──────────────┬───────────────┘
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
┌────────┐ ┌──────────┐ ┌────────┐
│ CLERK │ │ STRIPE │ │ RESEND │ (sub-processors)
│ (auth) │ │ (billing)│ │ (email)│
│ SOC 2 │ │ PCI-DSS │ │ │
└────┬───┘ └──────────┘ └────────┘
│
│ identity
▼
┌─────────────────────────────────────────┐
│ APPLICATION LAYER │
│ Next.js 14 (App Router) on Vercel │
│ │
│ • UI surfaces │
│ Letters · Family View · Emergency · │
│ Final Wishes · Settlement Packet · │
│ Settings / Who has access │
│ • API routes │
│ • Business logic │
└──────────────────┬──────────────────────┘
│
"can this viewer see this record? in what form?"
│
▼
╔═══════════════════════════════════════════════════════════╗
║ ║
║ ★ EMBERGRAPH ★ ║
║ ────────────────────── ║
║ the access decision substrate ║
║ ║
║ INPUTS ║
║ viewer identity ← from Clerk ║
║ record requested ← application ║
║ principal state ← alive · incap · deceased ║
║ role + activation ← three-stage chain ║
║ ║
║ LOGIC ║
║ 1. consult 360-cell visibility matrix ║
║ (classification × role × state) ║
║ 2. apply sub-filters ║
║ (release date · role scope · activation gate) ║
║ 3. produce projection ║
║ (FULL · SUMMARY · REDACTED · DENY) ║
║ ║
║ OUTPUTS ║
║ ▸ projected payload → caller ║
║ ▸ immutable audit entry → hash-chained log ║
║ ║
╚════════════════════╤══════════════════════════════════════╝
│
"fetch these rows / these specific fields"
│
▼
┌───────────────────────────────────────────────────────────┐
│ DATABASE LAYER │
│ Supabase Postgres + Storage │
│ │
│ • Records (artifacts, vault_sections, role_activations) │
│ • JSONB blobs │
│ • File pointers + storage buckets (signed URLs) │
│ • Coarse RLS = deny-all safety net (the FLOOR; │
│ EmberGraph is the ceiling) │
│ • AES-256 encrypted at rest │
│ • Hash-chained audit log table │
└───────────────────────┬───────────────────────────────────┘
│
(for the most sensitive vault content)
▼
┌───────────────────────────────────────────────────────────┐
│ CLIENT-SIDE SDB ENCRYPTION │
│ │
│ PBKDF2 → AES-GCM 256 · PIN-derived │
│ Keys never leave browser. EmberKeep cannot read SDB. │
└───────────────────────────────────────────────────────────┘
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SUPPORTING SUBSTRATE
Anthropic + Gemini · GCS (backup target) · Vercel edge
│
│ TODAY: AI calls bypass EmberGraph
│ (slide-7 known gap)
│
▼
┌─────────────────────────────────────┐
│ AI REDACTION LAYER (new — gap fix)│
│ lib/ai/redact.ts │
│ │
│ Every AI call routes through │
│ EmberGraph FIRST. Model sees only │
│ what the caller could have seen. │
└─────────────────────────────────────┘ Letters 6 role-display vault_sections
surfaces (every member read)
│ │ │
▼ ▼ ▼
projectArtifact() contact-roles.ts vault_share_grants
(1 surface uses (6 surfaces, bypass (coarse RLS, no
matrix) the matrix) per-classification)
│ │ │
▼ ▼ ▼
ENGINE #1 ENGINE #2 ENGINE #3
matrix-driven raw role state per-section RLSHonest: the canonical deck says "one engine." Reality is three. The matrix is correct logic that 6 of 7 surfaces don't consult.
Letters · 6 role-display surfaces · vault_sections · EK 4.0 RAG
│
▼
┌──────────────────────┐
│ decideAccess() │
│ (the SINGLE PDP) │
│ consults matrix │
│ applies sub-filters │
└──────────┬───────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
shapeRecord() decideRoleVisibility() shapeRagContext()
(Letters, (6 role-display (future EK 4.0)
vault surfaces)
sections)
│ │ │
▼ ▼ ▼
ALL audited through the hash-chained audit logThe reframing the external review locked: one decision authority, multiple enforcement paths. Not one function for everything.
TODAY (broken) TARGET (gap closed)
──────────────── ───────────────────
Application Application
│ │
▼ ▼
Build prompt Build prompt
│ │
│ unredacted vault content ▼
▼ EmberGraph
│
▼
decideAccess(AI_agent, record)
│
▼
Redacted payload
│
▼
Anthropic / Gemini ←─────────────── Anthropic / Gemini
│ │
▼ ▼
Response Response
🔴 Cat-1, Cat-2, Cat-3 🟢 Model receives only what
content shipped to model the caller could have seen.
regardless of viewer rights Audit entry recorded per call.This is the load-bearing reason EmberGraph exists at the chokepoint. Without it, every AI feature is a manual access-control surface.
What plugs into the stack later without a redesign:
| Future product | Plugs in where | Why it works |
|---|---|---|
| EK 4.0 — "EmberKeep Knows Me" (AI-native vault) | shapeRagContext() — new shaper, same
decideAccess kernel |
RAG retrieval is gated by the matrix; no special-case logic |
| Attorney B2B (Eric Gold's firm scenario) | New role type added to the matrix; existing
decideAccess consults it |
Adding roles is a config change, not an architectural change |
| Wealth advisor channel (BofA / Forward Inheritance) | New role + new release_condition (e.g.
client_signed_engagement) |
Sub-filter, not new code path |
| International / jurisdiction | New axis on the matrix (jurisdiction × classification × role × state) | Synthesis OPEN item; needs orthogonal modeling, not retrofit |
| Multi-principal / joint records | Schema change on records; matrix consults principal_set
instead of principal_id |
Bounded change inside the matrix layer |
| Compliance reporting (audit replay) | Already wired via hash-chained audit log + policy versioning (synthesis OPEN) | Audit log is the substrate |
The chokepoint pays for itself the second time you add a new surface.
| Layer | What's wired | What's the gap | Severity |
|---|---|---|---|
| Auth (Clerk) | ✅ Live, SOC 2 inherited | None | — |
| Database (Supabase) | ✅ Live, 59 migrations, RLS on 39 of 60 tables | 🔴 21 of 60 tables lack RLS (slide 3) | P0 before alpha |
| EmberGraph matrix | ✅ Wired in lib/access/visibility-matrix.ts |
🟡 Only 1 of 7 surfaces consults it | P0 (parallel-engine drift) |
| AI gating | 🔴 NOT WIRED | AI calls send unredacted vault content (slide 7) | P0 before alpha |
| Audit log | ✅ Hash-chained, RLS deny-all UPDATE/DELETE | 🟡 Co-transactional only on Letters surface | P1 |
| Client-side SDB encryption | ✅ Live, PBKDF2 → AES-GCM 256 | None | — |
| Three-stage role activation chain | ✅ Schema invariants enforced | 🟡 0 candidates in active state (no member-side
UI) |
P0 (EMB-420) |
| Dev/prod separation | 🔴 NOT WIRED — single Supabase project | Local dev hits production DB | P0 before alpha |
| Observability / error tracking | 🔴 NOT WIRED — PostHog stubbed, no Sentry | Production failures invisible | P1 |
| Backup + DR | 🟢 Nightly to GCS; 🔴 no documented restore | RTO/RPO unknown | P1 |
| Threat model (written) | 🔴 NOT WRITTEN | No artifact for advisor review | P1 |
security.txt |
🔴 NOT PUBLISHED | RFC 9116 noncompliance | P2 |
Pen test scheduled (locked 2026-05-22) before SOC 2 pursuit. Pen test scope must include the new chokepoint.
| Layer | Future-proof? | Confidence | Why |
|---|---|---|---|
| Database (Supabase Postgres) | ✅ YES | HIGH | Postgres scales; vendor not locked-in |
| Hosting (Vercel) | ✅ YES | HIGH | Edge runtime; serverless migration is possible |
| Auth (Clerk) | ✅ YES | HIGH | Standard OIDC; replaceable; SOC 2 inherited |
| EmberGraph matrix | ✅ YES | HIGH | Patent-track substrate; future-proofs against EK 4.0 + multi-product |
| Audit log (hash-chained) | ✅ YES | MEDIUM | Substrate is right; external anchoring needed at scale (synthesis) |
| Client-side SDB encryption | ✅ YES | HIGH | Already E2E for the sensitive layer |
| AI gating | ❌ NOT YET | — | The load-bearing close; closes slide-7 gap; enables EK 4.0 |
| Dev/prod separation | ❌ NOT YET | — | Substrate gap; pre-revenue is cheapest moment |
| Observability stack | ❌ NOT YET | — | Required for SLO tracking |
Verdict: the stack is fundamentally sound. The gaps are specific, named, and fixable. The chokepoint convergence + AI gating + dev/prod separation are the three load-bearing closes.
The architectural commit was reviewed by 5 independent LLM reviewers
(ChatGPT, Perplexity, Gemini, Grok, Claude CoWork) against a sanitized
design doc. Full synthesis at
embergraph-external-review-synthesis-2026-06-23.md.
| # | Design question | ChatGPT | Perplexity | Gemini | Grok | CoWork | Convergence |
|---|---|---|---|---|---|---|---|
| 1 | Single chokepoint vs peer engines | PDP/PEP split | One policy authority, not one shape | Logical SoT yes, physical no | Shared kernel + adapters | Right for decision, wrong as function | 5/5 PUSHBACK |
| 2 | Wrap (A) vs merge (B) for role-display | Shared kernel + role-specific evaluators | Reject B as written | Dedicated decideRoleVisibility |
A superior; dedicated primitive | B's doc-stated definition IS the category error | 5/5 AGAINST B-as-written |
| 3 | Per-row / per-field / migrate (vault_sections) | Per-field bridge, migrate long-term | Per-field transitional | Migrate NOW | Migrate NOW (>6-9mo threshold) | False dichotomy — per-section is a VIEW over unified store | SPLIT — CoWork reframes |
| 4 | Classification ⊥ semantic facets orthogonal | Load-bearing, day 1 | Load-bearing | Load-bearing, day 1 | Load-bearing, day 1 | Load-bearing as constraint, you're already violating it | 5/5 STRONG |
| 5 | Co-transactional audit invariant | Tier sync/aggregate | Co-trans for security-critical only | Outbox pattern; drop advisory lock | Strict; correct for trust-critical | Split the artifact (decision sync, chain spine async + anchored) | 4-DISTINCT POSITIONS |
| 6 | Sub-filter reification (all code?) | Hybrid (procedural + declarative) | Hybrid; declarative for stable | Fully declarative metadata | Hybrid, declarative-first | Separate binding (data) from evaluation (code) | 5/5 AGAINST PURE CODE |
| 7 | Three-state principal lifecycle | Decompose to 3 axes | Top bucket + state machine | Add Disputed / Reversible / Interregnum | Richer state machine | Capacity as a claim, not a property; who authorizes? | 5/5 AGAINST 3-STATE |
| 8 | Dev/prod sequencing | Upstream | Upstream | "Stop everything, fix environments" | Upstream of rebuild | Upstream, barely a question | 5/5 STRONG |
| 9 | What's missing | 8 items (versioning, temporal, break-glass, denial UX, caching, governance, regulatory drift) | Policy drift across representations; metadata escalation | Bootstrap paradox; break-glass; cryptographic boundary | Multi-principal; performance; cross-jurisdictional | State-transition authority; OIL = engine #2 reborn; right-to-erasure conflict; legal hold | NOVEL findings |
| Confidence band | # dimensions | Status |
|---|---|---|
| HIGH (5/5 panel converged + structural critique) | 10 | As locked as they can be without writing code |
| MEDIUM (clear direction, implementation choices remain) | 6 | Refines through implementation |
| LOW (novel concerns surfaced but not yet designed) | 7 | Each is a design pass we still owe |
We have the best directional design we can produce today, with 7 named gaps we haven't designed for yet. The HIGH band is decisional; the MEDIUM band is implementable; the LOW band is research-pending.
| Phase | Item | Duration | Why now |
|---|---|---|---|
| 0 | EMB-296 — Dev/prod environment separation | ~14-15 hrs over 4-5 days | 5/5 panel locked upstream; pre-revenue cheapest moment |
| 1a | AI redaction layer (lib/ai/redact.ts) |
1-2 days | Closes slide-7 honest gap; load-bearing for advisor trust |
| 1b | 21 RLS table closures | ~1 week | Closes slide-3 honest gap; required before alpha |
| 2 | EMB-420 minimum — member-side role-creation UI | ~1 week | Without it, 0 active roles forever; expanded scope is V2 |
| 3 | Domino #2 Strategy C — shared decideAccess + dedicated
decideRoleVisibility |
~2-3 weeks | Eliminates the 3-engine drift; 5/5 panel; the actual chokepoint convergence |
| 4 | Observability stack — Sentry + structured logger + cron alerting | ~1 week | Pre-revenue blind spots become P0 in prod |
Total MVP: ~5-6 weeks of focused build. Closes every slide-3 and slide-7 honest gap. Establishes the single decision authority. Ships safely before beta.
| Phase | Item | Trigger that forces the work |
|---|---|---|
| 5 | Domino #3 — vault_sections per-field
classification |
First customer who asks "why does my attorney see HIPAA notes" |
| 6 | Lifecycle expansion to capacity-as-claim model | First contested incapacity event |
| 7 | Sub-filter binding/evaluation engine | 8+ sub-filters in the catalog |
| 8 | Owner Intent Ledger moved inside matrix decision flow | OIL builds proven downstream |
| 9 | State-transition authorization full model + break-glass | First medical-emergency surface or 2nd incapacity case |
| 10 | Audit chain external anchoring (transparency-log style) | Pen test finding OR pre-SOC-2 audit prep |
| 11 | Multi-region audit replication | EU customer OR uptime SLA upgrade past 99.9% |
| 12 | Jurisdiction modeling (4th matrix axis) | International customer OR multi-state conflict |
┌─────────────────────────────────────────────────────────┐
│ PHASE 0 — Substrate ready (EMB-296) │ ◄── BLOCK
│ ──────────────────────────────────── │ starts
│ Dev/prod separation · staging gate · per-env keys │ here
└─────────────────┬───────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ PHASE 1 — Honest-gap closure (in parallel) │
│ ──────────────────────────────────────── │
│ 1a · AI redaction layer (slide-7 fix) │
│ 1b · 21 RLS closures (slide-3 fix) │
└─────────────────┬───────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ PHASE 2 — Bootstrap (EMB-420 minimum) │
│ ──────────────────────────────────── │
│ Owner UI to create role candidates │
│ Target-side accept flow (Stage 2 fresh re-auth) │
│ ▸ unblocks every downstream domino │
└─────────────────┬───────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ PHASE 3 — Chokepoint convergence (Domino #2 / C) │
│ ────────────────────────────────────────── │
│ Shared `decideAccess` kernel │
│ Dedicated `decideRoleVisibility` shaper │
│ 6 role-display surfaces refactor │
│ CI invariant: no direct role_activations reads │
└─────────────────┬───────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ PHASE 4 — Production observability │
│ ────────────────────────────── │
│ Sentry · structured logging · cron alerting · APM │
└─────────────────┬───────────────────────────────────────┘
▼
┃ ━ ━ ━ alpha ready · beta launch ━ ━ ━ ┃
│
▼ (driven by first-customer signal)
┌─────────────────────────────────────────────────────────┐
│ PHASE 5 — vault_sections classification (Domino #3) │
│ ───────────────────────────────────────────── │
│ Per-field classification map · unclassified default │
│ Mark + Eric legal review · codegen pipeline ship │
│ Strategy 4: unified records + section views │
└─────────────────┬───────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ PHASE 6 — Lifecycle + authorization │
│ ────────────────────────────── │
│ Capacity-as-claim model │
│ State-transition authorization framework │
│ Break-glass / emergency-override design │
└─────────────────┬───────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ PHASE 7 — Sub-filter engine + Owner Intent Ledger │
│ ────────────────────────────────────────────── │
│ Code-eval + data-binding split (CoWork sharpening) │
│ OIL moves inside matrix decision flow │
└─────────────────┬───────────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ PHASE 8 — Scale infrastructure │
│ ────────────────────────── │
│ Read replicas · synthetic monitoring · SLA tracking │
│ Audit chain external anchoring │
│ Multi-region replication (when EU customer signs) │
└─────────────────────────────────────────────────────────┘The MVP is what we ship before the Warm Lead Beta so we can sell to wealth advisors with a straight face. The marathon is what makes EmberKeep the patent-track substrate that future products (EK 4.0, attorney B2B, advisor channel) plug into.
Build the MVP next. Use it for 60-90 days. Let real customer questions drive the marathon's sequencing.
Generated 2026-06-24 by Claude Code. Visual artifact for
design clarity. Companion HTML at
full-stack-with-embergraph.html.