1. Introduction — The Paradox of Standards
The dream of a digital commons is as old as the internet itself: a space where information flows freely across boundaries, where collaboration scales beyond organisations, and where knowledge becomes a shared infrastructure rather than a private asset. In the architecture, engineering, and construction (AEC) industry, this vision has taken shape through the promise of interoperability, the idea that different actors, tools, and datasets can work together through shared principles.
At its best, standardisation is what makes such openness possible. Without common languages, naming conventions, or processes for exchanging data, digital collaboration would collapse into chaos. Standards like the ISO 19650 series aim to provide precisely this foundation: the creation of a shared grammar that allows models, documents, and workflows to circulate between organisations with clarity and traceability. In this sense, the rise of standards has been a civilising force, transforming the digital wild west of disconnected files and ad-hoc naming systems into a structured, navigable ecosystem.
Yet every act of ordering carries a shadow. The same mechanisms that enable coordination can also harden into bureaucracy. The same shared language that makes communication possible can become a code only the initiated can read. What begins as a set of guiding principles can easily devolve into a checklist culture where the goal shifts from understanding to compliance.
In the pursuit of interoperability, we risk building new silos: not of technology, but of interpretation.
This week’s reflection examines that paradox. How do digital standards — from ISO 9001’s legacy of quality management to the ISO 19650 framework for information management — shape not only our workflows but also our ways of thinking? At what point does the pursuit of order begin to constrain the creativity, adaptability, and openness that the digital commons was meant to protect?
2. The Origins of Regulation in the Digital Built Environment
Standards emerge wherever human collaboration grows too complex to rely on intuition alone. They are the protocols of civilisation: the quiet agreements that let us build, trade, and coexist without constantly reinventing the rules. The digital built environment — a vast ecosystem of architects, engineers, contractors, and clients — could not exist without them. But to understand what digital standards have become, we need to trace their origins back to the world that first needed them. No, not the pyramid. The factory.
2.1. Why We Standardise: Efficiency, Safety, Accountability
Standardisation has always been a way to tame uncertainty. The industrial revolution brought with it a chaotic proliferation of methods and parts: every workshop produced screws, gears, or fittings of slightly different dimensions. Assembly was an act of craftsmanship, not system. When the first mechanical standards appeared — such as the Whitworth thread in 1841 or later the ISO metric system — they were revolutionary not because they limited creativity, but because they allowed machines to talk to one another. Interoperability was born on the factory floor.
The same logic drove the standardisation of management. As industries scaled, it wasn’t enough for the bolts to fit; the processes themselves had to fit together. Out of this need came the quality movements of the 20th century: Deming’s continuous improvement cycles in Japan, the procedural rigour of Total Quality Management, and ultimately the ISO 9001 standard. Its purpose was noble — to ensure consistency, traceability, and a culture of improvement — yet its implementation often revealed a deeper paradox. What was meant to encourage reflection on how quality is achieved became, in many organisations, a bureaucratic ritual of proving that quality systems exist. The process of documentation began to overshadow the pursuit of excellence.
It’s a familiar story beyond industry. Anyone who’s ever filed a tax return, updated a corporate risk register, or tried to save the galaxy in a videogame where the tutorial never ends knows the feeling: you’re following the rules to unlock the next stage, but the game has forgotten why the rules exist. The structure that once gave you freedom now dictates your every move.
2.2. From ISO 9001 to ISO 19650: the Lineage of Quality Management
The ISO 19650 series — today the backbone of information management in Building Information Modelling (BIM) — descends directly from this managerial lineage. It inherits not only the principles of clarity, repeatability, and continuous improvement, but also the organisational logic of the quality standard: define a process, document it, and demonstrate compliance. Its roots lie not in technology but in governance.
When the first BIM standards emerged, the industry was struggling with another kind of fragmentation: every project team, every software vendor, every national standardisation body had its own dialect of data management. The introduction of ISO 19650, following the other regional and local attempts, was a historic attempt to unify these languages under a global grammar. It did not prescribe which naming convention to use, but that there should be one in order for information to flow between actors. It defined roles like the “Appointing Party” and “Lead Appointed Party” to clarify responsibilities without limiting to one stage or the other, and it introduced concepts like the Common Data Environment (CDE) to structure collaboration. In theory, this was the architecture of a digital commons, a framework within which everyone could participate equally.
But here, again, the shadow of ISO 9001 looms. In many organisations, implementation has followed the same pattern: the pursuit of certification eclipses the pursuit of comprehension. Teams replicate templates without understanding their intent. The focus shifts from “managing information to improve collaboration” to “filling out the Exchange Information Requirements because the client asked for them.” The standard, designed to foster dialogue, becomes a static script.
2.3. The Migration of Industrial Logic into Digital Collaboration
This drift from principle to prescription mirrors a broader migration: the importation of industrial logic into the digital. Factories once standardised parts; now offices standardise processes. The factory line has become the workflow diagram. And while these diagrams can bring coherence to complex collaborations, they can also impose a mechanistic view of human coordination, one that values predictability over adaptability.
Consider how many collaborative platforms today, from CDEs to project management tools, replicate the logic of the assembly line: tasks flow from one station to the next, every output depends on the completion of a previous step, and efficiency is measured by throughput. It’s the same design philosophy that underlies both Henry Ford’s Model T production and the data pipelines of modern BIM workflows. The result is order, but sometimes at the cost of creativity.
The cultural imagination has long been wary of this tension. In The Lego Movie (2014), the villain is literally called Lord Business, a caricature of standardisation gone too far, glueing every brick into its “correct” place. In video games like Factorio or Satisfactory, the player builds vast automated systems to achieve perfect efficiency, only to realise that the system now controls them. The metaphor holds uncomfortably true for digital construction: in our quest to automate collaboration, we risk automating thought itself.
And yet, the alternative — total freedom — is no better. Without shared standards, BIM collapses into Babel: files named inconsistently, models misaligned, data irretrievable. As in any ecosystem, some degree of structure is necessary for life to flourish. The question is not whether to standardise, but how to keep standardisation alive — dynamic, interpretive, and responsive to context.
3. The Double-Edged Nature of Standards
Every standard begins as an act of rebellion against chaos.
It says: enough with the confusion, the version clashes, the impossible file names. It offers a structure, a promise that if we all agree on how to name, classify, and exchange our work, collaboration will flow freely. ISO 19650 was born from precisely that conviction: that digital coordination could become as seamless as the geometry of the models it governs.
But somewhere between the ideal and its implementation, something changes.
The grammar that was meant to empower conversation becomes an orthodoxy. The rulebook replaces the reasoning. We start confusing coordination with compliance.
And in this confusion, the liberating idea of interoperability — the idea that systems, people, and disciplines could speak to each other — begins to harden into rigidity.
3.1. Interoperability vs. Rigidity: Coordination Through Compliance
Interoperability was supposed to be our lingua franca: a shared space where architects, engineers, and builders could exchange data without friction. Yet too often, what passes for “coordination” is little more than the synchronised performance of rule-following. We produce naming conventions so strict they require spreadsheets to decipher, file structures so ornate they resemble bureaucratic cathedrals.
In meetings, someone always says, “We’re ISO 19650-compliant,” as if that ends the discussion, as if compliance itself were proof of collaboration. But interoperability is not a checklist. It’s a conversation.
What good is a Common Data Environment if no one feels common inside it?
We’ve inherited a culture that equates discipline with understanding. But discipline without insight is just choreography, a collective dance whose steps no one remembers how to change. The more we tighten the rules to ensure order, the more we risk strangling the very adaptability that digital collaboration demands. Like a model over-constrained by its own parameters, the system stops moving.
3.2. How Guidelines Become Templates: the Comfort of Prescription
The problem isn’t malice: it’s fear.
Faced with complexity, teams crave certainty. Nobody wants to be the one who gets it wrong. So we reach for templates. We download “ISO 19650-compliant” folders, we replicate naming rules from other projects, we demand “examples” from the last job.
Guidelines that were written to provoke thinking are repackaged as ready-made answers.
It’s the same phenomenon that hollowed out ISO 9001. What began as a quality philosophy became a paperwork industry: procedures were copied verbatim, checklists replaced reflection, and soon “being compliant” became indistinguishable from “doing quality.”
In the digital construction world, the same logic creeps in quietly: if it looks like the example, it must be right.
And that’s where creativity dies: not in chaos, but in comfort.
Like in videogames, when the open world turns into a quest log: what was once exploration becomes a sequence of boxes to tick. The player still moves, but the freedom is gone. In our workflows, too, we mistake movement for progress, templates for wisdom, compliance for competence.
3.3. “Show Me the Example” Culture: when Compliance Replaces Understanding
“Show me the example.”
It’s the most common and most dangerous phrase in the implementation of any standard. Behind it lies a subtle surrender: the decision to follow rather than to interpret. It signals a loss of curiosity, a shift from why to how.
The culture of example-worship breeds passivity. Instead of developing an information management strategy grounded in the project’s context, teams search for the “correct” naming format or the “approved” metadata field. The conversation narrows to syntax, not meaning.
We stop asking what information is needed to make better decisions and start asking what information is needed to pass the audit.
And here’s the irony: in trying so hard to conform, organisations end up fragmenting. Each develops its own sacred template, its own “best practice” that can’t quite talk to anyone else’s. The commons dissolves into a patchwork of micro-bureaucracies, each convinced it’s following the standard to the letter. The very structure designed to unify us becomes the seed of a thousand little silos.
We don’t need more templates. We need literacy: the ability to read a standard, to interpret it, to argue with it. ISO 19650 was never meant to be a gospel; it was meant to be a language. And languages live only if we keep speaking them, bending them, making them our own.
So let’s stop treating standards as commandments from the mountain and start treating them as invitations to dialogue. The moment we forget that, we’re not managing information anymore: we’re just decorating our silos with certificates.
4. Lessons from ISO 9001: Quality vs. Bureaucracy
There was a time when “quality” was a battle cry. It meant craftsmanship, care, and pride in getting things right. When the ISO 9001 standard was introduced in the late twentieth century, it promised to bring that same ethos to the complexity of industrial systems: a way to scale excellence without losing integrity. It was the language of continuous improvement, of feedback loops and learning organisations. It was lovely.
But somewhere along the line, the revolution was domesticated. What began as a living philosophy became an administrative ritual. Instead of making better products, companies began to make better paperwork.
4.1. From Philosophy to Paperwork: when Form Overtakes Substance
Ask anyone who’s survived a quality audit, and you’ll hear the same story. The week before the auditors arrive, the office becomes a theatre of compliance: folders are polished, procedures rewritten overnight, and version numbers quietly aligned. The ritual has little to do with improving outcomes: it’s about demonstrating control.
By the time the auditors show up, the company has achieved a flawless simulation of quality.
It’s the same logic as a speedrun glitch in a videogame: players learn to exploit the system’s rules rather than play the game as intended. In ISO 9001, organisations learned that it was faster to document improvement than to achieve it. The “quality manual” became a shield, a way to survive audits without changing behaviour.
That’s how form wins over substance. Processes are followed religiously, but no one remembers why they exist. The mantra becomes “say what you do, do what you say”: but what if what you say is meaningless?
4.2. Checklists, Audits, and the Illusion of Control
Audits, in theory, are meant to keep systems accountable. In practice, they often create an illusion of control: the comforting sense that if everything is documented, everything must be under control. But as every project manager knows, the neatness of a checklist has little to do with the chaos of reality.
Real quality — like real collaboration — is messy, iterative, full of human judgment calls. But audits don’t measure that. They measure traceability, not insight; conformity, not wisdom.
It’s a dynamic familiar to anyone who’s watched the bureaucratic dystopias of Brazil or… well, The Office: paperwork multiplies in proportion to the system’s anxiety about itself. The more uncertain the process, the thicker the binder. The map becomes so detailed that it covers the entire territory.
And here’s the kicker: the more time you spend maintaining the system, the less time you have to improve the product. In many ISO-certified organisations, employees quietly joke that the Quality Management System needs its own quality management system, a recursion so absurd Kafka would have approved, as we have seen.
4.3. The Same Risk in BIM: Managing Data Instead of Managing Meaning
BIM, with all its potential for transparency and collaboration, now stands on the same precipice.
We discuss “information management” as if the goal were to possess data rather than to comprehend it. We measure success in terabytes and compliance matrices instead of insights gained or decisions improved. Like ISO 9001 before it, ISO 19650 risks being reduced to a choreography of evidence: naming conventions checked, folders approved, metadata verified.
The tragedy is that the tools meant to liberate us from inefficiency can just as easily enslave us to their own procedures. In some organisations, entire roles exist solely to maintain the illusion that data is “under control”: dashboards glowing green, folders neatly sorted, every file in its proper place. Yet when the design changes or the site shifts, the truth emerges: the control was performative. The model is pristine; the reality is chaos.
It’s the SimCity paradox. The city on the screen is clean, ordered, and balanced — but the moment you unpause and let people move in, traffic jams and power outages expose the difference between planning and life. BIM, too, can become a simulation of collaboration — a city frozen at 100% compliance but 0% vitality.
We have to ask ourselves: do we want to build systems that record quality, or systems that produce it? Do we want to manage information, or meaning?
The lesson from ISO 9001 should be seared into our collective memory: when the process becomes the product, the product no longer matters. The goal of standards is not to ensure that everyone fills out the same form, but that everyone can think together across differences safely, clearly, and creatively.
If we forget that, BIM will not be our digital commons: it will be our next bureaucracy.
5. ISO 19650 and the Architecture of Digital Cooperation
When ISO 19650 appeared, it carried a quiet but radical promise: to make collaboration legible. Not identical, not uniform: legible. Its goal was never to produce clones of the same workflow but to offer a shared language through which different disciplines could finally understand each other.
In spirit, it was an act of diplomacy: the framers of ISO 19650 knew that the digital built environment had become a Tower of Babel, with every firm speaking its own dialect of “information management.” The standard’s purpose was to give us grammar, not scripture: principles to coordinate by, not rules to worship. That’s why the norm says you should have a naming convention but doesn’t provide you with any example. It was an attempt to replace the chaos of personal conventions with a structure of mutual accountability.
In its best moments, ISO 19650 still does exactly that: it defines roles that clarify responsibility without prescribing hierarchy. It distinguishes between “information requirements” and “information deliverables,” insisting that data must have a purpose, not just a format. And in a world drowning in digital files, it safeguards the notion of a Common Data Environment (CDE): a neutral space where truth, ideally, could be shared.
It’s a beautiful idea. But as with all architecture, the elegance of the plan means little if the foundations shift when people move in.
5.1. Ambiguities and Translation Gaps: CDEs, Naming Conventions, and Metadata
The trouble with any international standard is that it must remain abstract enough to be universal, and abstraction breeds ambiguity.
ISO 19650 tells us what should exist, but not exactly how. One firm’s “single source of truth” is another’s tangle of permissions and folder depths. Naming conventions mutate with every national annexe; metadata schemas become their own dialects. Everyone insists they’re “aligned with ISO 19650,” yet interoperability fails not because the standard was wrong, but because its interpretations don’t interoperate.
It’s like fan communities translating the same manga into a dozen unofficial versions: all passionate, all earnest, but none quite matching the tone of the original. The intent survives, but the meaning drifts.
These gaps are not just technical, as it often happens: they’re cultural. Every organisation reads the standard through its own filters: commercial, legal, linguistic, and even emotional. A clause meant to promote openness becomes a weapon for control: “We can’t share that file; it’s not ISO-compliant.” A framework meant to simplify exchange becomes an ecosystem of proprietary compliance.
Ironically, ISO 19650’s greatest strength — its interpretive flexibility — is also its Achilles’ heel: a common trait of many ISO norms. It invites understanding, but demands maturity to interpret. And in an industry addicted to templates, maturity is often the scarcest resource.
5.2. The Reality on the Ground: Standards Without Shared Understanding
Walk into any coordination meeting of a large-scale project, and you’ll see the paradox play out in real time.
The folder structures are perfect. The naming strings are immaculate. The models, neatly federated. And yet, the conversation sounds like a diplomatic summit where every participant is speaking technically the same language but with entirely different meanings attached to each word.
One team says “Approved for Construction,” meaning we’re done modelling. Another hears “ready to build”. Someone else interprets “information delivery” as a PDF, not a dataset. The standard didn’t fail: the shared understanding did.
What results is a choreography of compliance with no choreography of comprehension. Teams perform the ritual of upload and approval, but no one truly collaborates. The CDE becomes a digital museum, full of immaculate exhibits, none of them alive.
It’s the same illusion that plagues multiplayer games when lag sets in: everyone sees themselves moving perfectly on their own screen, but from the outside, the team is out of sync. ISO 19650 was meant to synchronise intent, not just motion, yet too often we mistake synchronised motion for shared purpose.
In this sense, we’re not facing a technical failure but a pedagogical one: we’ve built the architecture of cooperation but not the culture to inhabit it; we’ve designed the syntax of exchange without nurturing the semantics of trust. Until that changes, ISO 19650 will remain what it currently is in too many projects: a magnificent skeleton waiting for living flesh. A digital commons in blueprint form but not yet a community.
So, what ca we do?
6. Toward a Living Standard: Reclaiming the Spirit of Collaboration
If the previous sections read like an indictment, this one must read like a reclamation. Standards are not the enemy; bureaucracy is not inevitable: what kills collaboration is not structure, but forgetting why structure exists. ISO 19650, at its core, is not a cage but a language. And languages, as we were saying, are living things. They only die when people stop speaking them with imagination.
To keep the digital commons alive, we must rediscover the art of principle-thinking: the capacity to act within a framework without becoming enslaved to it.
6.1. From Rule-Following to Principle-Thinking
Every standard contains two layers: the visible skeleton of rules, and the invisible spirit of intention. The rules tell you what to do; the principles tell you why it matters.
When we train people to follow standards as recipes, we produce compliance. If we train them to interpret principles, we produce judgment.
In a world as fluid as digital construction, judgment is the only sustainable form of expertise. The ability to decide, in context, what information actually needs to be exchanged, how naming conventions should adapt to project complexity, or when to bend a rule for the sake of clarity: that’s the difference between bureaucracy and mastery.
It’s the same lesson every good designer learns: you must first learn the grid to know when to break it.
Standards are no different. They’re scaffolds for thought, not walls around it.
If ISO 19650 is to remain relevant, its future depends on cultivating interpretive literacy: professionals who can read the standard like architects read a plan: understanding not just where the lines are, but what space they enclose.
6.2. Encouraging Interpretive Literacy and Situational Judgment
Interpretive literacy is not about memorising clauses; it’s about inhabiting them. It’s the capacity to translate abstract definitions into local realities, to ask: What does this mean for us, here, now?
This literacy must be taught, not assumed. It should be embedded in how organisations train their teams, how universities teach BIM, and how clients write their requirements. Instead of handing out templates, we should hand out questions:
- What problem is this clause trying to solve?
- What information do others actually need from me?
- What is the minimum structure that still enables trust?
That’s how culture changes: not through more rules, but through better reasoning.
In this sense, the evolution of BIM culture has much to learn from the worlds that have thrived precisely because they embraced open interpretation. Think of how the modding communities of videogames like Skyrim have sustained themselves for decades: their survival depends not on rigid control but on a shared literacy of experimentation. Everyone learns by adapting the base game; everyone contributes by expanding it.
ISO 19650 should be treated the same way: not as a finished product, but as an open platform for shared sense-making.
6.3. Open-Source Culture as a Model: Maintaining a “Commons of Understanding”
The open-source movement outside the construction industry offers a living example of what a commons of understanding can look like. Its vitality comes not from universal agreement, but from continuous interpretation. Code is forked, improved, debated, and remerged. Disagreement isn’t a failure of the standard but proof that the community is alive.
Imagine if BIM standards were maintained the same way: not as documents updated every five years by distant committees, but as collaborative repositories where practitioners could contribute examples, comment on ambiguities, and test new approaches. The ISO clauses could remain stable, but the interpretation layer — the living tissue of applied practice — could evolve in real time.
That’s how you prevent calcification. That’s how you keep a language breathing.
A digital commons worthy of the name must be more than interoperable files; it must be interoperable meaning, a culture where standards are not worshipped but argued with, iterated upon, and shared openly.
In other words, the opposite of silos.
The task before us is not to abandon standards but to animate them, to make ISO 19650 less like a monument and more like open-source code: forkable, discussable, alive.
Because if the commons is to survive, it needs fewer rule-followers and more maintainers: people who keep the conversation going, who remember that collaboration is not an outcome, but a practice.
Conclusion: the Ethics of Shared Language
In the end, every standard is a social contract.
It exists because a group of people decided that clarity was worth the effort, that confusion was too costly, that cooperation was still possible. ISO 19650, like its predecessors, is built on trust: the belief that if we speak a common language, we can build a shared future.
But trust cannot be legislated: it must be maintained.
That’s why the digital commons is not a technical construct but an ethical one. It lives — or dies — in the daily choices of the people who inhabit it: the modellers who decide whether to name things meaningfully; the coordinators who choose dialogue over escalation; the clients who ask for understanding instead of blind compliance.
A standard can define structure, but only culture can define integrity.
If ISO 9001 taught us how easily quality can become paperwork, ISO 19650 must teach us how to keep collaboration human. We must resist the seductive comfort of procedure, the fantasy that perfection lies in templates, acronyms, and colour-coded folders. The moment we confuse neatness with knowledge, we’ve already lost the plot.
Our industry needs translators who can move fluently between disciplines, between technologies, between mindsets, and leaders who understand that interoperability is not the alignment of software, but the alignment of intent. Because the truth is this: standards do not build silos. People do. And people can choose otherwise.
To work within a standard should be an act of freedom: the freedom to think clearly together. It’s a form of civic duty in the digital age: to preserve the spaces where shared meaning can still exist amid systems that would rather automate it away. If the twentieth century taught us how to build machines that work, the twenty-first must teach us how to build agreements that live.
That’s the real challenge — and the real promise — of the digital commons.
Not a world without rules, but one where rules serve understanding.
Not uniformity, but coherence.
Not compliance, but conversation.
Because in the end, the measure of a good standard is not how strictly it is followed,
but how widely it is understood and how generously it is shared.
No Comments