Here’s an article very well written and conceived, by Jay Merlan. Clear, sensible, food for thought about the creation and use of information models in AEC. Practicalities do get in the way of dreamy longing for modeling totalities. Whatever your goal is, it takes another kind of thinking to put limits where limits need to be, and where they are, in fact, whether you recognize them or not.
I’ll say no more about the article, other than that I maximally recommend reading it:
Since the mid 90s I’ve had similar thoughts — to those in the article about “data” — about modeled geometry: from first-hand experience doing too much modeling, geometry overkill, with concomitant:
- increase in cost (my time) to review, check, maintain, update and
- decrease in project intelligibility as time and attention drowns in an ocean of “total modeling” at the expense of navigating the project to its destination port.
I proposed some solutions to that, described here: https://tangerinefocus.com
Some have been implemented. Others not yet. Always motivated by increase in sanity, decrease in drowning, increase in model intelligibility and usefulness, through increased interpretive clarity and focus from better forms of engagement with the modeled.
I ‘d guess that Jay Merlan’s approach to data is motivated by the same conditions.

