The four links: the four disciplines of the method

If The thesis of the bridge explains why the paradigm is needed, this chapter sets out how it operates. And it is worth saying from the outset what distinguishes it: it is not a professional who knows a little of each thing, but four disciplines exercised as the four stretches of a single journey, which begins in a person and returns to a person. The data is the medium; the beginning and the end are always human.

The loop, not the list

The mistake would be to read the four disciplines as a menu —a professional who “knows sociology, and also development, and also data, and also AI”. That is dispersion, the opposite of what the paradigm asserts. The four form a single closed journey:

        ┌──────────────────────────────────────────────────────┐
        │                                                      │
        ▼                                                      │
  [1] SOCIOLOGY ─▶ [2] SOFTWARE ENG. ─▶ [3] DATA ENG. ─▶ [4] AI GOVERNANCE
  reads the org    builds the           guarantees the     returns value to
  (human           system               reliable data      the human decision
   problem)        (the hypothesis                          under governance
                    becomes                                 (from data to
                    a tool)                                  the person)
        ▲                                                          │
        │                                                          │
        └──────────────────────────────────────────────────────────┘
              value returns to the person and reopens the cycle

The closing of the loop is what distinguishes the paradigm from an ordinary multidisciplinary team: in a team, information is lost at every handover between specialists who do not understand one another. In integrated practice there is no handover: the hypothesis that arises from reading the organization is the same one that models the data and governs the AI. It is not retranslated —and degraded— at every step; it is preserved.

But the loop is not an assembly line. Any link can send you back to re-read the previous one. If in the third a piece of data “lies” in a way that reveals an unmapped human process, the method prescribes going back to the diagnosis before modeling or automating. If in the second the build exposes an untreated resistance, power and incentives are re-read. If in the fourth the AI does not return value to the person envisioned, both the algorithmic design and the organizational reading that justified it are reviewed. Iteration is what distinguishes a learning method from a cascade flow.

The four disciplines, one by one

Link 1 — Sociology of organizations

What it does. It reads the organization before the technology. It maps power, culture, incentives, real processes (not those in the manual) and resistances to change. It distinguishes the declared problem from the real one.

What it produces. A sociotechnical diagnosis: where it truly hurts, what can be changed and what cannot, who gains and who loses, where AI pays off and where it only destroys value.

Why it matters. Without this reading, everything else optimizes the wrong thing.¹

Guiding question: What do these people do here, why this way, and what breaks if this changes?

Link 2 — Software engineering

What it does. It turns the sociological reading into real software: auditable, maintainable, that people use every day. The social hypotheses become concrete tools.

What it produces. Secure backends (logic that runs on the server, not on the user’s screen), versioned programming interfaces —APIs, contracts that let one system talk to another without breaking on every change—, systems that react to events in real time and, when needed, MCP servers —standardized connection points for AI tools to access data and actions under control—, always with the auditability discipline a regulated environment requires.

Why it matters. It is where the idea materializes or stays in a presentation.²

Guiding question: How is this built so that the person in link 1 uses it without it getting in their way?

Iterative delivery. In 2001, seventeen developers signed the Agile Manifesto: a document that did not invent iteration, but made clear that software must work and that change is learned in contact with those who use it. That does not authorize chaos or sprints without delivery. It demands something concrete: each work cycle must leave an increment someone from the business can try in real work —not a PowerPoint deck describing what “will come”. Three commitments make that principle operational.

First, a shared Definition of Done: an agreed list between builders and future users of what “finished” means. In the bridge, finished is not “the code compiles”; it is “a person in operations can use it in their shift without calling technical support”. Second, a Product Owner —the business person who prioritizes what gets built first— with real availability: if it takes a week to answer “this or that?”, the team builds blind. The practical rule is to be able to prioritize within forty-eight hours. Third, minimum continuous integration (CI): an automatic process that, whenever someone submits a change, checks that the system builds and that basic tests pass. You do not need a heroic Friday evening deploy; that is enough to test the social hypothesis —“does this tool actually change the work?”— without depending on one expert who “knows how to release”.

The opposite is agile theatre: a one-hour daily where fifteen people report to the manager, sprints that are mini-waterfalls with delivery only at the end, retrospectives where everyone says “all good” out of fear. Rituals without increment or learning. That is agile in name only: the organization adopted the vocabulary without adopting the method.

DORA metrics —deployment frequency, lead time from change to production, recovery time after failure, change failure rate— help show whether delivery improves over time. They are orientation, not obsession: on an SME with a single critical server, deploying ten times a day is not the goal; knowing every change runs through tests and someone can roll back if something breaks, is.

Infrastructure-aware. When link 2 chooses where software lives —on owned servers, managed platforms or ready-to-use tools— it is not only choosing technology. It is splitting responsibilities. In IaaS (infrastructure as a service), the organization administers almost everything; in PaaS (platform as a service), the vendor runs the server and you run the code; in SaaS (software as a service), you use an application someone else operates. Moving to the cloud without patching security holes, without tested backups or a plan to leave if the vendor raises prices exports disorder into recurring spend that did not show in the initial budget. The criterion is not fashion —“everyone uses Kubernetes”— but operability: who in this organization can maintain this on a Tuesday at five p.m. when something breaks?

Link 3 — Data engineering

What it does. It guarantees that the data exists, is reliable, accessible and meaningful in its context. It builds the channels through which it flows —capture of changes from source systems, real-time processing when needed, quality rules and lineage that let you trace where each number came from— that feed everything else.

What it produces. Governed data platforms, measurable quality, lineage, data ready to decide on — not only to store.

Why it matters. Without quality data there is no AI: errors are merely automated faster. And data quality is contextual and social, not an isolated technical attribute.³

Guiding question: Does this piece of data say what people believe it says, and does it serve the decision that matters?

Link 4 — AI architecture and governance

What it does. It designs AI solutions that return real value to the person: they amplify their judgment, do not replace it, and do so under auditable rules. It closes the bridge from the data to the human decision.

What it produces. Auditable AI systems, with governance controls, measured by the value they deliver to the person and not by the metric in fashion.

Why it matters. It is where the loop closes or is betrayed: the AI either returns to the person as power, or leaves them out.⁴

Guiding question: Does this AI return decision-making power to the person in link 1, or take it away?

When AI stops suggesting and moves to executing on its own —the agentic step of the ladder—, this link does not put a person to review every case: it puts the judgment into the design and the audit of the rules with which the agent decides —what it resolves on its own, when it escalates to a person, what it leaves on the record—. Human control is not lost; it moves one step up, from the decision to the governance of the decision. The loop closes all the same, but the demand for governance rises with autonomy.

The loop in a case: Distribuidora Norte

A concrete example shows the journey better than any diagram. Distribuidora Norte — a food-and-beverage SME, roughly forty people, several branches inland— arrives with a request already translated into a solution: “we want AI to anticipate which customers we are about to lose”. The temptation is to start from the predictive model. The method starts earlier, in the reading. This case reappears in later chapters with other problems —delivery, dashboards, a pilot that left bad blood—; here what matters is seeing the four links on their first pass.

Link 1 — read the organization. Before touching a single piece of data one must understand what truly happens, and what appears is almost never what was asked for. The salespeople already know who is about to leave —they smell it in a call that cools, in an order that shrinks—, but that knowledge lives in their heads and in no system. And no one has an incentive to share it: here the customer belongs to the salesperson, and releasing the information is releasing power. The real problem was not predictive; it was that valuable knowledge did not circulate. A churn model that ignored that would have competed with the salespeople’s intuition instead of adding to it. And it would have lost.

Link 2 — build the system. From that reading comes the true requirement, which is not “a model” but a tool the salespeople find it worth their while to use: fast, that returns something to them on the spot —a customer about to leave and the probable reason— and that neither exposes nor replaces them. If recording a signal costs three clicks and returns nothing in exchange, no one records it, and everything above collapses. The system is designed, from day one, for the person in link 1.

Link 3 — make the data mean something. Only here does the data come in, and at once the usual problem appears: the field “last purchase” means different things at each branch —one subtracts returns, another does not; one counts the counter sales, another only the deliveries—. To model on top of that without correcting it is to train on sand. Getting the data to say what everyone believes it says is not a technical formality: it is to go back to link 1, because that mismatch is the mark of human processes that never agreed with one another.

Link 4 — return the decision to the person. The model, at last, flags the customers at risk. But the loop closes well only if that flag returns to the salesperson as power and not as surveillance: it reaches them with the why —“this customer lowered the ticket three months in a row”—, it is left to their judgment to act, and the system records what happened afterward in order to learn. Auditable, explainable, theirs. An AI that instead scored the salespeople by how they “manage” their alerts would have reopened, multiplied, the distrust of the beginning.

And there the cycle reopens: the salesperson’s decision —called, recovered, lost— is the new data that sharpens the next reading. The value did not end in a dashboard; it returned to the person, and from the person it begins again.

What is decisive is not that these four steps exist —they exist in any serious project—, but that the same practice runs through them, without dropping the hypothesis at any edge. The reading of link 1 —“the problem is that the knowledge does not circulate because the incentive blocks it”— is the one that keeps governing in link 4. In a chain of specialists that hypothesis would have been lost at the first handover, and the project would have delivered, with impeccable technical neatness, the model that deep down no one had asked for.

Why continuity is the product

Each discipline exists in the market on its own. What is scarce is continuity:

The differential is not mastering four disciplines separately. It is that knowledge does not degrade at the edges, because there are no edges: the chain is traveled as an integrated practice, not as a succession of specialists who pass the problem along.

That is why, in the end, the method is not judged by the four disciplines it brings together, but by a single thing: whether the person at the beginning —the salesperson, the small-business owner, the employee who enters the data— ends up with more decision-making power than they had. If the loop closes in them, it worked. If it closes in a dashboard no one looks at, it was, once again, technology without reading. The four disciplines are the path; the person is the point of departure and of arrival.

Translation artifacts

Translation is not a black box where a problem enters and a system exits. It leaves auditable products besides tacit judgment —documents anyone can review months later and understand what was decided and why. In each project I typically produce three.

A map of actors and interests: who sponsors visibly, who influences from outside the org chart, who gains from the change, who will resist and with what reason. A bilingual glossary: business words on one side —“active customer”, “closed order”— and technical concepts on the other, with definitions operations and systems can share. A sociotechnical risk matrix updated each time the project crosses from one link to another, because what was a theoretical risk in diagnosis can become a production incident. → The diagnostic method, Concepts of our own.

Sensemaking in the loop

Polanyi and Weick are not academic decoration in this method. The loop includes moments of explicitation: meetings where operators and managers build, together, the meaning of the categories and metrics the systems will later use. “What counts as a closed sale?” is not a data question; it is a human agreement question. If no one answers it before modeling, the model inherits categories each area understood differently —and amplifies them. Those moments matter especially when moving from the first link to the third and before deploying any AI that will decide on those categories.

Adoption by user type

The fourth link does not design only for the enthusiast who tolerates friction. Rogers described a curve: innovators, early majority, late majority, laggards. The early majority —people who adopt when something actually works— need the system to work without heroics: no fifty-page manuals, no three extra clicks per task. Late adopters need concrete evidence and low perceived risk: “the person next to me uses it and it went well”. The diagnosis identifies where the organization sits on that curve for each process, not in the abstract. Designing only for innovators produces pilots that die when scaling. → Authors and currents (Rogers).

The loop in resource-constrained organizations

In SMEs and small teams the loop does not vanish: it compresses and becomes more visible. A recent study of twenty-seven UK SMEs (Amanollahnejad et al., 2026) documented three mechanisms that change how each link is traversed:

When automation duplicates effort —part of the work stays in the new tool and part in the same spreadsheet as always— the loop commands returning to link 1 to clarify roles, not link 4 to tweak the model. That is productive misalignment: friction as a signal that something is badly designed, not as moral failure of the team.

In SMEs, digital capacity leakage —turnover, seasonality, people who learn and leave— forces links 2–4 to be designed with low friction and permanent scaffolding: less heroic configuration only the author understands, more defaults validated with operators. A weekend training course does not survive turnover. Each pass of the loop should leave less dependence on one person’s memory and more translation artifacts anyone can read.

Readers who go through the book in order will see how Distribuidora Norte crosses these ideas in diagnosis, hygiene and SME applications; those who enter a single chapter can return here for the full loop.

See also: The thesis of the bridge · Concepts of our own · The bridge applied to small businesses · Bibliography