DEV Community

Cover image for The Ledger Is the Loop: How One Record Carries a House Through Loan Origination, Deconstruction, and Construction
Salman Parvez
Salman Parvez

Posted on

The Ledger Is the Loop: How One Record Carries a House Through Loan Origination, Deconstruction, and Construction

ML Systems runs a three-stage value chain on a single house:

Loan Origination  →  Deconstruction  →  Construction  ────┐
   (Loan Pit)         (80–90% recovery)   (+10% SF, +1 level)
        ▲                                                 │
        └──────────── equity loop ────────────────────────┘
              the homeowner chooses to keep building
Enter fullscreen mode Exit fullscreen mode

The loop is client-driven. It is not an assumption that every homeowner loops; it is the observation that some will choose to, and the whole system is built to make that choice rational.

In the industry as it exists, those three stages are run by three different parties keeping three incompatible records. The lender has an appraisal and a title file. The demolition contractor has a dumpster count. The builder has a takeoff and a schedule. None of those records survive the handoff to the next party, and none of them survive the building. That is why the loop does not exist today: not because the economics fail, but because the record fails at every handoff.

This post is about the piece that fixes that — the Master Ledger — and what it does at each stage.


What the ledger is, in one paragraph

The Master Ledger is one auditable record per home, written by many authors: the homeowner, the town assessor record (VGSI), seven AI agents, ML Systems staff, and the Custodian. It stores claims, not facts. Every entry carries its source, an evidence grade (MEASURED > STATED > RECORD > MODELED), and a verification state. Authority is scoped by domain — the assessor is authoritative on legal and valuation facts, vision on the visible envelope, the homeowner on intent and recent work — and evidence ordering applies within a domain, not across the record. Verification is multiverification: the homeowner and the Custodian stamp independently, neither overrides the other, and every stamp is bound to the content it signed by an entryHash, so an edited claim lapses its stamps automatically.

I wrote up the reconciliation design in Claims, Not Facts. This post is about what that record does once a house starts moving.


Stage 1 — Loan Origination: what the Loan Pit underwrites against

Node 1 of the value chain is the Loan Pit: a reverse-auction marketplace where lenders and capital-market participants compete to fund the homeowner. A homeowner alone has weak leverage with capital markets. In the pit the relationship is inverted — lenders bid to originate the loan, the homeowner reaches capital they could not reach alone, and ML Systems keeps the relationship and the data. (MODELED. Regulatory compliance is the active workstream; licensing, disclosure, and state lending rules gate what ships.)

A reverse auction needs something to bid against, and a folder of PDFs is not it. What the lenders see is the HomeGenome: the ledger compressed into the smallest complete description from which the full home can be reconstructed. The compression reconciles conflicting claims into resolved states, grounds each fact in real primitives (member specs, not adjectives), ranks by evidence grade, and emits the genome per (property, cycle).

The point for underwriting is not that the description is compact. It is that every number in it can be traced back to a claim with a source, a grade, and a stamp. A lender does not have to trust the description; they can inspect how each entry got its standing.

Where the RCM fits: the Reversed Conventional Mortgage is parked. The calculator and tooling still exist as app features, but Node 1 is the Loan Pit and the loop no longer depends on it.


Stage 2 — Deconstruction: where the material intelligence is generated

The existing structure is taken apart, not demolished, so its materials survive.

REAPER reads the ledger's assembly stack and produces the reverse takeoff: a full bill of materials for what is in the building, routed by RRR — Reuse › Resale › Recycle. Full resale is not possible, so each recovered material is broken down to its most valuable recoverable state. Reuse beats resale beats recycle. (51% resale is a soft goal — a direction, not a metric the system enforces.)

Every recovered member becomes a new claim on the ledger: identified, quantified, valued. Two things happen to that inventory at once. It becomes a salvage bank, which secures financing, and it becomes a marketplace feed, which is the surface MIA — the market-intelligence mind — reflects real demand back into. The same record that the lender underwrote against in Stage 1 is now the record of what came out of the building in Stage 2, with the evidence grade upgraded: a member that was RECORD from the assessor or MODELED from a takeoff becomes MEASURED the moment it is on a pallet.

Labels on this stage, stated plainly:

  • 80–90% material recovery — MODELED, a target.
  • 2-day crane sequence — ASPIRATIONAL. No ML Systems deconstruction has been performed yet.

Stage 3 — Construction: the build is scheduled from the compressed sequence

Recovered materials rebuild the home — larger than before. The modeled cycle is +10% square footage and +1 level. CDA, the design plan-stack swarm, lays modeled rooms into the real measured wings and floors; MURPHY schedules the rebuild from the compressed sequence — milestones, per-phase construction order, the minimum-viable-estimate schedule, and the tracker that watches for what can go wrong.

The number that comes out of this stage is the one most likely to draw scrutiny, so here is how it is derived rather than asserted:

Baseline RI home:      $500,000  ·  2,000 SF  ·  2 levels (1,000 SF/floor)
After one cycle:       +10% footprint (1,000 → 1,100 SF)  +  1 added level
New total SF:          1,100 SF × 3 floors = 3,300 SF
Floors 1–2 value:      2,200 SF × $250/SF = $550,000
Floor 3 (60%):         1,100 SF × $150/SF = $165,000
New property value:    $715,000

CONSTRUCTION_VALUE_MULTIPLIER = 715,000 / 500,000 = 1.43×   (MODELED)
Enter fullscreen mode Exit fullscreen mode

Value is created by physical improvement, not market timing. The multiplier is calibrated from a real local-competitor proforma plus the ML Systems construction model. It is MODELED: the math is real; it has not been proven in the field, because no cycle has completed. The label is the point.


The loop: why the record has to persist per (property, cycle)

Cycle 1 is one house on a new foundation — Rhode Island housing stock sits on ~1960s foundations that are often the limiting factor. Later cycles expand on that same first home.

Compounded at 1.43× from a $500k baseline:

$500k → $715k → $1,022k → $1,461k → $2,089k → $2,988k   (5 cycles, MODELED)
Enter fullscreen mode Exit fullscreen mode

That compounding only exists if Cycle N+1 can underwrite against the verified record of Cycle N. Which means the ledger cannot be a project file that gets archived when the job closes. It is persisted per (property, cycle), and the equity created in Cycle N is not a market-appreciation estimate — it is the set of construction claims from Cycle N, stamped, with their evidence grade at MEASURED, that becomes the baseline description the Loan Pit compresses for Cycle N+1.

This is also where multiverification matters operationally rather than philosophically. Stage handoffs are exactly where records get silently edited in the industry today — a number changes between the appraisal and the takeoff and nobody can say who changed it or when. In the ledger, a changed number lapses every stamp on it. The Custodian's oversight console derives a review queue across every home — quarantined › lapsed › unverified › awaiting-stamp › unstamped › stamped — so the lapse is surfaced, not discovered at closing.


The exhaust is the product

Every home that passes through the value chain produces a fully specified, ground-truth construction sequence — the exact order, materials, and member specs of a real build. That data is the input to the Collective Ontology and, ultimately, to ontology licensing for robotics: training data nobody else has, because nobody else deconstructs and rebuilds the same home across cycles.

It is only worth licensing because of the ledger. A construction sequence whose every member carries a source, a grade, and converging independent verifications is ground truth. One that does not is a spreadsheet.


Where this actually is

Same labels, applied to the company:

MEASURED. The mobile app is approved and live on iOS and Android, with a no-login web preview at try.mlsystemsri.com. The Master Ledger is real: record-first UI, multiverification, lapsing signatures bound to content hashes, and the Custodian oversight console. Ontological compression runs on-device at intake. VERA's intelligence stack is live against free public data — VGSI harvest, facade vision from StreetView, satellite, and homeowner photos, sketch reconciliation, FEMA flood zones, Census tracts, RIGIS. The Loan Pit exists in-app: live-bid loan cards, a real partner-lender directory, and financing lanes.

MODELED. 80–90% recovery. The 1.43× multiplier. Loan Pit economics and reverse-auction mechanics. Unit economics from a real local-competitor proforma — ~16% gross margin baseline, modeled path to ~23% via origination plus recovery.

ASPIRATIONAL. The 2-day crane sequence. Humanoid Tier-1/Tier-2 labor, excluded from every financial scenario. Growth targets.

What is next is the first real loop: the founder is preparing to run Cycle 1 on his own property as homeowner #1. Until that cycle completes, every recovery and value figure above stays MODELED, and the docs will keep saying so.


Full public reference — the Value Chain, the Master Ledger, the Collective Ontology, Ontological Compression, and the Seven Minds — is open at github.com/MLSystemsRI/ml-systems-public. The proprietary engine is not in it. The concepts are.

ML Systems — Rhode Island construction (NAICS 236115). Tougher Problems Inspire Creative Solutions.

Top comments (0)