BIM data is evidence, not authority
A parameter in a model is a claim made by whoever typed it. Treating claims as authority is how wrong numbers get inherited across an entire project.
Open almost any coordination model and you will find a wall type called something like 'EW-01 200 Concrete Ext'. It looks authoritative. It is not. It is a string somebody typed, possibly copied from a previous project, possibly never revised after the design changed.
Claim, evidence, requirement, authority, resolution
Keeping these five things distinct is what prevents a model label from silently becoming a project commitment:
| Term | Meaning | Example |
|---|---|---|
| Claim | What someone or something asserts | A type name containing 'EI60' |
| Evidence | Material offered to substantiate a claim | A compound layer structure, a test report |
| Requirement | What must be satisfied | The system must achieve EI60 |
| Authority | Why a requirement governs | A regulation, standard or project contract |
| Resolution | The deterministic conclusion | This element resolves to this governed recipe |
No BIM parameter, attached PDF, product field or AI interpretation becomes authority by mere presence. It has to be admitted through a rule that says what kind of evidence it is and what it is allowed to influence.
Why inference is the wrong shortcut
It is tempting to fuzzy-match names: if the type contains 'concrete', classify it as concrete. It works in demonstrations and fails in production, because the failure mode is silent. A wrongly inferred category does not raise an error; it produces a confident, wrong quantity that flows into cost and carbon.
A stricter rule is safer: accept an explicit category property, accept an explicit hierarchy ancestor, accept an exact known alias — and otherwise leave the element explicitly unidentified, visible and actionable. Unidentified is annoying. Wrongly identified is expensive.
Identity must be addressed, not assumed
A model identifier is only meaningful inside the surface it came from. An internal object id is local to one viewable in one model version; carrying it across a re-publish or a different derivative is how selections, analyses and receipts quietly point at the wrong objects.
The fix is to address evidence with the full surface — the model, the exact version, the viewable — and to invalidate dependent analysis when that surface changes, rather than hoping the ids still line up.
Manufacturer content deserves the same discipline
Manufacturer-authored families carry real, valuable information, and they are still claims. A product name is not admission authority; a mapped, supported classification entity is. Where a mapping is missing, the honest state is 'no mapping', not a best-guess match on the product name.
The same applies to links embedded in model content. A URL pointing at a datasheet is useful evidence and a reasonable thing to surface to a reviewer. It is not proof that the linked document governs the decision.