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.