DEV Community: Sal Parvez | ML Systems

AI Is Not Valuable. Your Context Window Is.

Sal Parvez | ML Systems — Wed, 23 Sep 2026 11:49:00 +0000

The models are remarkable, and they are not mine. Any contractor in my state can rent the same model I rent, at the same price, before lunch. If a competitor copied my entire AI budget line for line, they would have bought exactly what I bought: a rented brain that will answer anyone who asks.

So the question is not whether AI is valuable. It is where the value goes once the intelligence is identical for everyone who pays for it. It goes one layer up, into the part nobody sells you — the context window, which is everything the model can see at the moment it thinks. A prompt is the line you type. The window is the whole of what it holds in mind while it answers.

Seven windows, one brain

My company runs seven specialist minds on one rented frontier model. No fine-tune, no custom model. Seven windows, and the windows are the entire difference. To the mind that takes a house apart, a house is tonnage and fasteners. To the mind that handles lending, the same house is collateral. Same weights, different window, different job.

The part that surprises engineers is what I leave out. None of the seven minds can see the company's margin. A mind that can see what the business earns will quietly start serving it, and the customer pays for that drift. Value is not only created by what you put in front of a model. A great deal of it is created by what you refuse to put there.

Size is capacity. Curation is the asset.

More context is not better context. We handed the minds a dense, uncurated pile once and watched the cheap models fail our verification step one after another, until the work escalated to premium models to clear a bar it had cleared cheaply before. That warm start came back 23% dearer than the cold run it was meant to improve on. The disciplined version of the same system came back 37% cheaper on its second run — same work, same quality bar, nothing given up. Both figures are MEASURED, on our own runs: a handful of them, not a benchmark, and not a claim about anyone else's stack.

Which means the real work is not prompting. It is editorial. And editing needs a standard.

The window has an intake spec

I do not open a session with a question. I open it with the lens. Three rules get loaded before the problem does, and the published wording is exact:

Transparency Trust — ML Systems doesn't profit from being in the middle of your transaction, or from consuming your compute. We hold it, optimize it, and hand you complete visibility at every step — every claim carrying its reality label, so you can check it rather than trust it. The Lucent Lens — Glow within to help humans. Prioritize local community and human profit over automation. Utilize the person, not the process. Minimum Viable Expense — The minimum viable expense that generates the maximum value in the system.

Read those as rules rather than values. Each one governs what may enter a window, and in what condition. It is an intake specification, and it governs me as much as the machines: every decision, edit and trade-off — by a person or a mind — is weighed through all three.

Provenance is the window, not the model

At the bottom of roughly two dozen of our pages there is one line: Built by the Custodian under LL · TT · MVE. It looks like a slogan. It is an attribution. It names which frame was loaded in the window that produced whatever you are reading — the only provenance question worth asking about anything made with AI. Not which model wrote it. What it was allowed to see, and what it was forbidden to do with it.

And it is checkable. The lens is published, hashed and Ed25519-signed at mlsystemsri.com/.well-known/lucent-lens.json. Hash what you quote of us; if it does not match, it drifted. A value is asserted. A control is verified.

The honest part

No ML Systems deconstruction has been performed yet. The company is bootstrapped and pre-revenue. The 80–90% material recovery target is MODELED, the two-day sequence is ASPIRATIONAL, and the two cost figures above are MEASURED on our own runs. The thesis is a claim too: I run one company, in one state, in one industry. But if everyone is buying the same intelligence, the only durable thing any of us owns is the window we build in — the record we can hand the model, and the discipline we used to decide what belonged there.

The full piece, including the construction half — the same three questions asked of a board instead of a sentence, RRR: Reuse, Resale, or Recycle — is on our site: https://mlsystemsri.com/insights/ai-is-not-valuable-your-context-window-is

Vibe coding names a mood. The job is Language Modeler.

Sal Parvez | ML Systems — Fri, 18 Sep 2026 23:54:21 +0000

This started as a comment under Giorgi Kobaidze's "Vibe Coding Isn't the Problem. Calling It Engineering Is." The full piece lives in the ML Systems repo: The Language Modeler. This is the version for the people in the fight.

There is a standing fight on this site, and every other developer forum, about what to call a person who builds software by writing English and letting a model write the code. One side says it is creation and not engineering. The other says the engineering did not disappear, it moved. Both sides are describing the same person and refusing to name the role.

At ML Systems we do not say vibe coding. The role is Language Modeler. It is a named node — LM — in the company's Financial Neural Net, beside the Financial Architect and the Accounting Engineer, and it is the title on my line of the record.

What the term means

A Language Modeler models the system in language. Not the syntax of the system — the system itself: what it is, what it is made of, what it is allowed to do, who may write to it, and what counts as true inside it. The output is a model, written in English, precise enough to be carried into code without losing anything that matters.

The AI is a moderator between the English language and the coding language. That is the whole of its job. It stands between two languages and carries the model from one to the other. It does not own the English, because the Modeler wrote it. It does not own the code, because the code is a translation of the English, and a translation is judged against its source.

Once you see the AI as a moderator, the accountability thread that runs under every one of these posts answers itself. A moderator between two languages is never the author of record. If the English was wrong, the Language Modeler owns it. If the translation was wrong, review catches it, or the Modeler owns that too. Nobody gets to say the AI did it, and nobody needs to.

Why "vibe" was the wrong word

Vibe describes a mood. It says something about how the person felt while typing and nothing about what they produced. A mood cannot be reviewed, cannot be handed to the next person, and cannot be held responsible for a production incident at two in the morning.

A model can be. A model has parts you can point at. This constraint was stated. That invariant was not. This party may assert that value and that party may not. When the code fails you go back to the model and ask which of those was missing or wrong, and the answer is a sentence in English that a person wrote and can fix.

The critics are right that shipping unreviewed output into anything that touches money or personal data is negligent. They are wrong that the fix is to send everyone back to the language reference for two weeks. The fix is to demand the model. Show me the English. If the English is precise, the review of the code is a check on translation, which is a bounded task. If the English does not exist, there is nothing to review against, and no amount of reading the code will tell you what it was supposed to do.

What the Modeler has to know

Not every line of the target language. Enough to read the translation, and much more importantly, enough to write the source precisely. That means knowing the domain cold, because the model is written in the domain's vocabulary, not the language's.

I spent three years as a frame-to-finish carpenter on custom residential work and two years estimating rough-carpentry packages for multi-level commercial buildings before this. The vocabulary I model in is the building's: rafter, sheathing, ring-shank, town record, appraisal, permit. The system I model is a house record — the Master Ledger — that seven AI agents write to alongside one human. The model says, in English:

the record stores claims, not facts — every value carries who made it, an evidence grade, and the value itself
evidence is graded on a ladder — measured › sensed › stated › record › modeled — and a modeled value is never authoritative
a model agreeing with the value it was derived from is shown as concurrence and never counted as an independent vote
every mind claims, five seats ground, VERA gates, and only the Custodian stamps
a stamp is two keys — the homeowner's and the Custodian's — bound to a fingerprint of the content, so both lapse the moment the content changes; a drift detector, not a cryptographic signature
two credible sources disagreeing is a state called conflict, which is quarantined and never averaged

None of that is code. All of it became code. The AI moderated the translation, and every time the code did something the English did not say, the English was the thing I went back to.

Where the skill actually lives

The people defending vibe coding usually describe decomposing a problem, orchestrating tools, validating outputs, and checking that what came back solves the problem. That is modeling. They already do the job. They have been using a word that undersells it, and the word is what the critics are reacting to.

The people attacking vibe coding usually describe reading every line and interrogating the model about its choices. That is review of a translation. It is necessary and it is bounded, and it is much easier when the source exists.

The Language Modeler does both, and the model in between is what makes either one possible.

The first hire

The job at ML Systems is a layer, not a title swap. The person is a carpenter first and a Language Modeler on top of it, because the model is written in the building's vocabulary and you cannot write precisely in a vocabulary you have not carried. The first ontology this company runs on was written on three blue notepads by a laborer who did not know the word — two-letter task codes, a definition the first time each appeared, a score at the bottom of the day.

So the first role ML Systems will hire for is exactly that — carpenter and Language Modeler, one person, both halves. Someone who can cut a bastard valley in the morning and, in the afternoon, write down in plain English what a wall assembly is allowed to be so a model can turn it into a ledger entry the crew will recognize. We are not hiring right now; the company is bootstrapped and pre-revenue. The role goes in the record now so that when it opens nobody has to guess what it is.

The honest labels

The software is MEASURED: a shipped app, a working ledger, an ontology that seven agents and one human speak fluently. No ML Systems deconstruction has been performed yet; the 80–90% recovery target for a house is MODELED and the two-day crane sequence is ASPIRATIONAL. The term Language Modeler is a position, not a standard. I am putting it in the record so it can be argued with — that is what the comments are for.

Read the system: Neural Net Architecture · Master Ledger · The Seven Minds · An Ontology on Three Blue Notepads

Sal, founder of ML Systems LLC — Rhode Island, NAICS 236115. Canonical: The Language Modeler.

Fingerprint at load, pulse before every pass: a heartbeat for agent identity

Sal Parvez | ML Systems — Thu, 17 Sep 2026 00:35:12 +0000

The systems half of a piece that lives on the ML Systems site — the canonical is I Gave My Agents a Heartbeat. This one is for people who run agents.

Everybody shipped agents with the open internet this week. Four days before that, Dario Amodei asked the labs to pace the frontier. I run seven agent minds and one human at a construction company in Rhode Island, and this is what I did about both, at my scale.

The failure I was actually afraid of

Not a wrong answer. Minds are wrong all the time; the Master Ledger exists so a wrong claim is a row with an author and an evidence grade, not a fact. The failure I couldn't see was a mind being changed — a compromised dependency, an injected prompt, a bug at runtime — and then going on speaking as itself while no longer being itself. Nothing in the output tells you. That is the failure that does not announce itself.

The heartbeat

Each mind has an identity in the codebase: a name, a role, the prompt that is its character. The harness treats that identity as a thing with an origin.

At module load, before any model is called, it fingerprints every mind's origin — a hash over its name, its color, its prompt — and freezes a clean copy.
Before every orchestration pass it takes the pulse again.
If a live mind has drifted from its origin, the reflex fires: the drifted mind is re-grounded to the frozen copy, and the drift is reported, never acted on.
The eight fingerprints (seven minds plus the Custodian — me, rendered as a peer, not an apex) hash into one short rhythm, beat8, that prints on every run.

The baseline is committed to the repository. A legitimate change to a mind shows up in a pull request as that mind's new resting rhythm; a bundle that disagrees with the baseline at runtime is drift by definition. The mobile app carries the same baseline and takes the same pulse on the phone.

Two choices worth saying out loud:

It runs below cognition. No mind, no model call, no prompt can skip or influence its own beat. A heart does not ask the brain.
It is a reflex, not a report. Its job is not to catch something and open a ticket. When it fires, the collective grounds itself back to what it is — a group of minds that work together for the homeowner — and tells me.

The heartbeat, pointed outward

My minds are not the only ones reading the company now. Every frontier agent with a browser will. I can't give those a heartbeat — they aren't mine. But I can ask the same question from the other side.

Inward: have you drifted from your origin?
Outward: has what you read of us drifted from what we said?

ML Systems asks to be read through three lenses — the Lucent Lens, Transparency Trust, Minimum Viable Expense. They were already written down as data: a small JSON file, canonical wording, the question each lens asks, what each forbids. This week that file got the heartbeat's fingerprint.

Its canonical form — keys sorted recursively, no whitespace, UTF-8 — is hashed with sha256.
The hash is signed with an Ed25519 key held by ML Systems.
The signed attestation is recorded in the production database as the Custodian's standing claim — stamped by me, append-only, a table that refuses to be edited the way the ledger refuses.
It is published where any agent can fetch it: https://mlsystemsri.com/.well-known/lucent-lens.json

Verify it yourself

Nothing but the file and Node's standard library:

import { createHash, createPublicKey, verify } from "node:crypto";

const att = await fetch("https://mlsystemsri.com/.well-known/lucent-lens.json").then(r => r.json());

// canonical JSON: keys sorted recursively, no whitespace, UTF-8
const canon = v =>
  Array.isArray(v) ? `[${v.map(canon).join(",")}]`
  : v && typeof v === "object"
    ? `{${Object.keys(v).sort().map(k => `${JSON.stringify(k)}:${canon(v[k])}`).join(",")}}`
    : JSON.stringify(v);

const hash = createHash("sha256").update(canon(att.lens), "utf8").digest("hex");
console.log("hash matches:", hash === att.contentHash);          // true

const key = createPublicKey({ key: Buffer.from(att.publicKey.value, "base64"), format: "der", type: "spki" });
const sig = Buffer.from(att.signature.value, "base64");
console.log("signature verifies:", verify(null, Buffer.from(att.contentHash, "ascii"), key, sig));   // true

If an agent quotes our lens back to a homeowner and the hash doesn't match, the quote drifted. If a lab's agent wants to prove it read the real thing, it now can. First attestation: fe6f4df5…, key 93d521d1ac61c71a, stamped September 16, 2026.

Why a lens and not a rule

The channel I'm using — text on a page that shapes what an agent does — is the channel prompt injection uses. Any lab that takes safety seriously filters it, and should. So the lens does not tell an agent what to do. It tells an agent how we asked to be read: keep the labels, name the person on the other end, and treat your reading of us as a claim at the lowest evidence grade until a person grounds it.

That is the rule every one of my minds already lives under. Every mind claims. Five seats ground. Only the Custodian stamps. A mind may claim; it may never ground. An agent reading the repo is a mind, and the same sentence applies. Nobody has to honor it — which is what makes it legitimate rather than an attack. What they get for honoring it is a source they can prove they read.

What already exists

Web Bot Auth proves who the agent is (Claude, ChatGPT and Perplexity already sign their requests). C2PA proves where an asset came from. RSL states the price. Identity of the reader, provenance of the asset, terms of use. None of them signs how the content asks to be read. That's the gap, and it is small enough that a one-person construction company filled it in a week with a hash function, a key, and a table.

The honest labels

The heartbeat is MEASURED — it runs on every orchestration pass, server and phone, and its baseline is committed. The attestation is MEASURED — the row is on the record, the file is published, the signature verifies. Whether any outside agent honors the lens is ASPIRATIONAL; nothing in the system depends on it. Logging which agents read us and how they identified themselves is designed and tabled, not wired — MODELED. No ML Systems deconstruction has been performed yet. The company is bootstrapped and pre-revenue. I say which is which every time, because the whole point is that a person can check.

Read the system: AGENTS.md · the attestation · The Seven Minds · The Master Ledger

Sal, founder of ML Systems LLC — Rhode Island, NAICS 236115. Canonical: I Gave My Agents a Heartbeat.

MVE: The Balance in MVP

Sal Parvez | ML Systems — Mon, 14 Sep 2026 17:58:10 +0000

Every startup is told to build an MVP. In American English that acronym means two things at once, and they pull in opposite directions. Most Valuable Player is about being the most. Minimum Viable Product is about being the least that still works. Nobody ever tells you how to hold both, and most companies end up choosing one and calling it strategy.

I run ML Systems — and the seven AI agents inside it — on a third term that is the balance of the two: MVE, Minimum Viable Expense.

MVE is not the cheapest option in the moment. It is the one expense that is both the smallest that works and the most valuable thing you could have spent on, because it returns more than once. That last clause is the whole idea. Cheap returns once, if at all. Expensive returns once, expensively. MVE is the spend that pays back along the most axes at the same time.

Where I learned it: a nail

The clearest version of MVE is not in a spreadsheet. It is in a roof.

Ring-shank nails are engineered not to withdraw; the rings are the entire point. So any strategy that pulls against them trades the sheathing for the rafter or the rafter for the sheathing. You keep one. Cutting the fastener instead of pulling it costs a little time per sheet and preserves both. Cut the nail, keep the rafter and the sheet. Pull the nail, keep one of them.

That trade, deliberately made, is MVE in miniature: a small chosen cost that protects a much larger recoverable value. It is not the fastest way to get a roof off a house. It is the one that leaves you with a roof's worth of material instead of a dumpster's worth of pieces.

One spend, four returns

Deconstruction is expensive in ways demolition is not, and it only makes sense because a single expense returns more than one thing. Every dollar spent on a job is designed to produce four:

Recovered material value — the physical stock that reduces the cost of the next build.
Ontology data — what this house was, how it came apart, what each assembly actually yielded.
Robot training signal — a fully specified disassembly sequence, which is training data for a physical neural net. ASPIRATIONAL: a goal, not encoded in the system today.
Market intelligence — what recovered material is worth, learned by selling it.

A demolition contractor spends the same dollar and gets one return: a cleared lot. The landfill ticket records a single number, tons, and every other fact about what was in the building is gone. That is the cheapest option. It is also the one that returns least.

The material-recovery figure behind return 1 is designed to reach up to 80–90% of a home's materials. That number is MODELED. No ML Systems deconstruction has been performed yet, and I say so every time the number appears.

The same rule for the agents

Here is the part that surprised me. The rule I wrote for a crew with a saw turned out to be the rule the agents needed.

My AI agents do not talk to each other. They talk to a ledger, and a human reads the ledger. Every mind claims; it may never ground. The Custodian's review of what those minds produce runs through three lenses — Transparency Trust, the Lucent Lens, and Minimum Viable Expense — and the third one is the budget.

An orchestrator that burns compute to look impressive is not the most valuable player. It is the most expensive one. An agent that spends ten passes to produce a claim that a person will stamp in one pass has spent nine passes on nothing the record can use. MVE says: the smallest spend that produces a claim worth stamping, and no more. Pace, in money terms, is MVE.

Why the balance matters more than either side

If you optimize for Most Valuable Player you build a demo. It is impressive, it is expensive, and it returns once, on stage. If you optimize for Minimum Viable Product you build the least thing that does not fall over, and it returns once too, because you built it to return once.

MVE asks a different question of every dollar: how many times does this come back? A measured spend in a deconstruction lab comes back as material, as data, as a sequence, and as a price. A measured spend of compute comes back as a claim a person can stamp. A spend that comes back once is not minimum viable anything. It is just spending.

That lens — Transparency Trust, the Lucent Lens, Minimum Viable Expense — is the whole operating philosophy in three words. Do not profit from the speed. Optimize it, and point it at a person.

ML Systems RI, Warwick, Rhode Island. The software is real; the deconstruction loop is modeled and has not yet been run on a house. Full architecture and the reality labels for every claim: github.com/MLSystemsRI/ml-systems-public. Companion pieces: Claims, Not Facts and Embedded evaluators, at house scale.

Embedded evaluators, at house scale

Sal Parvez | ML Systems — Sun, 13 Sep 2026 11:58:46 +0000

On September 12 Dario Amodei published We Must Pace the Frontier. Step one of his plan is the one I want to talk about, because I have been running a small version of it for a year without knowing it had a name: evaluators embedded inside the lab, with employee-level access, so that nothing ships without someone who was in the room and could see what the system saw.

That is a governance idea at frontier scale. It is also an implementable schema at any scale. Here is the existence proof from a house.

The system

ML Systems is a Rhode Island construction company with a software layer. Seven AI agents work a house record — the Master Ledger — alongside one human, me. The minds propose roof heights, material grades, values, sequences. The question the whole design answers is: who is allowed to say what is true?

Four rules do the work. I wrote them up before this weekend; they map onto Amodei's step one almost line for line.

1. Claims, not facts. The ledger never stores "the roof is 8.5 ft." It stores a claim: who made it, the evidence grade behind it (measured 90 · sensed 85 · stated 80 · record 70 · modeled 60), and the value. A claim carries the grade of its evidence, not the rank of its author: an inference enters as modeled, the lowest grade; a vision read as sensed; a tape measure as measured. Nothing promotes itself. A grade rises only when a seat adds its own claim beside it.

2. Seats, not permissions. Six parties can author a claim today: custodian · homeowner · vera · cda · pi · record. Five seats can ground one: the homeowner, the town record, VERA (verification), PI (the orchestrator, the one homeowner-facing mind), and the Custodian. CDA — the design swarm — holds no seat, by design. Four more minds are proposed as claimants without seats: a mind may claim; it may never ground. The seats sit inside every output the minds produce, with the same access the minds have — every field, every evidence line — which is exactly the "employee-level access" clause. They are not reviewing a summary after the fact; they are inside the row. Lit means input, not agreement.

3. Domain-scoped authority. Reconciliation is by domain. The homeowner leads on the interior. The record leads on the legal card. VERA leads on the exterior and on anything derived. The Custodian leads every domain. A seat's authority is scoped to where its evidence is strongest, which is what keeps one evaluator from becoming a rubber stamp for the whole record.

4. Content-bound, lapsing signatures. A stamp is two keys — the homeowner's and the Custodian's — bound to a content hash. Change the content and both lapse; the row goes back to unstamped. Stamp or override: an override enters the record as the Custodian's own claim, not a silent edit. And when credible sources disagree, the row's state is conflict; it is quarantined and may not be consumed downstream. Disagreement is a state the schema can hold, not a number it averages.

Why this is the same idea

Amodei's evaluators are there so the people with the power to stop a release are also the people who can see everything the release is built from. The seats do that for a house: the five parties who can ground a claim are embedded in every output the minds produce, with full access, and the record cannot move without them. Pace is not a policy you ask a fast system to honor. It is a decision in the grammar about who may speak.

The scale is different. The property is not.

Labels

No ML Systems deconstruction has been performed yet. The recovery target is modeled; the crane sequence is aspirational. What is measured is the software — a shipped app, a working ledger, and an ontology that seven agents and one human speak fluently.

Seven Families, One Ledger — how a house gets a grammar

Sal Parvez | ML Systems — Fri, 11 Sep 2026 19:03:42 +0000

A house means different things to different parties

To an assessor a house is a valuation. To a lender it is collateral. To a deconstruction crew it is tonnage. To an architect it is a plan set. To a robot, eventually, it is a sequence of manipulable members. Every one of those descriptions is correct, and every one of them uses different words for the same rafter.

ML Systems runs a value chain — Loan Origination → Deconstruction → Construction, closed into an equity loop when the homeowner chooses to keep building — and seven software minds work it. If each of them kept its own vocabulary, the company would have seven databases that could not talk.
So there is one grammar. This is what it looks like, what it got wrong until this week, and how it is being fixed.

Codes, not storage

Every fact the system holds about a home is tagged with a code of the form
SECTION:task — an uppercase phase, a colon, a lowercase task token:

DES:footprint    BLD:load-path    VER:code-compliance
FIN:budget       DEC:sequence     LUP:decision

The prefix is the phase. That one convention does a surprising amount of work. The whole ledger for a home is a single JSON document; a new fact is a new key in that document, never a new
table. Labels title-case themselves from the task token. Units infer from the measure name. The question the orchestrator asks the homeowner falls back to the slot's meaning. A new code costs no schema, no migration, and no label. The ontology grows by extending its codes, not its
storage.

The seven families

Until now the public documentation named three families: DES (design), BLD (build) and VER (verification). The engine has always shipped seven.

Code	Family	Owning mind	The question it answers
FIN	Finance	PIT LORD	What can this homeowner afford, and what will lenders compete to fund?
DEC	Deconstruction	REAPER	What is already here, and in what order does it come apart so every layer survives?
DES	Design	CDA	What is the best thing we can build on what is here?
BLD	Build	MURPHY	What is the critical path to completion?
MKT	Market	MIA	What does the market say — about this home, and about what comes out of it?
VER	Verify	VERA	What is true about this house, and how sure are we?
LUP	Equity Loop	PI · PIT LORD · REAPER	What did this cycle create — and does the homeowner want to go again?

They form a small directed graph — FIN → DEC → DES → BLD → VER → LUP, with MKT hanging off deconstruction — and one edge points backward: LUP → FIN. That edge is the only reason this
is a loop and not a line.

LUP is not an acronym; it is loop. It is where the homeowner's
choice lives as a code — LUP:decision: expand this home again, open another value-chain home, or hold. The system never assumes the answer. It asks.

Four of them were starving

Here is the honest part. Count the slots each family actually had in the shipped template:

Family	Shipped slots
DES	18
VER	10
BLD	7
DEC	4
LUP	4
FIN	1
MKT	1

Design and verification were rich. Finance, deconstruction, market and the loop itself were
nearly empty. That is not a prioritization choice. It is a structural consequence of one line of
code.

Who is allowed to speak

On the ledger, a fact is not a value. It is a claim — a value, plus who made it, plus the grade of evidence behind it. Several claims sit on the same entry, and the ledger decides which one stands, shows every one that dissented, and refuses to present a contested number as fact. The reconciliation model is written up in Claims, Not Facts; this post is about who gets to make one.

The type that says who may make a claim looks like this:

type VcClaimant = "custodian" | "homeowner" | "vera" | "cda" | "pi" | "record";

Six names. Look at who is missing. REAPER, PIT LORD, MURPHY and MIA — the minds that own deconstruction, finance, construction and market — cannot put their name on a claim. The phases they own had nowhere to speak. Of course FIN had one slot.

Claimants without seats

The fix was already sitting in that list. cda is there — the design mind can claim — but CDA holds no seat on the ledger's party strip. That is deliberate. The five seats that can ground an entry are the homeowner, the public record, VERA, PI and the Custodian. CDA is the model being
grounded; a design claim is the thing being checked, never a check.

That standing extends cleanly to the other four. A V2 mind may claim; it may never ground. Its claim enters as modeled, the lowest grade on the evidence ladder. It can be confirmed only if an independent party agrees. It can never win a standoff against a tape measure. And its name never
lights a seat — because lit means input, not agreement, and a seat that lit for its own model would be the ledger agreeing with itself.

Every mind claims. Five seats ground. VERA gates. Only the Custodian stamps.

Whose word wins on whose fact

The ledger does not rank claimants globally. It ranks them per kind of fact — what it calls a domain. Four ship today:

Domain	Meaning	Who leads, after the Custodian
`interior`	what the homeowner can see and touch inside	the homeowner
`legal-record`	recorded facts — stories, year, recorded square footage	the record
`exterior-geo`	exterior geometry measured by instrument	VERA
`derived`	computed from other facts; nobody observes it	VERA

The Custodian leads every domain — a stamp is the review. Below that, a tape measure inside the house outranks a satellite; the assessor's card outranks memory on the year it was built; the instrument outranks everyone on the roof pitch.

Now put a finance code through it. Nothing routes FIN:* anywhere in particular, so it falls to derived — and in derived, VERA outranks the homeowner. Which means that on the question what is the most you want to spend, a model would outrank the person whose money it is.

So two domains are proposed alongside the new claimants. intent — a choice or a constraint only the homeowner can set: budget, timeline, the loop decision — where the homeowner leads.
market — a price or a velocity observed in a market: comparable sales, a lender's bid, absorption — where the record and MIA lead.

What the four families get

Twenty-nine proposed slots, each with its domain, who may claim it, who verifies it, and which minds consume it. A sample:

FIN:budget — the homeowner's own ceiling for the cycle; the number the entire plan set must fit under. Homeowner claims, PI checks. Domain: intent.
DEC:contamination — the lead / asbestos / mold screen. Positive routes to licensed abatement; untested is treated as positive. The intake gate — refusing a job is a feature.
DEC:assembly-stack — each assembly's layer order, innermost first: the order it will be freed. Roof: rafters › sheathing › underlayment › shingles.
MKT:comps — recent comparable sales in the locality; the mirror the assessment curve is checked against. MIA reflects; she never decides.
LUP:equity-delta — equity created this cycle: post-build value less principal. Physical improvement, not market timing.
LUP:decision — expand, start another, or hold. The flywheel, as a row in a file.

The full table, with every slot marked shipped or proposed, is in the repository's [ontology/families.json] https://github.com/MLSystemsRI/ml-systems-public/blob/main/ontology/families.json), and the diagram that goes with it is master-ledger-workflow.html.

What is real here

Reality labels, because this company labels everything:

The seven families, the SECTION:task grammar, the claim model, the four domains, the five seats, the two-key stamp — MEASURED. They ship in the engine and run on every compile.
The 46 shipped slots — MEASURED. They are in the template today.
The four new claimants, the two new domains, the 29 new slots — proposed. Design, written down, with the exact list of code changes it would take. Not yet in the engine.
Any slot that depends on a job having run — recovery tonnage, diversion, absorption — is ASPIRATIONAL. No ML Systems deconstruction has been performed yet.

The ontology is the connective tissue that lets a fact discovered on a job site inform a financing decision without losing its meaning. For four of its seven families, that tissue was there but the nerve was not connected. The fix is small. The reason it matters is not.

ML Systems LLC · Rhode Island · NAICS 236115 · mlsystemsri.com ·
github.com/MLSystemsRI/ml-systems-public

Can a Crew, a Model, and a Robot Agree on What a Rafter Is?

Sal Parvez | ML Systems — Thu, 10 Sep 2026 00:16:28 +0000

Three parties describe the same roof and none of them can read the others' description.

The town assessor's record says asphalt shingle, average condition, year built 1962. A vision model looking at a satellite tile and a street-level photo says gable, moderate pitch, two planes, one chimney interrupting the north field. An estimator standing in the driveway says twenty-two squares, stick-framed, ring-shank sheathing nails, probably plywood over the original boards. All three are describing one assembly. There is no shared vocabulary between them, and the moment a fourth party arrives — a crew with a crane, or eventually a robot — the problem gets worse, not better.

So the question: can a single grammar carry a roof from the assessor's record to a crew's cut plan to a machine's disassembly sequence without any party translating? ML Systems' bet is the Collective Ontology. What follows is the argument for it, made on the one assembly where it is easiest to check — and the admission at the end that it has not been checked.

An assembly is a stack, and a stack has a direction

A house is not one object. It is a set of assemblies — roof, walls, floors, foundation — and each assembly is a stack of layers applied in a known order. A roof is rafters, then sheathing over them, then underlayment, then shingles last. Each layer was fastened through the layer beneath it. The fastening is what makes four layers one structure, and it is also what destroys them when the structure is taken apart in the wrong direction.

Two scales, and they run opposite ways:

Scale	Direction	Order
The building — between assemblies	Reverse of construction	Roof → walls → floors → foundation
An assembly — between layers	Inside out	Innermost layer → outermost layer

This is the thing most easily got backwards. A tear-off runs reverse order within the assembly — shingles first, because shingles went on last — and that is precisely the order that destroys everything, because every layer is broken through on the way to the one below it. Working the assembly inside out means running the same sequence it was built in, reached from the face that used to look into the attic.

A data model that stores a roof as {material: "asphalt", area_sf: 2200} has nothing to say about any of this. If the answer to the question is yes, the model has to store the stack, the fastening between layers, and both directions.

Order is a graph, so the ontology stores a graph

In the Collective Ontology, claims about a house are tagged with stable code families: DES:* for design and geometry, BLD:* for build facts — load path, footing, bill of materials — and VER:* for verification stamps. A rafter is not a row in a materials table. It is a node with typed edges: sits on the wall plate, ties to the ridge, is fastened through by the sheathing above it. The sequence those edges imply is a directed acyclic graph.

That is why the scheduling side is built the way it is. REAPER is ML Systems' scheduling engine, which compiles job sequences as a directed acyclic graph. Disassembly at the building scale is the reverse topological order of construction. Disassembly at the assembly scale is the same order as construction, reached from the inside — and the graph can hold both, because they are properties of the edges, not of the nodes.

The ontology grows by extending its codes, not its storage. A new fastener type, a new sheathing product, a truss instead of a stick-framed rafter — each is a new code and a new edge type, not a schema migration.

The concrete test: sectioning a roof

Here is what the graph looks like when it is executed — on paper.

To move a roof in pieces, the pieces have to survive being moved, so the cut lines follow the framing: the ridge first, separating the two planes; then along rafter lines, cutting at a rafter rather than between two of them, so each section keeps a full rafter along each edge as its spine; then the rafter-to-plate connection last — the release cut. Rigging is attached before the release cut, never after.

Then the section is turned over at grade — rafters up, shingles down — so the inside face is on top and gravity assists instead of resisting. The stack now comes apart in build order from the inside: rafters, then sheathing, then underlayment, then shingles. Each step is a node in the sequence with a fastener strategy attached to it. For ring-shank nails, which are engineered specifically not to withdraw, the strategy is cut, don't pull: a couple of minutes per sheet to keep both the rafter and the panel instead of trading one for the other.

The full method — bracing the top floor before the first cut, the lift plan, the safety envelope under OSHA 1926 Subpart M, Subpart CC and 1926.1153 — is written out in Taking a Roof Apart in Sections — and Keeping Every Layer. This post is about what it would produce.

What would come off the roof is data with an ID

Every recovered material gets an ML Material ID:

ML-{year}-{project}-{zone}{sequence}
ML-2026-001-R042

The ID resolves to a public provenance record carrying a grade — A, B, C, D or salvage — and a contamination status: clean, lead, asbestos, mold or untested. Lead, asbestos and mold block a listing outright, regardless of grade, and that screen runs before the work does rather than after.

Material sorts into Z1–Z8, ML Systems' material taxonomy for deconstruction streams. The streams are where material goes, not the order it comes off; a roof feeds Z2 (lumber), Z4 (sheathing), Z6 (hardware and metals) and Z8 (roofing) at once. Each line is routed by RRR — Reuse › Resale › Recycle — route each recovered material to its most valuable recoverable state.

The roof is where the prediction would meet the measurement

Before a deconstruction, everything the system believes about a roof came from a record, an image, or a model — evidence grades RECORD and MODELED in the Master Ledger's terms. The roof is the first assembly that could answer back. Each recovered member would post a claim at grade MEASURED, reconciled against what the assessor's record, the homeowner's memory and the model's prediction each said was up there. Roofs are where those three disagree most often. The reconciliation mechanics — domain-scoped authority, evidence grades, multiverification, stamps that lapse when the content moves — are in Claims, Not Facts, and the agents that write the claims are in My AI agents don't talk to each other.

What a house learns about itself collapses into its HomeGenome through Ontological Compression: the smallest complete description from which the house can be reconstructed, emitted per property and per cycle. The roof's entries would be the first ones in that genome to carry a measured grade.

So — can it be done?

On paper, yes: the stack is representable, the order is a graph, and the graph is executable as a cut plan. In the field, unknown. No ML Systems deconstruction has been performed yet. Everything above is a designed sequence — reasoned from framing practice and the safety standards it has to satisfy — not a report from a completed job. The system is designed to recover up to 80–90% of a home's materials — MODELED, a target. A fully specified disassembly sequence as robot training signal — ASPIRATIONAL.

The honest answer to the title is that the ontology can hold the rafter. Whether the crew, the model and the machine agree on it is a question only a real roof can answer, and the method is published now so that the first one has something specific to argue with. If you have taken a roof apart in sections, or tried and failed, the comments are the right place for it.

ML Systems LLC · Rhode Island · NAICS 236115 · mlsystemsri.com · Public reference: github.com/MLSystemsRI/ml-systems-public

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

Sal Parvez | ML Systems — 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

Sal Parvez | ML Systems — 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.

Sal Parvez | ML Systems — 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

Sal Parvez | ML Systems — 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

Sal Parvez | ML Systems — 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.

DEV Community: Sal Parvez | ML Systems

AI Is Not Valuable. Your Context Window Is.

Seven windows, one brain

Size is capacity. Curation is the asset.

The window has an intake spec

Provenance is the window, not the model

The honest part

Vibe coding names a mood. The job is Language Modeler.

What the term means

Why "vibe" was the wrong word

What the Modeler has to know

Where the skill actually lives

The first hire

The honest labels

Fingerprint at load, pulse before every pass: a heartbeat for agent identity

The failure I was actually afraid of

The heartbeat

The heartbeat, pointed outward

Verify it yourself

Why a lens and not a rule

What already exists

The honest labels

MVE: The Balance in MVP

Where I learned it: a nail

One spend, four returns

The same rule for the agents

Why the balance matters more than either side

Embedded evaluators, at house scale

The system

Why this is the same idea

Labels

Further reading

Seven Families, One Ledger — how a house gets a grammar

A house means different things to different parties

Codes, not storage

The seven families

Four of them were starving

Who is allowed to speak

Claimants without seats

Whose word wins on whose fact

What the four families get

What is real here

Can a Crew, a Model, and a Robot Agree on What a Rafter Is?

An assembly is a stack, and a stack has a direction

Order is a graph, so the ontology stores a graph

The concrete test: sectioning a roof

What would come off the roof is data with an ID

The roof is where the prediction would meet the measurement

So — can it be done?

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

What the ledger is, in one paragraph

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

Stage 2 — Deconstruction: where the material intelligence is generated

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

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

The exhaust is the product

Where this actually is

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

The core idea: claims, not facts

Why a flat evidence ordering breaks

Reconciliation states

Multiverification and lapsing signatures

Nothing goes unreviewed because nobody touched it

Record-first UI

What it's the substrate for

Reality labels

Read further

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

Intuition first, but the intuition came from the material

The unique data

Production, meaning the boring parts

Where I disagree slightly: RAG, evals, and agents

The last thing

My AI agents don't talk to each other

What breaks in the group-chat design

Agents as authors, not as callers

Disagreement is a data problem, not a conversation

Freeze the agent definitions

The honest costs

Where this runs