Forensic Recovery and Canonical Receipt Dossier

Executive ruling

The current DeedSonar incident is not evidence that the September 9 Supabase cutover erased the estate. That is the source claim, labeled as a source claim below.

SOURCE CLAIM [S1]: The September 10 handoff documents live-query evidence showing the Pro database contains the canonical DeedSonar estate, the principal estate views are present with the expected counts, tenant scope is uniform, RLS and grants are not obviously deficient, and the deployed bundle points at the intended Pro project. The leading fault is stale legacy-signed authentication state in the browser after the Supabase environment swap, with a second auth risk around auth.identities that the original cutover fingerprint did not check.

The deeper problem is continuity, not invention. The proof already exists, but it is fragmented across formal dossiers, receipt markdown, Git custody, local worktrees, terminal logs, Notion canons, and library indexes. The remedy in the source is a single receipt registry and evidence spine that points to primary artifacts rather than another redesign.

PROVEN REAL-BUT-SEPARATE OPEN UNKNOWN NOT-TO-BE-REOPENED

1. What actually happened

2. Current incident: evidence, not theory

Use the parity calculator in the Calculators section to recompute every difference below. The table values are copied from the source.

3. Immediate remediation order

Do these in this order. Do not reopen migration archaeology already killed by live evidence.

1. Step 1. Fresh session test. Incognito, app.deedsonar.com, log in. Purpose is to force a token minted by the current Pro project. If data populates, the database and runtime route are substantially exonerated and the normal browser has stale cookies.
2. Step 2. Clear only the DeedSonar host cookies. Clear cookies for https://app.deedsonar.com, hard reload, log in again. Session lives in cookies because the app uses @supabase/ssr with server-side cookie reads.
3. Step 3. If fresh login fails, check identities. Run the supplied read-only query against Pro and compare auth.users, auth.identities, email identities, password presence, and confirmation counts. An identities = 0 result is the specific auth migration bug named in the handoff.
4. Step 4. Capture the browser-side decisive artifact. DevTools, Network, Fetch/XHR, reload, click a failing data request, Response. A protected API returning 401 while the shell looks logged in confirms auth/session failure; a 200 with empty arrays moves the investigation to the route/query layer. Do not look for /rest/v1/ traffic; the app uses its own /api/* routes.
5. Step 5. Audit the actual code path. Inspect src/middleware.ts, src/lib/supabase/api-auth.ts, and the desk-card routes. Enumerate every Supabase/Postgres environment variable. The app may have more than the three environment variables previously swapped.
6. Step 6. Only after auth works, repair the config estate. Generated reseed script is recorded as 274 idempotent rows with original UUIDs and ON CONFLICT DO NOTHING. Execution status is unknown. Do not assume it ran. Do not blindly restore the 96 legacy stages without deciding whether historically inconsistent status vocabularies should be preserved; the August 30 audit had already identified that legacy mess.
7. Step 7. Re-close with a real live acceptance tape. End state is browser session, API, current estate, operator flow, deployment SHA, production health, acceptance receipt, with all numbers recorded. Built, merged, and deployed are not equivalent to wired, live, and proven.

4. What was already built and proven

The archive is unusually strong. The problem is that it is indexed as a library of artifacts instead of operated as one evidence graph.

5. The canonical receipt map: where the evidence actually lives

Four distinct custody layers. Treating them as one has caused the exact confusion now being repaired.

6. Core receipts that must be treated as canonical anchors

Explorer: filter by status, search by ID or name, click a row for detail. Statuses are copied from the source.

Critical distinction: a receipt mentioned by another artifact is not the same as a receipt currently located, hashed, and reconciled to the exact source commit. The September 8 cutover material names the final receipt path and required fields, but the evidence available here does not prove that the final P15 artifact was actually closed. That must be treated as OPEN until verified.

7. Why the system felt like it "lost everything"

The product could display a confident founder/session shell while the server-side authenticated data path was dead. That mismatch must be made explicit rather than averaged away.

8. What not to do

• Do not rerun the base schema.
• Do not blindly replay all Supabase migrations.
• Do not use supabase db push against the established target as a panic button.
• Do not clone legacy wholesale merely because the UI is blank.
• Do not delete the legacy project, legacy storage, or old worktrees while recovery evidence is still being reconciled.
• Do not treat an HTTP 401 on /api/* as proof that a particular route exists; the middleware can blanket-401 unknown paths.
• Do not treat a prerendered page or cached shell as session proof.
• Do not reseed config tables until the status-vocabulary defect is explicitly decided.
• Do not reopen the already-killed hypotheses about grants, RLS, tenant drift, anon key, or missing estate views unless new contradictory evidence appears.
• Do not call the final cutover green until the browser-level acceptance tape, exact production SHA, and final receipt agree.

9. The actual continuity failure we need to fix

The archive already anticipated this problem. The canonical hard-document binder says architecture is not runtime proof, recommends one canonical evidence directory and one writer per repository, and warns that generated/Notion artifacts were sometimes counted as products. The provenance timeline calls for an artifact ledger with date, source, SHA/hash, claim supported, and evidence class.

So the remediation is not another document. It is a custody system that makes every important claim traceable to one primary receipt.

10. Canonical evidence spine to establish now

11. Acceptance model for the repaired DeedSonar

Set each gate. The summary counts PASS, BLOCKED, and UNKNOWN. A gate is not passed by a database-only query where the source requires live route or browser evidence.

12. Canonical archive inventory already found

SOURCE CLAIM [S3]: The 60-day canonical index records 303 named artifacts from June 24 through August 24 and explicitly states that the index is semantic/canonical rather than a claim that only 303 files exist. It directs the operator to run a local manifest command for literal file links.

• 2026-07-19: EVIDENCE_CHAIN_OF_CUSTODY.json; 05_CANONICAL_SHA_MATRIX.json; 30_FINAL_VERDICT.md; DeedSonar CRM fidelity delta audit.
• 2026-07-20: Neuruh Test and Verification Ledger; APG punch list; readiness snapshot.
• 2026-07-21: DeedSonar P0/P1 Launch Package; Launch Control Package; P0/P1 Master Index; Decision Register.
• 2026-07-23: DeedSonar emergency/demo/rescue binders, final-convergence prompt, custody starting point, evidence index, SHA ancestry, final verdict, controlled production cutover.
• 2026-07-24: NEURUH_COMPLETE_HANDOFF_DOSSIER, chat-thread handoff, strict operating laws, master continuity handoff, AXON emergence and built-not-wired packs.
• 2026-07-28 to 07-31: Complete real-estate/ecosystem codex, artifact suite, PDF library, architecture atlas, founder master codex, DeedSonar operating bible, impossible-gap analysis, continuity truth map, hard-document binder, artifact-control plane.
• 2026-08-05 to 08-07: live operator-loop mission, visual proof suite, UAT pack, production release closure, NC canonical import estate.
• 2026-08-09 to 08-14: checksum policy/verification, final runtime report, master status, terminal stop-point/CodeX handoffs, canonical convergence stamps, finish timeline, repo inventory, DeedSonar finishing command center and browser acceptance.
• 2026-08-16 to 08-23: final convergence, founder/system assessment, Level-5 master dossier, signal/knowledge dossier, public launch master dossier, Master Control Hub, control-plane codices, agentic economy launch kit, master new-chat handoffs, seven-lane recovery, super-detailed thread handoff, thread status ledger, OSS handoff, Grok workspace bundle.

13. Where the canonical receipts are right now

• Library: Strongest historical hard receipts are directly retrievable by name and were used in this dossier, including Aug 7 production closure, Aug 16 convergence, Aug 21 Master Control Hub, Aug 26 launch-readiness/corrected-truth records, Sep 8 provenance timeline, and canonical artifact indexes.
• Local Git/worktrees: Local checkout ~/neuruh-repos/NeuruhAI/deedsonar; cutover receipts were read from a cutover worktree under ~/neuruh-worktrees/deedsonar-pro-cutover-20260907. Those local receipt files are the primary source for exact cutover gate evidence until current Git custody is reverified.
• GitHub: NeuruhAI/deedsonar is private and was explicitly not readable from the chat-side tool in the Sep 10 handoff. Current GitHub state is not something this dossier should invent.
• Vercel: DeedSonar project is on the anchorpointpg team. Chat-side Vercel grant was documented as returning 403, so runtime logs still require founder-side dashboard access.
• Supabase: Legacy lvdimujkfheeyqchjzra is reachable via chat-side service-role SQL; Pro efxowqudmsfqjmbeidjc is reachable from the founder Mac. That access asymmetry is itself a canonical custody fact.
• Storage: September 10 handoff says 288 objects across 2 buckets are live/reachable on legacy and should be extracted before deletion. This should become an explicit storage receipt rather than an oral memory.

14. Canonicalization corrections we should make to the archive

• Assign every primary receipt a stable ID and a SHA256. Do not make the filename itself the identity.
• Store the exact source commit, branch, environment, operator/tool, timestamp, and authority level with every receipt.
• Separate DOCUMENTED, CONFIGURED, BOOTED, TESTED, LIVE, and RETIRED states.
• Keep historical failed receipts. They are evidence, not clutter. Regressions strengthen provenance.
• Cross-reference Notion, GitHub, local files, deployment logs, browser screenshots, and terminal receipts to the same receipt ID rather than copying the same narrative into multiple canons.
• When two receipts conflict, do not delete the old one. Mark the newer authority and preserve the contradiction.
• Use one current canonical state page that links to receipts; do not create a new "master" page every time continuity breaks.
• Close the September 10 incident with a dedicated incident receipt whose final field is "canonical state after repair" so the archive records the repair itself, not just the failure.

15. Reconstructed timeline: what the evidence supports

Explorer: filter by evidence class.

16. Bottom line

You do not have an empty history. You have an evidence distribution problem plus a current auth/runtime incident. The evidence already proves substantial work: a production DeedSonar release, canonical data estate, operator/control architecture, public/common governance primitives, receipt infrastructure, canonical timelines, and a multi-month chain of handoffs and audits.

The immediate repair is narrow: get a fresh Pro session working, prove the protected API path, then repair the separate config-table debt, then re-run the end-to-end operator court, and finally seal one current receipt containing the exact live numbers, SHA, auth mapping, deployment, and known debt.

The strategic repair is larger but equally concrete: make the canonical receipt registry the operating spine of Neuruh. The goal is that six months from now nobody has to ask "where was the proof?" The system should answer with a receipt ID, source hash, location, authority, observed result, and current canonical interpretation.

Appendix A. Source map used for this dossier

Appendix B. Exact next command set

1. Browser: Incognito, app.deedsonar.com, login, record whether cards populate.
2. Browser: DevTools, Network, Fetch/XHR, reload, capture the first protected /api/* response status/body.
3. On Mac, from the local repo: inspect middleware, api-auth, desk-card routes, and grep every process.env.* SUPABASE/POSTGRES reference.
4. Pro DB: compare auth.users vs auth.identities vs email identities/password/confirmation counts.
5. Only after A1-A4 pass: run config census and decide whether legacy status vocabulary is to be restored, normalized, or intentionally left gated.
6. Run the full bounded operator acceptance court.
7. Write one incident-closure receipt with: incident ID, root cause, before/after, exact SHA, Vercel deployment, Supabase refs, auth mapping, acceptance statuses, config debt, rollback status, and canonical-state revision.

Appendix C. Canonical laws to carry forward

• MERGED != WIRED
• DEPLOYED != POINTED
• A receipt with no numbers is not a receipt.
• PUBLIC != THE DATABASE
• A policy count is not an RLS state.
• HOST-UNREACHABLE != ACCOUNT-UNREACHABLE
• A COMPLETE RECEIPT OVER A PARTIAL DENOMINATOR IS A FALSE GREEN
• A PRERENDERED SHELL IS NOT PROOF OF A VALID SESSION
• A BLANKET-401 MIDDLEWARE MEANS 401 IS NOT EVIDENCE OF A ROUTE
• UNKNOWN is a valid state. Never convert it to zero because the UI wants a number.

Calculators: recompute the source math

All calculators run locally in this page. No data leaves the browser. Hand-checked values are listed under each result.

Sample loaders

Three samples load the calculators, gates, and completeness fields together. Sample 1 is the September 10 incident as filed. Sample 2 is the August 7 release closure. Sample 3 isolates the config debt.

Completeness meter: incident-closure receipt

Appendix B step 7 lists the fields a closure receipt must contain. Fill them to raise the meter. Empty fields are listed as missing. UNKNOWN is a valid entry; a blank field is not.

Share link

The share link encodes the current parity inputs, gate statuses, and completeness fields into the URL hash as base64 JSON. Opening the link restores them.

Try-it walkthrough

Walk the remediation order in the demo. Each step names the evidence it produces.

How it works / What this is not

Honest gaps

All figures on this page are source claims from the September 10, 2026 dossier unless the text says the page computed them from those filed numbers. Computed values are labeled hand-checked in the calculator cards.

Related sites

Neuruh Hub is the master map for Neuruh builds. Sibling context: DeedSonar is the flagship real-estate CRM and lead app; Lead Recipe OS is the signal-to-opportunity kernel; LANDOS is the land signal engine. This demo does not link to private repos, live Supabase projects, or the Vercel dashboard, because those require founder-side access.