Gilbert Simondon (1924–1989) was a French philosopher renowned for his work on philosophy of technology. He developed an ontology focusing on the processes of individuation, addressing how individuals emerge and transform through communication, and contributed significantly to information theory. This week we try to take some points away from him when it comes to information management.
Preface: framing the theory
For Gilbert Simondon, information is not a quantity transmitted from a sender to a receiver, as in the classical Shannon–Weaver model. If their model includes six key components (an information source, an encoder, a channel, a noise source, a decoder, and a receiver), Simondon defines information not as a signal that crosses a pre-existing channel but as something that creates the channel itself. Information, in Simondon’s vocabulary, is the event that triggers a process of individuation, the birth of form from potential. More than a concept, information is reframed as a relation, a tension between an energetic system and a form that has not yet been realised.
His definition overturned the dominant paradigm of communication studies of his time (1950s–60s), which treated information as measurable and communication as a transfer of discrete data. Simondon instead redefined communication as a phase transition, a transformation in which both entities involved are altered. To communicate, in his view, is to individuate together.
In his Du mode d’existence des objets techniques (1958), he extends this view to technical objects: machines, as such, are reframed from inert tools to information-bearing beings.
They contain within their structures traces of the operations that generated them, the “memory” of technical evolution, and communication needs to be studied as the dialogue between man and machine, or between machines themselves, in a proto-cybernetic ecosystem in which meaning arises from reciprocity rather than command.
Simondon’s concept of transduction — the process by which a structure propagates within a medium, generating new structures — becomes central to this expanded communication model: where Shannon imagined channels, Simondon envisions media capable of self-modification. The transmission of information thus became inseparable from technical becoming: every act of communication reconfigures its participants and the milieu they inhabit.
Gilbert Simondon’s notion of the milieu — the environment through which individuation unfolds — offers a radical rethinking of the digital ecosystems that support production in BIM. In our context of Information Management for the Construction Industry, let’s see what it means to reinterpret the Common Data Environment as a transductive milieu: a space where information evolves through mutual adaptation between systems, tools, and human agents. Moving beyond linear workflows and fixed schemas, let’s explore how concepts such as interoperability, metadata structures, and management mechanisms can be redesigned to sustain continuous individuation, enabling information to live rather than merely circulate.
Transduction in Practice: how Information becomes Form
1.1. The Lifecycle as Phase Transition: Design, Coordination, Construction, Operation
In Simondon’s vocabulary, transduction describes the process by which a structure propagates through a medium, reorganising both itself and the medium in the act of becoming. It is not the transfer of form from one state to another, but the generation of form through continuous negotiation between potential and constraint.
This notion applies uncannily well to the digital life of a project. An information model — or more precisely, the distributed information system that constitutes it — does not evolve through clear-cut stages but through a series of phase transitions. Design, coordination, construction, and operation — just to mention the biggest phases — are transformations of a single system, but the new tensions and constraints they introduce radically transform the model itself, or at least they should.
In traditional practice, however, the handover between these phases is treated as an exchange of “frozen” information: the model is issued, validated, sometimes even broken to make it less functional for a third-party that’s seen as an enemy, and then passed to the next agent. But what actually occurs is transductive: the information, whether you like it or not, doesn’t simply move but mutates.
Every phase brings its own milieu: different software environments, data structures, sets of responsibilities, and ontologies of meaning. A parameter that in design expressed an intention (“this wall defines a compartment”) becomes in construction a performance specification and in operation a maintenance attribute. This we know, right?
Thinking transductively means acknowledging that information is not stable across these phases, and that it is precisely through these instabilities that the project evolves. Information management, then, includes the design of conditions under which these transitions can occur without rupture. This matches perfectly with the idea of the Common Data Environment as a system designed to accommodate difference and transformation, an ecosystem, a field of propagation that must support not the preservation of information, but its ability to change form while maintaining identity, like a melody that survives its transposition to another key.
1.2. Transductive Processes in BIM
The everyday mechanics of BIM are, in fact, transductive operations, though often conceived in purely procedural terms. Let us examine two of them — versioning and aggregation — and see how we can improve our approach.
1.2.1. Versioning
Versioning represents the archetype of transduction in digital environments. Each revision of a model is not a discrete replacement of the previous one, as the decision of doing “v1.2 → v1.3” vs. “v1.2 → v2.1” carries a logic and hides a deeper ontogenetic process: the model transforms itself through the resolution of internal tensions (design conflicts, new requirements, feedback from site), and the versioning system tracks the genealogy of forms. A minor change in form determines an incrementation of the same series (v1.2 → v1.3), while a major change is signalled through the creation of a new series (v1.2 → v2.1), and once upon a time, we were faced with the choice of determining what’s major. It’s a choice you know very well on a construction site, which often comes down to what generates an extra cost. In BIM, it often comes down to what generates an additional coordination effort. When properly designed, the versioning system enables learning, allowing each iteration to inherit latent knowledge from previous states and to signal major changes.
When the versioning system only allows incremental progression — when it forces every change to be “v1.2 → v1.3” and denies the possibility of opening a new branch such as “v2.1”, just as it happens with Autodesk Construction Cloud — the digital environment loses one of its essential degrees of individuation: the capacity to diverge. What is suppressed is the system’s ability to express discontinuity and acknowledge that the occurred transformation is structural.
In this situation, information can still move, but it cannot differentiate its own history: the genealogy of forms collapses into a flat sequence where every modification is treated as equal, and the result might be an environment that records change without meaning it. It’s a form of informational amnesia, where every iteration overwrites the logic that justified its birth. Without the possibility of a “2.1,” the model cannot signal that a design decision has reconfigured its ontology, that the relation between parts has been reorganised, or that a new set of constraints has entered the system.
D’you follow me so far?
This limitation mirrors a deeper managerial tendency in the industry, in which continuity of control is preferred over continuity of sense. A flattened versioning structure keeps the data orderly but severs the project’s evolutionary memory, and enforces linearity where transduction demands branching, experimentation, and reversible evolution. When this occurs, coordination becomes less about understanding transformations and more about tracing revisions. In short, it becomes a bureaucratic exercise. In Simondonian terms, we could say that such a system arrests individuation at the level of repetition, as it allows information to circulate but not to become. The absence of branching precludes the formation of alternative trajectories, hybrid models, or exploratory forks, the very mechanisms through which a technical object evolves. To design living information systems, we must therefore preserve the possibility of divergence: the digital equivalent of allowing a form to test its new phase before deciding whether it truly belongs to the same lineage.
So, what can we do?
Below is a set of practical, implementable strategies for restoring the possibility of divergence inside Autodesk Construction Cloud, even when the platform’s native versioning model enforces a strictly linear sequence (v1.2 → v1.3 → v1.4…) with no ability to branch into v2.1. These techniques do not “hack” the system: they design a milieu around it, so that divergence can still occur at the level of workflow, file structure, visibility, and meaning.
Solution 1: Using Milestone Segregation through Folders
Concept: if the system cannot branch versions, you branch the context. A new folder becomes the digital equivalent of a new series (the “v2.x” family).
How to do it:
- Structure your file tree so that each major transformation generates a new “lineage folder.”
- Examples:
- 03_Coordination/01_Main Lineage/Models
- 03_Coordination/02_Refactored Series/Models
- 03_Coordination/03_Design Shift_2025-02/Models
- When a major change is needed, copy the last accepted version into the new folder and continue working where you were.
Solution 2: “Frozen Models” or “Frozen Views”
Concept: a frozen view in the model is a fixed snapshot that acts as a “phase delimiter,” much like Simondon’s temporary stabilisations.
How to do it:
- Follow the previous instructions until you have a frozen milestone in a separate folder;
- Lock permissions so it becomes read-only because I’m feeling paranoid;
- In Model Coordination, create a Dedicated View that points to the frozen state.
1.2.2. Aggregation
Aggregation — the assembling of multiple disciplinary models into a coordinated whole that we sometimes call Federation — is another instance of transduction. What takes place here is not the fusion of homogeneous data but a negotiation between ontologies that might appear homogenous (if you managed your naming convention and information architecture well, for instance) but in fact are tragically heterogeneous: architectural, structural, MEP, and environmental models each express reality through their own syntax and logics. The federated environment acts as a transductive interface, where these ontologies adapt to one another, creating new informational consistencies. This is the digital equivalent of Simondon’s phase boundary, the region where new forms of organisation emerge.
So let’s tackle one thing our technological tools allow: moving stuff around when model coordinates don’t match.
The problem: what the “Relocate” Tool Hides
This happens in many federating environments — Navisworks, Solibri, ACC in the Model Coordination module, even some viewer-based pipelines — and the presence of a relocate or transform tool quietly transforms a deep informational problem into a superficial technical gesture. A model arrives with coordinates that do not match the project’s base point; instead of asking why, we ask the technician to shut up and slide it into place. The tool acts like a bandage: it repairs appearance, not meaning. What is lost is precisely the transductive tension that should trigger investigation. In Simondon’s terms, misalignment is not a defect but a signal that two systems are inhabiting different milieux, operating with incompatible constraints or reference points. It is a moment of incompatibility that should drive individuation: “how did this model come to be?”, “what coordinate system was used?”, “what does this tell us about the authoring context?”, “is this team working with outdated or partial references?”
When the relocate command is used uncritically by the BIM Coordinator or — worse — employed as a “shut up, you can solve it on the technical side” tool by their superiors, the federation stage no longer functions as a phase boundary, as a gate check, but becomes a cosmetic merger. The environment appears coordinated, yet its internal logic remains fractured: each model is still living in a different world, simply displayed as if they were one, and we’re left wondering why so many clashes appear. This erases the genealogy of the form — the chain of dependencies and contexts that led to its placement — and breaks the transductive continuity between disciplines.
The inner danger isn’t visual. If one model is consistently relocated during federation, it means that its authors never truly saw the others in their correct spatial or semantic position: they were referencing a displaced environment, designing in a parallel coordinate reality and, from a project-level perspective, this indicates that the architectural milieu and the structural milieu are not actually interacting; they are stacked rather than related. The transduction is faked instead of performed. Information does not propagate; it is forcibly overlaid. This practice also impairs any downstream process that relies on absolute or shared coordinates, from clash detection to point cloud comparison, from site layout to robotic fabrication, as a relocated model becomes a silent anomaly: it looks right inside the federator, but it is wrong everywhere information should have flown back. By relocating, we avoid confronting the deeper question: why is this model unable to align in the first place? The relocate tool disables the project’s self-diagnostic mechanism, preventing the information system from learning about its own inconsistencies.
For an ecosystem to individuate properly, misalignment must be treated as a transductive event: a manifestation of incompatible assumptions that require reconciliation, not concealment. The goal is not simply to see models overlap, but to understand how their authors relate to the shared environment, and whether the project’s digital milieu is functioning coherently across all agents.
Conclusion: what we learned from Simondon
If we take anything away from Simondon this week, it is this: information only becomes meaningful when it is allowed to transform and the tools are paramount in this. An information model that cannot diverge, a federated environment that hides misalignments, a workflow that suppresses phase transitions have one thing in common: they prevent the ecosystem from individuating. They block the very process through which the project learns, adapts, matures, and generates coherence.
Across versioning and aggregation, we saw how digital tools designed for convenience — linear histories, relocate commands, cosmetic federation — can quietly sabotage the project’s capacity for self-understanding: they interrupt the passages where structure propagates, differences surface, and contradictions reveal themselves, strip the system of its memory and its tensions, leaving us with information that moves but does not evolve.
What Simondon offers is a philosophy of information as becoming. From that perspective, BIM is not a set of information models that might or might not talk to each other, but a constantly shifting field where models (intended as the information containers of the ISO) negotiate with each other or fail to. Information management becomes about designing the conditions under which these negotiations can happen without rupture, concealment, or loss.
This is where we stop for today.
No Comments