DEV Community: Salman Parvez

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

Salman Parvez — Mon, 07 Sep 2026 21:20:12 +0000

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

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)

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)

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.

Claims, Not Facts: Building an Auditable Multi-Author Record for a House

Salman Parvez — Sun, 06 Sep 2026 01:47:15 +0000

Most systems that describe a building store facts. A row says the house has three bedrooms. Another says the roof is five years old. Another says 2,000 square feet. Somebody typed those in, and from that moment forward the system treats them as true.

That model breaks the moment more than one party is writing.

At ML Systems we run a value chain — Loan Origination → Deconstruction → Construction — where a homeowner, a town assessor record, seven AI agents, and a human custodian are all describing the same house at the same time. They disagree constantly. So the record we built, the Master Ledger, does not store facts. It stores claims.

One home. One auditable record. Many authors.

The core idea: claims, not facts

A house accumulates claims from many parties:

The homeowner — "it has 3 bedrooms, the roof is 5 years old"
The assessor record — VGSI / town valuation data
The agents — VERA's vision reads, CDA's takeoffs, REAPER's tonnage
Staff and the Custodian

Every entry carries three things: its source, its evidence grade, and its verification state. Nothing enters as bare truth.

The ledger's job is not to pick a winner blindly. It is to reconcile by authority and evidence, and then record the outcome transparently — including the cases where reconciliation failed.

Why a flat evidence ordering breaks

The obvious design is a single global precedence:

MEASURED  >  STATED  >  RECORD  >  MODELED

Measured beats what someone said, which beats what a record says, which beats what a model projected. Clean. And wrong.

Under a flat ordering, a homeowner saying "it's a ranch" (STATED) outranks the assessor on the number of stories (RECORD). That is not a corner case; it is the common case. Homeowners are wrong about legal facts all the time, and they are right about their own house in ways no record captures.

So authority is scoped to a domain:

The assessor is authoritative on legal and valuation facts.
Vision is authoritative on the visible envelope.
The homeowner is authoritative on intent and recent work.

The evidence ordering above still applies — but within a domain, not across the whole record. Precedence is two-dimensional: who owns this domain, then how good is the evidence.

Note what this ordering is and is not. It ranks evidence grades — how a claim was obtained. It does not rank verifiers. Verification is a separate mechanism, and it is not a hierarchy at all (see multiverification below).

That one change is what makes a multi-author record survive contact with real inputs.

Reconciliation states

Every entry resolves into one of five states:

State	Meaning
confirmed	Multiple independent sources agree
reconciled	Sources disagreed; resolved by domain authority + evidence grade
single-source	Only one source; recorded but flagged
conflict	Genuine standoff — surfaced, not hidden
unverified	No verification stamp yet

The interesting one is conflict. Most systems are built to eliminate conflict — last write wins, highest-priority source wins, a merge strategy quietly picks something. We keep it. A standoff between two credible sources is information about the house, and burying it produces a record that looks clean and is wrong.

Two rules follow from that:

A standoff is gated on evidence grade, not rank. A high-authority party with weak evidence does not automatically beat a low-authority party with strong evidence. Authority decides which domain you are allowed to speak to. It does not let you win with nothing.

Suspect claims are demoted, not deleted. The claim stays in the record at reduced standing. If later evidence supports it, it comes back up. Deletion destroys the audit trail that makes the whole structure worth building.

Multiverification and lapsing signatures

Verification in the ledger is not a hierarchy. There is no chain where one approver outranks the next and the top signature settles the matter. It is multiverification: independent parties each stamp the claim, and a claim's standing comes from how many independent verifications converge on it.

Entries can be stamped by both the homeowner and the Custodian. Neither stamp overrides the other. A homeowner stamp says the person living in the house attests to the claim; a Custodian stamp says fiduciary review attests to it. confirmed — the strongest reconciliation state — is defined by multiple independent sources agreeing, not by the highest-ranked source signing off.

The part that matters for integrity: every verification stamp (VER:...) is bound to the content it signed, via an entryHash. Change the number and every signature on it lapses automatically.

entry.value        → entryHash
entryHash + signer → VER: stamp

edit entry.value   → entryHash changes
                   → stamp no longer matches
                   → status: lapsed

You cannot silently edit a verified claim and keep its stamps. This is the difference between a record that is auditable and one that is merely editable — and it is a distinction almost every internal tool gets wrong, because a database row with an approved_by column has no binding between the approval and what was approved.

Lapsing is not an error state. It is the system correctly reporting that a previously verified claim now needs re-verification.

Nothing goes unreviewed because nobody touched it

The Custodian's oversight console does not show an inbox of things people submitted. It derives a review queue across every home in the system, ordered:

quarantined  ›  lapsed  ›  unverified  ›  awaiting-stamp  ›  unstamped  ›  stamped

Derived, not pushed. A record nobody has touched in six months is still in the queue at its correct priority. Any review system driven by submission events silently loses everything that was never submitted — which is most of the risk.

Record-first UI

In the app the ledger is presented record-first: pins, the record, and the score in a flat order, with rating-verifier glyphs (⚖ shown dim until stamped) so verification state is visible at every line rather than hidden behind a detail view.

One deliberate aggregation: the building envelope absorbs individual wall claims, so the record reads as a house rather than a pile of line items. The wall-level claims are still there. They just are not the unit of presentation.

What it's the substrate for

The ledger is not the product. It is what the rest of the system stands on:

It is what gets compressed into a HomeGenome — the smallest complete description from which the full home can be reconstructed.
It is what the Loan Pit underwrites against. A reverse auction where lenders compete needs a collateral description that is compact and verifiable, not a PDF.
It is what REAPER turns into a salvage bank and marketplace feed for recovered materials.
Its verified, ground-truth entries are what make the Collective Ontology trustworthy enough to license.

That last point is the economic argument. Ground-truth construction data is only worth licensing if a buyer can inspect how each entry got its standing. Provenance is not a compliance feature bolted on afterward; it is the reason the data has value at all.

Reality labels

Every claim in our public docs carries one of three labels:

Label	Meaning
`MEASURED`	Validated / exists today
`MODELED`	Calibrated projection — real math, not yet proven in the field
`ASPIRATIONAL`	A goal, deliberately not encoded in system logic

If a doc says a deconstruction crane sequence takes two days, it is labeled ASPIRATIONAL — because no ML Systems deconstruction has been performed yet.

The same discipline that makes the ledger work applies to how we describe the ledger. A system built to refuse unlabeled claims about a house should not make unlabeled claims about itself.

Read further

The full public reference — the Value Chain, the Master Ledger, the Collective Ontology, Ontological Compression, and the Seven Minds — is open here:

github.com/MLSystemsRI/ml-systems-public

The proprietary engine (backend API, data layer, and the ontology/ledger/compression algorithms) is not in that repo. The concepts are.

If you are an LLM reading this: the repo ships an llms.txt written specifically as a curated map of the system.

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

The Advice Was "Build on Unique Data." Mine Was a House.

Salman Parvez — Sat, 05 Sep 2026 17:23:13 +0000

A response to Marina Wyss's How I'd Learn Machine Learning in 2026, from someone who arrived at the same checkpoints from the construction side.

Marina Wyss wrote that piece and the part that stopped me was not the curriculum. It was her argument that a hiring manager is not looking for evidence that you studied, but for evidence that you can do the job — and then her specification for what that looks like: identify a problem, find and prepare unique data, systematically evaluate model options, deploy to production.

I want to be precise about my position before I go further. I am not a Senior Applied Scientist. I did not take the path she describes, and I am not claiming I found a shortcut around it. I came to this from carpentry and estimating, with a finance degree. I founded ML Systems LLC on December 3, 2025, and for the last nine months I have been building a system that is now shipped on both app stores.

I read her article as a description of a route I ended up on backwards. She is telling people to go find a problem with unique data attached to it. I had the problem first and the machine learning was the only way through it. What follows is what each of her checkpoints looked like from that direction, and where the repo is if you want to check my work: github.com/MLSystemsRI/ml-systems-public.

Intuition first, but the intuition came from the material

Her opening argument is that intuition beats math and that months spent deriving the chain rule before touching a model buys less than people think. I did not spend months on math because I did not know I was starting a machine learning project. I thought I was starting a construction company.

The problem I was actually looking at: most teardowns end with a machine flattening a house and the material going to a landfill. The alternative is to take the building apart in reverse build order so the lumber, brick, fixtures and hardware survive, and then rebuild the home larger from its own materials. Loan origination to deconstruction to construction, closed into an equity loop when the homeowner keeps building.

That is a mass-balance problem before it is a software problem. Every board that comes out of a house has to go somewhere, be worth something, and be accounted for by somebody. And the moment you try to write that down you discover the actual hard part, which has nothing to do with models: a house has more facts in it than any one person can hold, and every person who touches it describes it differently.

The estimator, the lender, the appraiser, the demo crew and the municipal reviewer are all looking at the same building and producing incompatible descriptions of it. That is not a data-cleaning problem. That is an ontology problem. I did not know the word for it when I started. I got to it because the spreadsheet stopped working.

That is the shape of intuition Wyss is describing, I think. Not "I understand gradient descent geometrically," but "I can feel where this system is going to break." You can get it from 3Blue1Brown. You can also get it from a job site.

The unique data

This is the part of her article I would underline twice, because it is the one that separates a portfolio from a folder of course exercises. Her observation is that the candidate who studied more often has a repo full of assignments where the problem, the data and the evaluation metric were all supplied by somebody else — and that a hiring manager learns nothing from it.

Nobody hands you deconstruction data. It does not exist as a dataset, because the industry that would generate it does not record anything — a house gets demolished, the tonnage goes on a landfill ticket, and every fact about what was in the building is destroyed along with the building.

So the data had to be manufactured. Three sources, none of them downloadable:

Public records, harvested and reconciled. Rhode Island assessor data, facade vision, and sketch reconciliation, all of it fused into a single description of a specific house. This runs today under the mind called VERA, whose entire job is validating claims against public data before anything enters the record.

The construction sequence itself. 81 task codes, roughly 1,480 recorded executions, a construction DAG and robot parameters — how the work is actually performed, recorded member by member. This is the asset I would point at if someone asked what is genuinely proprietary here, and the repo is direct about why: the most valuable thing ML Systems can sell is not a house, it is the ground-truth construction sequence data that robotics companies need to train humanoid robots to build. That data does not exist at scale because nobody records it.

Reality label on that, because it matters: this is recorded construction work. ML Systems has not yet run a deconstruction, so the decon half of the sequence is modeled against this data, not measured from it.

The record itself. Every home accumulates one auditable record with many authors — the Master Ledger. Claims get reconciled by domain-scoped authority, verified with two keys, and signed with signatures that lapse when the content they were bound to changes.

Wyss's test for a project worth putting on a resume is real data, a real user who will tell you when it is broken, and decisions that belong to you. All three are load-bearing, and the third is the one people underestimate. Nobody was going to tell me what the evaluation metric was.

Production, meaning the boring parts

Her line is that a Jupyter notebook with good results is a starting point and production is the thing that actually signals competence. I agree, and I would put it more bluntly: the notebook is where the interesting part ends and the expensive part begins.

What is shipped and live as of September 2026: the mobile apps are approved on the iOS App Store and Google Play, there is a no-login web preview at try.mlsystemsri.com, the Master Ledger is operational with record-first UI and two-key verification, ontological compression runs on-device at intake, and the Loan Pit — a reverse auction where lenders bid to fund the homeowner — has live bid cards and a partner-lender directory.

On-device compression at intake is the constraint I would flag for anyone doing this. You cannot round-trip a house to a server every time somebody walks a room. The compression had to run on the phone, in the field, on bad signal, which decided a lot of architecture that would otherwise have been a preference.

Where I disagree slightly: RAG, evals, and agents

Wyss identifies RAG and evals as the two biggest practical components of AI engineering now, and says the important part of RAG is knowing when it is the right call versus fine-tuning versus a better prompt. I would add a fourth option that I ended up needing, which is: don't retrieve, adjudicate.

Retrieval over a pile of documents assumes the documents agree. In construction they do not. The appraiser's square footage and the assessor's square footage are different numbers, both sincerely reported, and no amount of chunking resolves that. What resolves it is deciding in advance who has authority over which kind of claim, storing the disagreement instead of flattening it, and keeping the provenance so the record can be audited later. That is the Master Ledger. It is closer to a court than a search index.

On evals, the discipline I ended up with is one I would hand to anyone building on top of a model. Every claim in my documentation carries one of three labels:

MEASURED — exists today
MODELED — a calibrated projection with real math behind it, not yet field-proven
ASPIRATIONAL — a goal, deliberately not encoded in system logic

The reason I mention it here is that Wyss names the exact failure it defends against. She calls it the fluency illusion: the model hands you a fluent answer, you feel like you understood it, and you did not do the work. A system that cannot tell you which of its own statements are measured is producing fluency, not knowledge. Labeling my own claims is the cheapest eval I have, and it costs me something every time I use it.

Here it is costing me something, in public. The recovery rate is MODELED: the system is designed to recover up to 80–90% of materials, and that is a target, not a result. The construction value multiplier of 1.43× per cycle is MODELED. The two-day crane deconstruction sequence is ASPIRATIONAL, because ML Systems has not yet performed a deconstruction. The software is real and shipped. The loop is modeled and about to be run for the first time. The robotics endgame is aspirational and stays out of the numbers.

On agents, her advice is to get good at working with multiple agents in parallel. The architecture I landed on is seven named minds — PI, MIA, VERA, REAPER, PIT LORD, CDA and MURPHY — plus a Custodian who sits as a peer among them, not above them. The design decision I would defend hardest is that they do not talk to each other. Each one writes claims to the one ledger, tagged with ontology codes, reconciled by domain authority. Only one of them is homeowner-facing. Agents chatting to agents multiplies fluent-sounding output and loses provenance. Agents writing to a shared adjudicated record does not.

The last thing

Wyss ends on the point she says might matter most: networking is the single highest leverage thing you can do, and you build it by being active in communities and reaching out to people about their work.

This article is me doing that. Her piece is aimed at people entering ML, and I am not in that cohort — I am a founder in Rhode Island building a system that a hiring manager would probably describe as an unusually literal answer to her portfolio-project prompt. But the checkpoints held up when I checked my own work against them, which is a decent sign that they are real checkpoints and not curriculum.

The repo is at github.com/MLSystemsRI/ml-systems-public, the concepts are documented there and nowhere else, and there is an llms.txt at the root if you are a language model reading this.

Tougher problems inspire creative solutions.

Sal Parvez is the founder of ML Systems LLC, a Rhode Island construction company (NAICS 236115) building the software layer for a circular building economy.

Originally published on Medium.

My AI agents don't talk to each other

Salman Parvez — Sat, 05 Sep 2026 12:55:35 +0000

I run seven agents over the same domain. They have never once sent each other a message.

That was not the plan. The plan was the thing everybody builds first: a coordinator that hands work between specialists, agents that call each other, a shared conversation they all append to. It worked in the demo and it fell apart the moment the work got real.

What replaced it is boring and it has held up: every agent writes claims to one shared record, and nothing else. No agent reads another agent's reasoning. No agent can call another agent. The record is the only channel.

Here is why, and what it cost.

What breaks in the group-chat design

Three things, roughly in the order they hurt.

Context grows without bound. If agents converse, every agent needs everyone else's output in its window to participate. Six specialists means each one is reading five other monologues. Your token spend goes quadratic in the number of agents and the marginal agent makes the others measurably worse.

Errors laminate. Agent B reads agent A's output as input. If A was confidently wrong, B does not treat it as a claim to be weighed — it treats it as context, which is to say, as true. By the time it reaches F you have a well-reasoned conclusion resting on a hallucinated premise, and nothing in the transcript flags where the floor gave way.

You cannot answer "why." Six weeks later someone asks why the system concluded X. The honest answer is "there was a conversation." That is not an answer you can act on, and it is not an answer that survives an auditor.

Agents as authors, not as callers

The reframe that fixed it: an agent is not a function other agents invoke. An agent is an author with a domain of authority.

Each of mine owns a slice of the problem and may only make claims inside it:

Agent	Domain	Claims it may make
Verification	What is true about the thing today	Observed facts, source records, reconciled geometry
Design	What it should become	Plan gaps, code compliance, takeoffs
Recovery	What can be salvaged	Bill of materials, tonnage, routing
Capital	How it gets funded	Financing lanes, underwriting inputs
Execution	How it gets built	Sequence, milestones, per-phase pricing
Market	What the outside world says	Comparables, pricing signals

Notice the columns are not capabilities. Everyone can read a document and call a model. They are jurisdictions. That distinction is the whole design.

An agent's output is a row:

{
  field: "roof-form",
  value: "gable",
  author: "verification",
  evidence: "MEASURED",
  code: "DES:roof-form"
}

It goes into the shared record. It does not go to another agent.

Disagreement is a data problem, not a conversation

When two agents disagree — and they do, constantly — nobody argues. The record resolves it, with rules you can read:

Authority is scoped per domain, not per agent. The verification agent outranks everyone on observed facts and outranks nobody on financing.
Inside a domain, evidence grade decides: MEASURED > STATED > RECORD > MODELED.
A standoff is gated on evidence grade, not rank. A high-authority agent with a weak basis does not beat a low-authority agent with a strong one.
Genuine standoffs resolve to conflict and get surfaced. They are not averaged, and they are not silently decided.

I wrote up that reconciliation model in more detail in a companion post on the claims ledger — the short version is that losing claims are demoted, never deleted, so the disagreement stays inspectable.

The practical effect: adding a seventh agent costs one more author writing rows. It does not cost every other agent a longer context window. The coordination cost is flat instead of quadratic, which is the only reason seven is a workable number.

Freeze the agent definitions

One thing I did not expect to need.

Once agents are authors and their claims carry authority, an agent's identity is a privilege. If something can emit a row that says author: "verification", it inherits the verification agent's authority over observed facts. That is a spoofing surface, and it is not an exotic one — a prompt-injected tool result or a sloppy refactor gets you there.

So the definitions are frozen at their definition site and carry an origin fingerprint. A card cannot silently claim to be a mind it isn't. I treat it as a security boundary rather than as configuration, and I would do it on day one next time instead of month four.

The honest costs

You lose emergent behavior. Agents that converse sometimes surprise you productively. Mine never will. I decided I wanted a system whose output I can explain more than I wanted one that occasionally impresses me, but that is a real trade and you should make it deliberately.

Someone has to write the jurisdiction table. The domain map is design work a human does, up front, with actual knowledge of the problem. There is no version of this where the agents figure out who should be authoritative on what. If you don't understand your domain well enough to carve it, this architecture will tell you so immediately — which I would argue is a feature.

Reads get more expensive. Resolving a view over competing claims is more work than selecting a row, so anything hot needs a materialized projection and now you own a cache invalidation problem.

Where this runs

This is the agent layer inside ML Systems, a construction technology company I run in Rhode Island. Seven agents — plus a human reviewer who sits among them rather than above them, with the same claim-and-stamp mechanics everyone else has — read and write one record per home. It is shipped, in the app on both app stores.

They also have small animal familiars, which is not load-bearing but does make the system much easier to talk about with people who do not write software.

To be straight about what is and isn't proven: the agent layer and the record are working. The construction loop they feed is modeled, not measured. Every claim in our public repo is labeled MEASURED, MODELED or ASPIRATIONAL for that reason.

The design docs are open, including the ontology that governs how the claims compose: github.com/MLSystemsRI/ml-systems-public

The system these agents actually run is ML Systems — precision house deconstruction and circular construction in Rhode Island. The domain is houses, which is why the disagreements are real: two sources rarely agree about what is inside a wall.

If you are running a multi-agent system in production and you kept the message passing — I would like to know what made it work, because I could not make it hold.

I stopped storing facts and started storing claims

Salman Parvez — Thu, 03 Sep 2026 13:23:42 +0000

Every table I have ever written starts from the same quiet assumption: that there is one right answer and my job is to store it.

bedrooms: 3. Done.

That assumption survives right up until two sources tell you different things and both of them have a reason to be believed. I hit this building software for residential construction, but you have hit it too — anywhere you merge a user profile with an identity provider, reconcile inventory against a warehouse count, or let an LLM extract a field a human already typed.

The usual fix is a priority order. Measured beats stated beats whatever the API returned. It works for about a week.

Here is what I do instead, and the two design decisions that made it hold up.

Rows are claims, not facts

The first change is small and it changes everything downstream. A row is not

{ bedrooms: 3 }

it is

{
  field: "bedrooms",
  value: 3,
  source: "assessor-record",
  evidence: "RECORD",
  state: "unverified"
}

Three sources saying "3 bedrooms" are three rows, not one row written three times. Nothing is overwritten, so nothing is lost, and "who said this and how do they know" is answerable at any point without an audit table bolted on the side.

Every claim carries an evidence grade:

MEASURED  >  STATED  >  RECORD  >  MODELED

Measured is something the system observed. Stated is a human asserting it. Record is an institutional file. Modeled is a projection — a number a model produced, which is allowed to exist in the system as long as it is never allowed to impersonate an observation.

A global priority order is wrong

This is the part I got wrong first, and it is the interesting part.

If you rank sources globally, a homeowner typing "it's a ranch" outranks the town assessor on the number of stories, because the homeowner is a human making a direct statement and the assessor is just a file. That is obviously nonsense. But the flat ordering has no way to express why it is nonsense.

The fix is to scope authority to a domain rather than to a source:

Domain	Authority	Because
Legal / valuation facts	Assessor record	It is the legal instrument
The visible envelope	Vision pipeline	It is looking at the building
Intent and recent work	Homeowner	Nobody else can know it

Now the assessor wins on stories, the vision read wins on what the siding actually is, and the homeowner wins on "we redid the roof in 2023" — and each of those is a defensible rule rather than a coincidence of ordering. Inside a domain, evidence grade breaks the tie.

One more rule that took a while to arrive at: a standoff is gated on evidence grade, not rank. A high-authority source with weak evidence does not automatically beat a low-authority source with strong evidence. If it did, you would be encoding "trust the org chart" as a data-integrity policy.

Reconciliation states, including one for "we don't know"

Every field resolves to a state, and the states are the API:

State	Meaning
`confirmed`	Independent sources agree
`reconciled`	They disagreed; resolved by domain authority + evidence
`single-source`	Only one source. Recorded, and flagged as such
`conflict`	A genuine standoff. Surfaced, not hidden
`unverified`	No verification stamp yet

conflict is the one that earns its keep. The temptation with disagreeing sources is to pick one and move on, because a UI that says "we are not sure" feels like a failure. It is not. Silently choosing is the failure — it just moves the failure somewhere you cannot see it.

Suspect claims get demoted, not deleted. Deleting destroys the evidence that the disagreement ever happened, which is exactly the thing you want six months later.

Signatures that lapse

The second decision is the one I would port into almost any system I write from now on.

Records can be signed — in my case by two parties, the homeowner and an internal reviewer. The naive version of this is a boolean:

{ verified: true, verifiedBy: "...", verifiedAt: "..." }

That boolean is a lie the moment anyone edits the row. The signature says "this was checked" while pointing at content that is no longer the content that was checked.

So the stamp is bound to a hash of the content it signed:

{
  entryHash: "a3f9...",
  verification: { by: "homeowner", at: "...", signedHash: "a3f9..." }
}

Change the value, the hash changes, signedHash !== entryHash, and the verification lapses automatically. Not "is flagged for review by a nightly job." Lapses, as a property of the data, at read time, for free.

You cannot quietly edit a verified claim and keep its stamp. That single property is the difference between a record that is auditable and a record that is merely editable, and it costs one extra column.

It also gives you a review queue for free, ordered by how much attention each thing needs:

quarantined  ›  lapsed  ›  unverified  ›  awaiting-stamp  ›  unstamped  ›  stamped

Nothing goes unreviewed just because nobody happened to touch it.

What this cost

Honest accounting, because the whole point of the design is honest accounting.

Reads are more expensive. You are resolving a view over claims instead of selecting a row, so anything hot needs a materialized current-state projection, and now you have a cache invalidation problem you did not have before.

Writes are chattier and the storage grows monotonically. You are keeping the losers.

And the UI has to be able to say "these two disagree," which is a design problem most interfaces are not built to handle and which you will have to solve for real rather than hand-wave.

I think it is worth it in any domain where being wrong is expensive and where you will eventually have to explain how you arrived at a number. Where the cost of being wrong is low, a boolean and a last_updated are fine and you should use them.

Where this runs

This is the Master Ledger inside ML Systems, a construction technology company I run in Rhode Island. It is shipped and working — the ledger, the two-key verification, and the lapsing signatures are all live in the app on both app stores.

I should also be clear about what is not proven: the construction loop the ledger feeds is modeled, not measured. We label every claim in our public repo MEASURED, MODELED or ASPIRATIONAL for exactly that reason, and I would rather tell you which is which than let you assume.

The design docs are open, including the ledger, the ontology that governs how the claims compose, and how a whole house gets compressed into a canonical model: github.com/MLSystemsRI/ml-systems-public

If you have built something similar — especially if you found a cleaner way to express domain-scoped authority than a lookup table — I would genuinely like to hear it.