DeedSonar Forensic System Dossier

Document control

This edition reconciles the August release dossiers, the September DeedSonar/Neuruh control material, current Notion canon, and the current GitHub main branch through the merge of PR #83. Where evidence is older than the current code or production target, it is labeled historical rather than silently promoted to present truth.

Headline figures (source claims)

Arithmetic check done on this page: 20,734 NC + 1,609 MI = 22,343. 21,582 mapped + 761 unmapped = 22,343. Both reconcile exactly.

Executive ruling

The important change is not cosmetic. The project has moved through several distinct classes of engineering problem, and each class left behind a reusable control law. The initial product problem was "make the CRM useful." The actual engineering problem became "make a multi-source opportunity system tell the truth, remain reproducible, preserve authority boundaries, and survive real production data and runtime constraints."

• The August release proved the foundational CRM/product release discipline: source custody, authenticated UAT, migration replay, RLS/grants, Vercel deployment, and an explicit production cutover path.
• The September convergence work transformed the read path from an expensive wide scan into a canonical one-pass result-set seam, then built identity, signal fusion, recipe membership, qualification, next-best-evidence, demand matching, contact intelligence and data-estate custody around that seam.
• The system now treats UNKNOWN as a first-class epistemic state. Missing evidence is not silently converted into false, zero, current, callable, clear, or authorized.
• The system distinguishes property identity, person identity, ownership, legal authority, contact evidence, DNC state, consent, and action authority rather than collapsing them into a single "lead" concept.
• The production database authority moved from legacy lvdimujkfheeyqchjzra to canonical target efxowqudmsfqjmbeidjc; the legacy project remains forensic/parity reference, not a write target.
• The latest main branch is 06cbb841... after PR #83. That does not by itself prove that every recently merged migration has been applied to production. Merge state, deployment state, and database-apply state are tracked separately in this dossier.

What this dossier deliberately does not claim

• It does not claim all 30 recipes are live. The recovered catalog is 30; the live/runnable status is a smaller subset and has changed as the implementation matured.
• It does not claim every recently merged migration is already in the production ledger. Several production mutations remain founder-gated by design.
• It does not claim automated calling/SMS is enabled merely because phone evidence exists. The current architecture explicitly separates phone presence, contact resolution, DNC, consent and action authority.
• It does not claim the outcome-learning loop is empirically closed. The architecture exists; verified economic outcome data must still feed calibration.

Evidence source: Notion Chapter 07 capability-topology correction and Chapter 16 recipe maturity; GitHub PRs #60, #61, #69, #71, #73, #74, #82, #83.

2. Product definition: what DeedSonar actually is

2.1 Product stack

2.3 Entry modes

Evidence source: Notion Chapter 07, 2026-09-07 capability-topology correction.

3. Canonical evolution timeline

3.1 The August release dossier in context

The August 7 release dossier established the first hard baseline: source qualification, canonical Git custody, migration reconstruction and a production deployment route. It also codified the idea that the product is stronger than a working interface when the database, code, deployment and evidence all agree.

Evidence source: DeedSonar Release Closure Dossier 2026-08-07, pages 1-3: 95/95 test files, 638/638 tests, fresh Next.js build, migration reconstruction through 110, canonical Git root, staged Vercel deploy. All counts are source claims.

3.2 The 120 Willow case changed the product specification

The 120 Willow work was not just client work. It was the clearest proof that the operator needed a single property case preserving evidence, title, authority, contact, underwriting, outreach and economics rather than a chain of disconnected scripts and files. The Master Control Hub lists the resulting evidence corpus: an 87-page underwriting dossier, a 54-row evidence ledger, 22 source families, a relationship graph, kinship ledger, bridge matrix, contact-resolution analysis, source-exhaustion matrix and outreach sequence. All counts are source claims.

Evidence source: DeedSonar Master Control Hub 2026-08-21, pages 1-3.

4. System architecture

4.2 The principal state machine

4.3 Canonical invariants

• PROPERTY IDENTITY != PERSON IDENTITY != OWNERSHIP INTEREST != LEGAL AUTHORITY != FAMILY RELATIONSHIP.
• PHONE PRESENT != CONTACT RESOLVED != DNC CLEAR != CALLABLE != AUTHORIZED.
• UNKNOWN != FALSE; UNKNOWN != ZERO; READ FAILED != EMPTY.
• PRIMARY RECIPE != COMPLETE OPPORTUNITY TRUTH. Many-to-many membership preserves overlap.
• PROXY != FULLY RUNNABLE. Partial evidence is labeled rather than disguised.
• FORECAST ECONOMICS != REALIZED ECONOMICS.
• BUILT != LIVE. MERGED != APPLIED. DEPLOYED != DATA-CLOSED.
• SOURCE ATTEMPT != SOURCE EXHAUSTION. A transient failure cannot manufacture a permanent conclusion.
• EXPORT READY != EXPORT DELIVERABLE unless the actual artifact can be produced and read.
• A permission refusal is not a zero-result read.

5. The read-spine breakthrough

The read path is one of the clearest examples of capital-grade engineering inside the project. The system was not merely "slow." It was structurally performing broad work multiple times because the result-set predicate was duplicated and wide JSON documents were repeatedly decompressed.

5.1 What was happening

• Find Sellers could scan the full 22,343-row estate twice for a 100-row page.
• A lateral JSON extraction path decompressed wide normalized documents repeatedly.
• recipe_engine was a larger secondary document and could impose another large detoast cost.
• Exports walked page-by-page, effectively re-running the estate predicate for each page.
• Vercel and Postgres timeouts made wall-clock performance look intermittent because cache warmth changed the same block-heavy query cost.

5.2 The fix

PR #41 introduced deedsonar_result_set_membership_v1 as the canonical skinny predicate. Counts, facets, map points, total, page ids and related result-set surfaces could derive from a single membership pass. Wide row hydration then occurred by primary key only for visible rows. The identity projection further moved the nine frequently accessed scalar fields out of TOASTed JSON.

Evidence source: GitHub PR #41 summary; DeedSonar Master Control Hub acceptance matrix.

6. Data estate and identity

6.1 Estate scale

The estate is not one homogeneous data set. It contains ranking receipts, candidate projections, source rows, property/facts projections, CRM links, contact evidence, recipe memberships, watches, saved intent, and multiple temporal stamps. The architecture therefore treats the "estate" as a set of coordinated projections rather than one magic table. Counts are source claims.

6.2 Canonical identity

PR #63 establishes one opportunity identity seam based on the existing landos-ingest property key. The core identity is {FIPS}|P|{APN} with conservative address fallbacks. The resolver refuses to merge when the evidence establishes different counties/properties and holds uncertain cases instead of guessing.

On the real NC curative import, the identity court produced 20,734 opportunities with 0 false merges, 0 splits, and 0 unknown/conflict in that measured run. The court also exposed 481 Wake tax ACCOUNT ids incorrectly being used as parcel ids and placeholder situs values that could have caused vacant-lot merges. All counts are source claims.

Evidence source: GitHub PR #63.

6.3 Source custody and estate receipts

PR #66 repaired the custody seam for the data-estate. Previously the stage append did not hash stored payloads and seal produced only a counts hash that was not stored as the batch head. The new custody model records raw and normalized payload hashes and produces a chained sealed receipt whose digest binds source row ids, payload digests and class. An already-sealed estate can be backfilled with a receipt without rewriting its rows.

6.4 Temporal truth: facts-as-of

PR #70 and #75 address a subtle but important distinction: a source observation date is not the same thing as the ingest date, batch creation date or processing date. Earlier code substituted a write clock when the source facts date was absent. That made "freshness" look newer than the evidence really was. The corrected model preserves NULL/UNKNOWN when the facts date is not source-observed, and the UI explicitly reports partial coverage.

Evidence source: GitHub PRs #70, #75, #76, #79, #81.

7. Signal fusion and the Opportunity Genome

The signal-fusion work is where multiple upstream producer systems stopped being a pile of specialized facts and became a canonical evidence vocabulary that downstream opportunity logic can consume.

7.1 Ten recovered source families

VALUATIONPARCELDEED_TENURECODE_VACANCYHAZARDTAX_YEARS_THRESHOLDPARCEL_GRAPHPROBATE_DEPTHESTATE_SALE_JOINTAX_SALE_CALENDAR

The fusion layer maps heterogeneous producer shapes onto the existing SignalObservation / registry / ledger semantics. Each fused signal has an explicit outcome: KNOWN, UNKNOWN or CONFLICTED.

7.2 Merge policy

The fusion court over the Aug-27 NC raw import produced 20,734 fused properties, 0 unplaced, 0 unmapped, and reproduced the seven materialized recipe partitions exactly. The downstream recipe engine accepted 20,734/20,734 exported eligibility contexts. All counts are source claims.

7.3 Important semantic corrections

• Tax-balance equity is an equity ceiling when mortgage is unknown. It cannot satisfy an equity threshold merely because the computed ceiling is large.
• The nc_dps:vacancy_or_code source is one disjunctive fact, not vacancy AND code.
• A corpus-scoped empty neighbor list is UNKNOWN rather than proof of isolation.
• A county-level hazard join does not supply a parcel-specific flood/storm fact.
• Estate-form party names are not automatically converted into property signals.
• primary_recipe is a projection/facet, not evidence.
• An open tax foreclosure case implies delinquency only when no stronger tax source has spoken.

Evidence source: GitHub PR #64.

8. Recipe Engine: 30 opportunity strategies

The Sep-8 recipe recovery established a more ambitious truth than the old product exposed. There are 30 canonical strategies in the recovered catalog, but the catalog should not be confused with 30 live runnable filters.

8.1 Maturity, not marketing

Flag: the maturity counts sum to 74 (3 + 10 + 33 + 8 + 15 + 5), which exceeds both the 30-recipe catalog and the 46-entry live registry. The source does not reconcile this overlap on the page. Treat the classes as overlapping registry-level counts, not as a partition of the 30 recipes. See the Duplication and gaps section.

Evidence source: Notion Chapter 16 recipe recovery and GitHub PR #57.

9. Candidate-to-recipe membership

PR #52 created the normalized candidate_recipe_membership seam; PR #57 added the bounded writer for the engine-provided many-to-many memberships. The writer preserves the engine's primary membership, imports independently proven secondary memberships, and refuses to manufacture overlaps.

Arithmetic check done on this page: 20,738 + 641 + 148 = 21,527. Reconciles exactly.

This many-to-many layer is not merely an analytics convenience. It is necessary to avoid throwing away business context. One property can be simultaneously an heirship case, fractional title case, curative case, absentee opportunity and tax-distress case, each with a different research path and economics.

10. Qualification: evidence before label

The qualification seam is intentionally separate from ranking and contactability. It converts evidence and membership into an explicit stage, but it does not manufacture authority or contact readiness.

• QUALIFIED requires all five gates to pass.
• CANDIDATE means sourced membership exists but another gate is open.
• OPPORTUNITY is the "there is an opportunity-shaped signal but not enough sourced recipe proof" state.
• UNKNOWN is reserved for failed/unrun membership reads rather than zero-result reads.
• Qualification never consumes phone, DNC, consent, CRM or UI state as evidence.

10.1 A real defect exposed by the tape

The Sep-13 customer tape found that data_estate_revise_v1 could change candidate_class without changing recommended_action. The live check caught the mismatch, and the full 1,000-row chunk rolled back. PR #83 fixes the producer so a class change derives and records the corresponding action transition. This is a strong example of the system catching a semantic inconsistency in production rather than allowing a silent state split.

Evidence source: GitHub PR #83.

11. Next Best Evidence: the research optimizer

The NBE layer converts an opportunity's open facts into a ranked research plan. It is pure, deterministic and receipt-producing. It does not contact a seller, make an offer or underwrite merely because a source is available.

11.1 Core rules

• UNKNOWN is never false.
• Disagreement is CONFLICT, not latest-wins.
• Each live recipe membership is evaluated independently.
• Paid sources are held behind spend approval.
• Operator-only sources remain explicitly operator-only.
• A free route remains preferred over an unpriced or paid route when it can settle the same question.
• A source failure is not equivalent to zero results.

11.2 Production projection observed (source claims)

Arithmetic check done on this page: 19,227 + 1,505 + 2 = 20,734. Reconciles exactly.

Evidence source: GitHub PR #62.

12. Contact intelligence: from evidence to authorized action

The contact ladder is one of the most important governance innovations in the system because ordinary lead software collapses these states into a single field. DeedSonar treats each rung as independent and fails closed when a rung cannot be read.

PR #71 adds a persisted action-authority ledger with owner_admin/tenant_admin authorization for positive grants, desk-seat denial/revocation, a basis tied to the relationship class, attestation and a maximum 180-day expiry. It explicitly does not turn the dialer on. The architecture therefore allows a future action cutover without weakening the evidence model.

Evidence source: GitHub PR #71.

12.1 941 high-confidence phone evidence is not 941 callable leads

The export/convergence work proved that 941 current candidates had accepted phone evidence from party_phones under the product's strict rule. The same work kept callability and authorization separate. A phone can be valid evidence while DNC is unknown, consent is absent, or authority is not granted.

Flag: section 16 separately reports 947 live phone rows in Sep-11/12 evidence. The source does not merge 941 and 947 into one number; they are different read surfaces/counts. See Duplication and gaps.

13. Demand / buyer matching

PR #59 moves buyer matching earlier in the funnel. A property need not be under contract before the system can ask which buyers might want it.

This is a major commercial improvement because a customer can be told not only "this parcel looks interesting" but also "these buyer theses fit it, this is why, these facts remain unresolved, and these are the dimensions that determine disposition."

Evidence source: GitHub PR #59.

14. Saved searches, watches and export as operating infrastructure

The system treats saved intent and export artifacts as first-class state rather than UI conveniences. That required its own engineering work because long-running reads outgrew synchronous HTTP requests.

14.1 Async export architecture

• The export freezes the ordered membership once at job creation, so the exported set cannot drift while the job runs.
• Each batch becomes an independent storage object; progress advances only after an object lands.
• Transient failures retain RUNNING state and retry the same batch; fatal failures move to FAILED.
• Idempotency is enforced by tenant + idempotency key so double-clicks do not create duplicate jobs.
• The worker and cron advance the same function, so a closed browser tab does not kill a long export.
• The serializer is canonical and shared between synchronous and asynchronous paths, preventing semantic drift.

14.2 Why the project needed this

A measured full-estate CSV was approximately 114 MB. A naive full-estate path involved many long hydrations. The system therefore had to turn export into a durable workflow with bounded progress rather than pretending a large document was a "download button." Size is a source claim.

15. Security, RLS, authorization and migration custody

15.1 Security posture as architecture

• Tenant-scoped reads are the default product boundary.
• Sensitive writes use narrow SECURITY DEFINER functions rather than handing broad database power to application code.
• Anonymous/public execution is denied on internal identity overlays and control tables.
• Service-role paths are used only where job lifetime or operational custody requires them, with authority re-proven at read time where possible.
• A permission failure is surfaced as a permission/refusal state, not as zero records.
• Migration tooling was hardened to reject duplicate version numbers instead of allowing one timestamp to mask another migration.

15.2 Migration version collision was a real defect

PR #67 found three different migration bodies sharing the same 20260910120000 version. The old apply tool used ON CONFLICT (version) DO UPDATE, which could leave one ledger row while multiple schema mutations had actually occurred. The new guard refuses a different migration under an already recorded version and adds uniqueness tests. This is one of the most important "boring" discoveries in the project because it protects the integrity of the migration ledger itself.

Evidence source: GitHub PR #67.

15.3 Current production database authority

The migration program explicitly rejected a "copy the rows" shortcut. The target must reproduce the canonical migration chain, estate, facts overlays, identity, ranking/recipe state, contact/party graph, result-set predicates, saved-object state and RLS/grants. Otherwise the product could have identical rows and still be a different system.

Evidence source: GitHub PR #74; Notion Chapter 16 current target correction; Notion "Finish DeedSonar product/data convergence."

16. Current state as of 14 September 2026

This section uses the latest retrievable evidence, with a strict distinction between current GitHub main and live production facts observed on Sep-13. Where the current post-#83 production schema was not re-read after the merge in the available evidence, that is explicitly disclosed.

16.1 The current main branch is a living convergence artifact

PR #83 is an important marker because it shows the project is still doing semantic convergence, not cosmetic cleanup. A real production estate revision demoted one candidate while leaving its recommended action stale. The check caught it and caused the entire chunk to roll back. The code was then repaired and merged with a 17/17 local court plus 25/25 facts-as-of court. Counts are source claims.

17. Defect ledger: the discoveries that actually made the product stronger

Each defect became a system law, test, or architecture seam.

18. Proof system: how DeedSonar verifies itself

The project has evolved a layered proof model rather than relying on one giant test command.

The Sep-12 convergence proof harness reported 70 PASS / 0 FAIL on its tested production evidence set, with 73/73 Python unit tests in the convergence package and 2,292 Vitest tests passed at the corresponding head. This is strong infrastructure proof, but it should be read as "the harness passed its scope," not "every downstream production migration and workflow is closed forever." All counts are source claims.

Evidence source: GitHub PR #73.

19. What is truly innovative here

19.1 Opportunity Genome over lead records

Traditional lead systems store a record plus fields. DeedSonar increasingly stores a structured opportunity genome: property identity, ownership context, evidence, signal families, recipe memberships, ranking, open questions, contact state, demand and action authority. This lets one property participate in multiple economic theses without copying or mutating the underlying truth.

19.2 Information-gain research loop

Most "AI research" systems answer questions. DeedSonar adds a planning layer: which source visit should happen next, what fact will it settle, what is the expected information value, what is the cost/latency, and when should research stop? This turns research itself into an optimizable economic process.

19.3 Epistemic honesty as a first-class product primitive

The repeated treatment of UNKNOWN, CONFLICT, SOURCE_FAILED, PROXY and NOT_AUTHORIZED is not defensive UX. It makes the system composable because downstream automation can reason from uncertainty without guessing. The same rule appears in ranking, freshness, export, contactability, buyer demand and authority.

19.4 Authority is modeled, not implied

The architecture refuses the common shortcut "we found the owner, so we can contact them." It distinguishes identity, ownership, family relationship, legal authority, DNC, consent and action authorization. That makes the system more suitable for regulated or high-consequence workflows.

19.5 Custody-bound AI

The system increasingly binds decisions to receipts, hashes, source IDs, migration fingerprints and canonical JSON. The commercial value is reproducibility: another operator or machine can inspect not only the conclusion but the state of the evidence and the exact transformation that produced it.

19.6 Domain kernel rather than one vertical hard-code

The DeedSonar architecture was deliberately designed to be the first hardened vertical proof of a broader opportunity factory. The deeper kernel is "lawful signal environment to evidence substrate to identity to signal fusion to opportunity genome to recipe compiler to strategy/economics to information gain to qualification to governance to outcomes to attribution." A second vertical would be the decisive proof that this is a reusable kernel rather than a sophisticated property app.

Evidence source: Notion Chapter 16, Chapter 07; signal/recipe recovery material.

20. Commercial product surfaces

The internal architecture is too complex to sell directly. The public product should expose bounded outcomes while preserving the proprietary decision machinery underneath.

Price flag: the $100 Scan and $499 Dossier are source prices from this 14 Sep 2026 dossier. They are source claims, not current verified prices. Verify the current price list before quoting to a customer.

20.1 Why the product can command higher pricing

• It can attack the research cost, not only the data cost.
• It produces a decision file, not a CSV.
• It can recover cases that conventional lead systems abandon because the ownership/estate/title graph is messy.
• It can match opportunities to downstream buyer demand before contract, improving disposition economics.
• It can track source exhaustion and information gain, making repeated research increasingly systematic.
• The evidence/provenance architecture supports enterprise-grade review, partner handoff and future calibration.

21. Remaining gaps and risk register

These are the important remaining gaps visible in the retrieved evidence. They are not reasons to restart the architecture; they are closure items or deliberate product boundaries.

22. Exact next operating sequence

1. Re-prove current main == current Vercel production: exact SHA, health, authenticated route smoke.
2. Re-prove current efxo database custody: migration ledger, exact function bodies / fingerprints, latest data-estate revision migration state, action-authority objects and grants.
3. Run one live customer tape end-to-end: PROPERTY to IDENTITY to RECIPES to QUALIFICATION to NBE to RESEARCH WRITEBACK to CONTACT PROJECTION to AUTHORITY to DEMAND to ACQUISITION to RECEIPT.
4. Close the specific first-missing capability: do not restart architecture, do not create a second store, do not infer missing facts.
5. Package the paid front door: one Property Scan, one Intelligence Dossier, one custom deep-case offer.
6. Begin outcome receipts: prediction, action, cost/time, result, realized economics, calibration proposal.

Interactive forensic explorers

These tools run entirely in this page. Sample records are synthetic illustrations built from the dossier's published counts, not real property or owner data. Source figures are labeled source claims.

Appendix A. September convergence PR chronology

All entries are source claims from Appendix A. Use the PR explorer above to filter. PRs #51 and #53 are absent from the source chronology; that is a gap, not an omission by this page.

Appendix B. Primary evidence sources used

Appendix C. Terminology that must remain stable

Appendix D. Bottom-line investor / partner framing

The historical engineering record supports a stronger statement: the project has already demonstrated release engineering, high-scale read optimization, canonical property identity, multi-source evidence fusion, many-to-many opportunity membership, qualification, information-gain planning, buyer matching, contact-state governance, data custody receipts, and migration/cutover controls. The remaining challenge is to close the final production seams, repeatedly run the live workflow, and capture economic outcomes. That is a much smaller problem than inventing the machine from scratch.

What a commercial buyer is actually acquiring

A buyer is not acquiring a list of parcels. The defensible asset is a governed decision pipeline: data enters through controlled source paths, is normalized and reconciled to canonical property identity, is evaluated against multiple opportunity strategies, is ranked, researched, challenged, and progressively cleared for action. The same architecture can produce a one-property dossier, a county-scale acquisition hunt, a portfolio triage, or a custom intelligence workflow.

The product also reduces institutional memory loss. Source attempts, evidence, contradictions, facts-as-of dates, recipe memberships, authority decisions, export artifacts and research receipts become durable system state. A second operator can inspect why a decision exists without reconstructing the original researcher's terminal session or spreadsheet.

The next defensible moat is the outcome layer. Once predicted opportunity states, actual actions, costs, contacts, contracts, dispositions and realized economics are persisted, the system can calibrate which recipes, evidence routes and research actions actually produce profitable outcomes. That is where a sophisticated rules-and-evidence engine can become a compounding economic system rather than a static intelligence product.

Final assessment

DeedSonar has crossed the difficult architectural threshold. It is now possible to point to distinct, tested seams for identity, evidence, recipes, membership, qualification, research planning, contact governance, demand matching, export, custody and production convergence. The remaining work should be treated as a finite closure program with live receipts, not a mandate to redesign the organism.

The strongest immediate business move is to put the machine in front of customers through the bounded scan/dossier entry points, use the resulting work as the first live outcome data, and let actual paid cases determine which deeper capabilities deserve the next engineering dollar.

Duplication and gaps found in the source

These are plainly stated on the page, as required. Nothing here was silently reconciled or invented away.

How it works

1. Originate. A market hunt, a messy dataset, a known parcel, or a dead-end case enters the system.
2. Identify. The canonical {FIPS}|P|{APN} seam resolves property identity and refuses to merge on weak evidence.
3. Fuse. Ten source families normalize into canonical signals with KNOWN, UNKNOWN or CONFLICTED outcomes.
4. Match. The property is evaluated against 30 recipe strategies with many-to-many membership preserved.
5. Qualify. Five gates decide OPPORTUNITY, CANDIDATE or QUALIFIED. No gate consumes phone, DNC, consent or UI state.
6. Plan. Next Best Evidence ranks the next research visit by information gain, cost and access, preferring free routes.
7. Govern contact. The six-rung ladder separates phone presence from resolution, DNC, opt-out, consent and authority, and fails closed.
8. Match demand. Buyer boxes are evaluated before contract, with UNKNOWN kept distinct from NO_MATCH.
9. Act and receipt. Governed action is recorded with provenance; outcomes feed calibration once live transactions occur.

What this is not

• Not a CRM with property data. It is a governed opportunity operating system, and the dossier says so explicitly.
• Not 30 live recipes. Two were genuinely running at recovery; the rest are runnable, partial, proxy, blocked, contract-only, or unregistered.
• Not a dialer. Phone evidence is not callability, and the action-authority ledger explicitly does not turn the dialer on.
• Not a closed outcome loop. The architecture exists; verified economic outcomes are still missing.
• Not a current price list. The $100 Scan and $499 Dossier are 14 Sep 2026 source prices; verify before quoting.
• Not a live system demo. This page is a faithful transcription and explorer of a dated dossier. It does not connect to DeedSonar, Supabase, or any production database.
• Not investment advice. All figures are source claims from the dossier, not independently verified facts.

Related real-estate modules

• Real Estate Agent hub
• Residential Underwriting Engine (sibling module; the dossier's underwriting route)
• E1 Land and Zoning Unlock (sibling module; land and development recipes)

Source document: DEEDSONAR_FORENSIC_SYSTEM_DOSSIER_2026-09-14.pdf. Transcription prepared 4 November 2026. Layout was not eyeballed in a real browser; that is an accepted limit of this build.