DRT Week 11A. Assemblage thinking, v2
Why causal structure lives in interfaces, seams, and intensity gradients
The attractive but wrong simplification
When an organization is under pressure—market shifts, operational volatility, regulatory heat, “AI transformation”—the most seductive simplification is the org chart. It feels concrete. Boxes imply control. Reporting lines imply accountability. Reorgs look like action.
So leaders tell a familiar story: “We have a coordination problem.” The implied fix is also familiar: restructure, rename roles, add committees, redraw escalation paths, install a new “owner” function. And when things still don’t work, the explanation slides toward a softer register: culture.
This is not naïve. It is just a category error. Org charts describe who reports to whom. They do not describe what causes what.
Why it fails (technically and philosophically)
Causality in socio-technical systems is rarely housed in boxes. It is housed in constraints and translations.
If you want the “equations” of an operating system, you do not look at titles. You look at:
Interfaces (where data becomes a decision; where a decision becomes an action).
Evidence rules (what is permitted to count as “proof,” who can introduce it, and when).
Incentives and liabilities (what is punished, what is rewarded, who absorbs downside).
Intensities (time pressure, convenience gradients, status asymmetries, reputational exposure).
This is why a system can “obey” the org chart while disobeying strategy. In dynamic relationality terms, the actual-real is carried by operational flows and constraints; the virtual-real is carried by lived dispositions and trust; the virtual-possible is carried by narratives and legitimacy conditions; the actual-possible is carried by platforms, workflows, and architectures that can be instantiated and scaled. The org chart mostly lives in a thin slice of the last two, and it routinely mistakes that slice for the whole.
A technical way to say it, without getting lost in formalisms: the organization behaves less like a hierarchy and more like a network with weighted edges. The weights are not decorative. They are causal: an “override” edge with high liability and low clarity will dominate outcomes more than a clean reporting line. A “handoff” edge under intense time pressure will create drift even if everyone is competent and well-intentioned.
The upgraded concept: Assemblage Map v2 (now with intensities and seam logic)
Repair: keep the assemblage map—but upgrade what you think it is a map of.
Assemblage Map v1 (Week 3) taught the right unit: heterogeneous components linked by relations.
Assemblage Map v2 (Week 11) targets the causal substrate: interfaces, seams, and intensities.
Two definitions make the upgrade operational.
Interface: the mechanism that turns one domain’s “output” into another domain’s “input” (a workflow state change, a dashboard threshold, an approval gate, a data schema, a policy template, a contract clause).
Seam: a specific kind of interface where success criteria flip—because the decision crosses into a different regime of meaning, risk, or evidence. Seams are where drift and conflict originate, not because people are “cross-functional,” but because translation is under-designed.
This is the Week 11 claim that tends to irritate, and then help:
“Culture” is often a proxy for unobserved edge dynamics and intensity gradients.
Culture talk becomes dominant precisely when the organization cannot see the seams that are actually governing behavior.
Minimal working model (a diagram-in-words you can run in a room)
Pick one decision that matters (not a “program”): e.g., auto-execution thresholding, exception approval, replenishment re-routing, credit risk escalation, safety gating.
Now do three things:
Draw the map as nodes + edges.
Nodes are not departments; they are decision-relevant entities (people, teams, platforms, policies, external constraints). Edges are verbs: recommends, routes, approves, overrides, audits, executes, blocks.Tag edges with intensities.
For each edge, add 2–3 intensity tags from a short menu:
Time pressure (windowing, seasonality, “must ship”)
Liability (who carries downside if wrong)
Convenience (frictionless defaults vs painful work)
Status (whose judgment is socially privileged)
Cost visibility (who sees the true trade-off)
Mark seams explicitly.
A seam is an edge where at least one of these flips:
evidence standard (“what counts”)
accountability (“who answers”)
objective function (“what ‘good’ means”)
permissible action set (“what can be done here”)
If you do only this, you will already see why org charts can look tidy while the system remains ungovernable.
Executive implications (what changes once you see seams and intensities)
Implication A — Strategy lives where decisions travel, not where charts are drawn.
Palantir is a useful primary case because its operational ontology is, in effect, a discipline for making dependencies and decision travel explicit. In Creative Transformation of Organizational Ecosystems’ terms, it acts as a structural translator across domains that would otherwise remain “siloed.” When the ontology is good, a change in the operational layer can be coherently interpreted at executive altitude—and vice versa—because interfaces have been designed rather than improvised. That is not “data integration.” It is seam governance by design.
Implication B — Intensities, not intentions, determine whether human–AI coupling stabilizes.
Consider Deere. The dominant outcomes are often set less by org boundaries and more by the field/ops/platform edges: where telemetry becomes advice, where advice becomes action, where exceptions become escalations. Under tight agronomic windows, time pressure becomes a strong field: it pulls decisions toward automation defaults. If override is high-liability and low-clarity, the system will “choose” automation even when humans disagree—because the intensity gradient is stronger than the training deck.
Implication C — Decentralization only works if seams are engineered, not romanticized.
Haier’s micro-enterprise logic can be read as a node-level design: many small accountable units close to users. But the decisive question is not “how many micro-enterprises.” It is: what interfaces coordinate them without smothering them? Micro-enterprises are only as entrepreneurial as the seams they are allowed to traverse. If the platform-level evidence rules, incentives, or value-sharing mechanisms are mis-specified, the network will re-centralize informally—often through status and resource asymmetries rather than formal authority.
Implication D — Retail transformation succeeds or fails at store-level seams.
Lowe’s is explicitly building a Palantir-and-NVIDIA-enabled, real-time decision layer for supply chain and rolling out generative assistants. The causal question is not “AI adoption.” It is seam design:
When a store-level constraint conflicts with an optimization recommendation, what counts as evidence?
Who can override, and with what audit trail?
Does time pressure convert “recommendations” into de facto commands?
This is where corporate narratives about “customer-ready AI” either become lived capability—or become exception queues with better branding.
Guardrails (how not to break the repair)
Do not map the universe. Map one decision and the few seams that govern it.
Do not treat intensities as “soft.” Liability and time pressure are as causal as code.
Do not blame interpersonal conflict first. Cross-functional pain is often interface debt.
Do not confuse visibility with control. Dashboards can expose seams—or cosmetically hide them.
If Week 3 said, “Name the assemblage or you cannot govern,” Week 11 sharpens it: name the seams and intensities—or you will govern stories while the system governs you.