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. 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. Two-key verification and lapsing signatures Entries can be stamped by both the homeowner and the Custodian — two keys, not one. The part that matters for integrity: a verification stamp (VER:...) is bound to the content it signed, via an entryHash. Change the number and the signature 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 stamp. 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.