Neuruh - Document Control - Evidence Map - Not a new proposal

Canonical Receipt Index

DeedSonar / Neuruh. Historical product state, hash custody, canonical dossiers, evidence ledgers and recovery lineage. Evidence cut: 2026-09-10. Reconstructed from the saved Library artifacts and preserved terminal / custody records.

Source documentNEURUH_CANONICAL_RECEIPT_MASTER_INDEX_2026-09-10.pdf
Evidence cut2026-09-10
Pages in source10 pages
Named artifacts in 60-day index303 (source claim)
Rows in this explorer95
Hubneuruh-hub.pages.dev

1. Executive ruling and golden state

Source claim: The historical DeedSonar product state shown in the founder-supplied screenshots is directly represented in the surviving evidence corpus. The corpus contains the Find Sellers operating contract, Current Estate universe, recipe census / reconciliation, opportunity qualification, contact-resolution work, map identity courts, acquisition handoff tests, release / custody records, Git SHA ancestry, checksum receipts and the September cutover control rail.

The archive is distributed across formal dossiers, receipt files, release packs, workspace manifests, local worktree custody records, Git SHA proofs, terminal transcripts and visual acceptance evidence. The canonical 60-day index records 303 named artifacts and explicitly says it is not a literal inventory of every filesystem item.

22,343Current estate opportunities (source claim)
306Qualified (source claim)
6,442Seller identified, after T27B projection; later screenshot 6,467 (source claim)
940Contact found, after +3 stale-phone repair; interim 937 (source claim)
989Already in CRM (source claim)
0Ready to contact; discovery and outreach authorization are separate (source claim)

Recipe census: Current 22,343; sum(recipes) 22,343; RECONCILED; PRIMARY_RECIPE_ONLY (source claim). Operator flow: Find Sellers to candidate to Send to Acquisitions to CRM link to downstream workflow. Map: county / polygon navigation, parcel points and exact candidate / property identity parity (source claim).

Figure 1. Find Sellers funnel (source counts, evidence cut 2026-09-10) 22,343 Current estate 6,442 Seller identified 940 Contact found 306 Qualified 989 already in CRM. 0 ready to contact. Counts are source claims, not live counts verified by this demo.
Figure 1. The funnel is a projection of the historical board. Qualified (306) is not a subset shown in sequence in the source; the source lists the six counts as a state bar, not as a strict funnel order.

2. Receipt index explorer

Every receipt the source enumerates, grouped by the source's own families. Section 9 overlaps Sections 1 to 4: the same dossiers appear in both lists in the source. This explorer keeps both listings and flags the overlap instead of silently deduplicating it.

Showing 95 of 95 rows.

#FamilyDateArtifactRoleDetail / hash

3. Working calculators (math defined in the source)

All inputs default to the source counts. Change a value and the result recomputes. Rates are simple divisions of the source counts; they are not new claims about live performance.

Results

Qualified rate: 1.37%. Seller identified rate: 28.83%. Contact found of seller identified: 14.59%. CRM rate: 4.43%. Contact found of estate: 4.21%.

Reconciliation check

RECONCILED. Sum(recipes) 22,343 equals Current 22,343. Difference 0. Rule: PRIMARY_RECIPE_ONLY (source claim).

Change over time

Estate 20,734 to 22,343: +1,609 (+7.76%). Contact 937 to 940: +3 (+0.32%). Seller 6,409 to 6,442: +33; later screenshot 6,467: +25 more.

Figure 2. Reconciliation: Current = sum(recipes) Current estate 22,343 Sum(recipes) 22,343 Difference 0 - RECONCILED (source claim, PRIMARY_RECIPE_ONLY) This demo recomputes the arithmetic. It does not re-audit the underlying recipe census.
Figure 2. The source states the census reconciled. The calculator lets you test what happens if either input changes.

4. Completeness meter

Each explorer row is scored on five fields: date, artifact name, role, detail, and hash or location where the source gives one. A row is complete only when all five are present in the source text as extracted. Truncated names in Section 2 score as missing.

Completeness: 75% (356 of 475 fields present).

5. Custody, contradictions, and what the corpus establishes

Exact local custody locations recovered (Section 6, 13 locations)

These are Mac paths as recorded in the source. This demo does not access them and does not verify that the files still exist at those paths.

Critical receipt contradictions: preserve, do not erase (Section 7)

ItemForensic reading (source claim)
22,343 current estateStable late-stage current-estate universe across UI / data receipts.
306 qualifiedStable late-stage qualified count.
937 to 940 contact foundAug 20 state recorded 937; a later repair explicitly added three stale phone projections and states Contact Found became 940.
6,409 to 6,442 to later 6,467T27B superseded the 6,409 projection; founder screenshot later showed 6,467. Tie each to its exact snapshot.
20,734 to 22,34320,734 was the Aug 16 sealed Data Estate checkpoint; 22,343 is later Current Estate truth.
Early Sep target empty to later target populatedEarly cutover receipts recorded an access-blocked / new target state; later evidence shows populated Pro target. Both are valid time-scoped states.
Current UI = Not availableCurrent runtime failure does not overwrite historical Find Sellers proof.

What the receipt corpus establishes (Section 8, source claims)

Figure 3. Custody chain in the source Library artifact -> Manifest / SHA-256 -> Receipt file -> Release pack -> Cutover control rail Git SHA ancestry: baseline d0535863...; accepted branch 5fa21247... Checksum receipt: CHECKSUM_VERIFICATION.txt records OK for branch, SHA, tree map and final report. Superseded evidence is preserved, not rewritten (SUPERSEDED_EVIDENCE.md). Hashes in this demo are copied from the source PDF text. They were not re-hashed from the original files here.
Figure 3. The chain is the source's model of preservation. This demo reproduces the chain as an index; it does not re-verify any hash against a live file.

6. Try-it walkthrough

  1. Start with the golden state. Click "Load: Golden state board". The explorer filters to the Find Sellers family and the calculators reset to 22,343 / 306 / 6,442 / 940 / 989.
  2. Check the repair. Click "Load: T27B repair 937 to 940". Read the T27B operator receipt and the T29 contact-state repair rows. The delta calculator shows +3, +0.32%.
  3. Check the earlier checkpoint. Click "Load: Aug 16 checkpoint 20,734". Compare 20,734 with 22,343 in the delta calculator: +1,609, +7.76%.
  4. Test reconciliation. Change Sum of recipes to 22,342 and click Calculate rates. The reconciliation line changes to NOT RECONCILED with difference -1. Change it back to 22,343.
  5. Find a hash. Search "abbac41a" in the explorer. The master universe row shows the full SHA-256 from the source.
  6. Share your view. Set a filter or search, click "Copy share link", and open the link in a new tab. The same filter, search and calculator values restore from the URL hash.
  7. Check completeness. Scroll to Section 4. The missing-fields list names exactly what the source text did not supply, starting with the truncated Section 2 filenames.

7. Share link

Your current filter, search text, family, and calculator inputs are encoded in the URL hash as base64 JSON. No data leaves the page except the link you copy.

8. How it works / What this is not

How it works

  • The explorer holds 95 rows copied from the source PDF text: 12 + 10 + 14 + 12 + 10 + 13 + 24 across families 1, 2, 3, 4, 5, 6 and 9.
  • Search filters name, role and detail. Family filters by the source section number.
  • Calculators divide the counts you enter. Reconciliation subtracts Current from Sum(recipes).
  • Completeness scores five fields per row and lists every missing field by row.
  • Share encodes state as #d= base64 JSON and restores it on load.

What this is not

  • Not a live DeedSonar dashboard. The source says current UI is Not available.
  • Not a re-audit. Hashes are copied from the PDF, not recomputed from original files.
  • Not a literal filesystem inventory. The source says the 303-artifact index is not a literal inventory of every filesystem item.
  • Not proof that any count is still true today. Every count is labeled as a source claim tied to its snapshot date.
  • Not a new architecture proposal. The source states it is an evidence map.

9. Honest gaps

10. Sources and related sites

Source: NEURUH_CANONICAL_RECEIPT_MASTER_INDEX_2026-09-10.pdf, 10 pages, evidence cut 2026-09-10, produced with ReportLab PDF Library. No secrets or credential values are included in the source, and none are included here.

Related: Neuruh Hub (master map of Neuruh sites). Sibling receipt and provenance builds on the hub include the Neuruh provenance timeline and the Recipe system demo where listed. This page is a standalone demo; it does not fetch data from the hub or any sibling site.