# Can a Crew, a Model, and a Robot Agree on What a Rafter Is? > Source: > Published: 2026-09-10 00:16:28+00:00 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. 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. 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. 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](https://github.com/MLSystemsRI/ml-systems-public/blob/main/deconstruction-lab/articles/roof-in-sections.md). This post is about what it would produce. 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. 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](https://dev.to/salparvez/claims-not-facts-building-an-auditable-multi-author-record-for-a-house-33d6), and the agents that write the claims are in [My AI agents don't talk to each other](https://dev.to/salparvez/my-ai-agents-dont-talk-to-each-other-166e). 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. 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](https://mlsystemsri.com) · Public reference: [github.com/MLSystemsRI/ml-systems-public](https://github.com/MLSystemsRI/ml-systems-public)*