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.

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:

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:

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.