What is construction decision infrastructure?
Models describe geometry. Decision infrastructure records the choice, the evidence behind it, the authority that governed it, and the receipt that proves it.
A building model tells you that a wall exists, where it sits and what it is nominally made of. It does not tell you why that build-up was chosen, which requirement it was meant to satisfy, which product was priced against it, or whether anyone could reconstruct that reasoning six months later. That gap — between description and decision — is what decision infrastructure exists to close.
Description is not decision
Most construction software is descriptive. Authoring tools describe geometry. Coordination tools describe clashes. Data platforms describe properties. All of them are useful, and none of them hold the commitment: this element, in this scope, resolves to this system, using this recipe, satisfied by this product, at this price, with this carbon figure, because of this rule.
When that commitment lives only in a spreadsheet, an email thread or someone's memory, every downstream question becomes an archaeology exercise. Cost teams re-derive quantities. Sustainability teams re-derive materials. Contractors re-derive intent. Each re-derivation is an opportunity for the numbers to diverge.
Four properties of a decision you can trust
- Deterministic — the same inputs, the same rules and the same versions always produce the same result. No hidden randomness, no silent defaults.
- Traceable — every output can be walked back to the evidence it came from, and the evidence can be walked back to the model surface it was extracted from.
- Replayable — the decision can be re-executed later against the recorded inputs and produce the same conclusion, which is what makes disagreement resolvable.
- Auditable — a third party can inspect the chain without needing access to the person who made the call.
AI interprets, the engine decides
Language models are genuinely good at interpretation: reading messy type names, proposing what a user probably meant, explaining a result in plain words. They are the wrong tool for authority. A model that guesses a fire rating with high confidence is more dangerous than a system that refuses to answer.
AI interprets. Engine decides. Every decision should have a receipt.
The separation is practical, not philosophical. AI proposes actions and explains outcomes; a deterministic engine validates them and owns the authoritative result. Increasing the amount of automation must never erode that boundary — otherwise the receipt stops meaning anything.
Unresolved is a valid answer
The most under-rated feature of decision infrastructure is the ability to refuse. When evidence is missing, incompatible or ambiguous, the correct output is an explicit unresolved state with a named blocker — not a default value quietly substituted to make a dashboard look complete.
This matters most in aggregation. A partial cost total presented as a whole-building total is not an approximation; it is a false statement. Progressive outcomes should show what has been established, state the coverage, and keep the unresolved scope visible alongside it.
The authority chain
LITHIC Core organises decisions along a single chain, where each link may only take authority from the link above it:
- Identity — what this element actually is, addressed to an exact model version and viewable.
- System classification — which construction system the element belongs to.
- Contract — what the project has committed to for that system.
- Recipe — the governed build-up that satisfies the contract.
- Material requirements — what the recipe demands of real materials.
- Product selection — which real product satisfies each requirement.
- Price book — the versioned commercial snapshot the product is priced against.
- Cost and carbon — derived figures, never entered figures.
- Decision receipt — the signed record of all of the above.
Because the chain is ordered, a fault has a location. A wrong category is an identity problem. A missing build-up is a recipe problem. A stale price is a price-book problem. Four different problem classes, four different fixes, no cross-layer guesswork.
What this changes in practice
- Quantities stop being re-counted per discipline, because they resolve from one governed basis.
- Product substitutions can be compared without losing the requirement they were meant to satisfy.
- Carbon and cost move together, from the same selection, rather than from two parallel spreadsheets.
- Disagreements become inspectable: you replay the receipt instead of debating recollections.