The four links: the four disciplines of the method

Four excellent specialists can, between them, deliver the wrong system. Whoever read the organization hands in a report, and someone files it. Development builds what it understood of the requirement. Data engineering models without knowing which decision it serves, and the AI is designed around what the technology allows. Nobody did bad work. What got lost was the thread: the hypothesis about the people thinned out at every handover.

If The thesis of the bridge explains why the paradigm is needed, this chapter shows how it operates. Its defining feature is not a professional who knows a little of everything. It is four disciplines practiced as stretches of a single journey, which begins with a person and returns to a person. Data is the medium; the beginning and the end are always human.

The loop, not the list

It would be a mistake to read the four disciplines as a menu. The professional who “knows sociology, and also development, and also data, and also AI” is scattered, which is the opposite of what the paradigm claims. 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

Closing the loop is what sets the paradigm apart 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 comes from reading the organization is the same one that later models the data and governs the AI. Because it is not retranslated at each step, it does not degrade.

That does not make the loop an assembly line. Any link can send you back to reread the previous one. If in link 3 a piece of data “lies” in a way that reveals an unmapped human process, the method calls for going back to the diagnosis before modeling or automating. If in link 2 the build exposes a resistance nobody worked through, power and incentives are reread. If in link 4 the AI does not return value to the intended person, both the algorithmic design and the organizational reading that justified it are reviewed. That iteration is what distinguishes a learning method from a waterfall.

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 the ones in the manual) and resistance to change. It distinguishes the declared problem from the real problem.

What it produces. A sociotechnical diagnosis: where it truly hurts, what can change 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 do they do it this way, and what breaks if it changes?

Link 2 — Software engineering

What it does. It turns the sociological reading into real software: auditable, maintainable and used every day. Social hypotheses become concrete tools.

What it produces. Secure backends, that is, the logic that runs on the server rather than on the user’s screen. Versioned programming interfaces (APIs), which are 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 through which AI tools reach data and actions under control. All of it with the auditability discipline a regulated environment demands.

Why it matters. It is where the idea takes shape or stays in a slide deck.²

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. The document did not invent iteration, but it made clear that software has to work and that change is learned in contact with the people who use it. That does not license chaos or work cycles (sprints) with nothing delivered. It demands something concrete: every cycle should leave an increment that someone from the business can try in their real work, not a presentation describing what “is coming”. Three commitments make that principle operational.

The first is a shared Definition of Done: a list agreed between those who build the system and those who will use it about what “finished” means. In the bridge, finished is not “the code compiles” but “someone in operations can use it during their shift without calling for technical help”. The second is a Product Owner with real availability, that is, the business person who decides what gets built first. If they take a week to answer “this or that?”, the team builds blind; the practical rule is being able to prioritize within forty-eight hours. The third is minimum continuous integration (CI): an automatic process that, every time someone submits a change, checks that the system builds and that the basic tests pass. There is no need for a heroic Friday-evening deploy. That is enough to test the social hypothesis (“does this tool actually change the work?”) without depending on a single expert who “knows how to release”.

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

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

Infrastructure-aware. When link 2 chooses where the software lives (owned servers, managed platforms or ready-made tools), it is not only choosing technology: it is allocating responsibilities. Under IaaS (infrastructure as a service), the organization runs almost everything. Under PaaS (platform as a service), the vendor takes care of the server and the organization, of the code. Under SaaS (software as a service), the organization uses an application someone else operates. Moving to the cloud without patching security holes, without tested backups and without a plan to leave if the vendor raises prices turns disorder into a recurring cost that was not in the original budget. The criterion is not fashion (“everyone uses Kubernetes”) but operability: who in this organization can keep this running on a Tuesday at five p.m., when something breaks?

Link 3 — Data engineering

What it does. It ensures that data exists and is reliable, accessible and meaningful in its context. It builds the channels through which data flows and that feed everything else: change capture from source systems, real-time processing when needed, quality rules and a lineage that lets anyone trace where each number came from.

What it produces. Governed data platforms, measurable quality, lineage and data ready for decisions, not just for storage.

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

Guiding question: Does this 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 that person’s judgment rather than replacing it, and they do so under auditable rules. It closes the bridge that runs 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: AI either returns to the person as power, or leaves them out.⁴

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

When AI stops suggesting and starts executing on its own, on the agentic step of the adoption ladder, this link does not assign a person to review every case. It places judgment in the design and audit of the rules by which the agent decides: what it resolves on its own, when it escalates to a person and 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 still closes, but the demand for governance grows with autonomy.

The loop in a case: Distribuidora Norte

A concrete case shows the journey better than any diagram. Distribuidora Norte, a food-and-beverage SME with roughly forty people and several branches in the provinces, arrived with a request already translated into a solution: “we want AI to anticipate which customers we are about to lose”. The temptation was to start with the predictive model. The method starts earlier, with the reading. What follows is the loop’s first pass through that company.

Link 1 — read the organization. Before touching any data one has to understand what is really going on, and what turns up is almost never what was asked for. The salespeople already know who is about to leave. They sense it in a call that cools off or an order that shrinks, but that knowledge lives in their heads and in no system. Besides, nobody has an incentive to share it: in this company the customer belongs to the salesperson, and giving up the information means giving up power. The real problem was not predictive; it was that valuable knowledge did not circulate. A churn model that ignored this would have competed with the salespeople’s intuition instead of adding to it, and it would have lost.

Link 2 — build the system. The true requirement comes out of that reading. It is not “a model” but a tool the salespeople find worth using: fast, giving them something back on the spot (a customer about to leave and the likely reason) and neither exposing nor replacing them. If recording a signal takes three clicks and returns nothing, nobody records it, and everything above collapses. That is why 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 the usual problem shows up at once. The “last purchase” field means different things at each branch: one subtracts returns and another does not; one counts counter sales and another counts only deliveries. Modeling on top of that without fixing it is training on sand. Getting the data to say what everyone believes it says requires going back to link 1, because that mismatch is the trace of human processes that never agreed with one another.

Link 4 — return the decision to the person. At last, the model flags the customers at risk. But the loop closes well only if that flag reaches the salesperson as power and not as surveillance. It arrives with the reason (“this customer’s ticket has dropped three months in a row”), acting on it is left to their judgment, and the system records what happened next in order to learn. The tool is auditable, explainable and theirs. An AI that instead scored the salespeople on how they “manage” their alerts would have reopened, and multiplied, the distrust of the beginning.

That is where the cycle opens again. 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 went back to the person, and from there the loop starts over.

What is decisive is not that these four steps exist, since they exist in any serious project. What is decisive is that the same practice runs through all of them, without dropping the hypothesis at any edge. The reading from link 1 (“the knowledge does not circulate because the incentive blocks it”) still governs 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, a model nobody had really asked for.

Readers who go through the book in order will see Distribuidora Norte cross these ideas in diagnosis, hygiene and SME applications. Those who enter through a single chapter can come back here for the full loop.

Translation artifacts

Translation is not a black box where a problem goes in and a system comes out. Besides tacit judgment, it leaves auditable products: documents anyone can review months later to understand what was decided and why. Every project leaves at least three.

The first is a map of actors and interests: who sponsors openly, who has influence from outside the org chart, who gains from the change and who will resist it, and for what reason. The second is a bilingual glossary, which sets the business’s words (“active customer”, “closed order”) on one side and the technical concepts on the other, with definitions that operations and IT can both use. The third is a sociotechnical risk matrix updated every time the project moves from one link to the next, because what was a theoretical risk during diagnosis can become a production incident. → The diagnostic method, Concepts of our own.

Sensemaking in the loop

The glossary is not written alone. Polanyi and Weick, with tacit knowledge and the collective construction of meaning (sensemaking), serve a practical purpose in this method. The loop includes moments of explicitation: meetings in which operators and managers jointly build the meaning of the categories and metrics the systems will later use. “What counts as a closed sale?” looks like a data question, but it is a question of human agreement. If nobody answers it before modeling, the model inherits categories each area understood in its own way, and amplifies them. These moments matter most when moving from link 1 to link 3, and before deploying any AI that will make decisions on those categories.

Adoption by user type

Nor does link 4 design only for the enthusiast who puts up with friction. Rogers’ curve distinguishes innovators, early majority, late majority and laggards. The early majority, who adopt once something actually works, need a system that runs without heroics: no fifty-page manuals, no three extra clicks per task. Laggards need concrete evidence and a risk they perceive as low: “it worked for the person next to me”. The diagnosis places the organization on that curve for each process, not in the abstract, because designing only for innovators produces pilots that die when they scale. → 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 27 UK SMEs (Amanollahnejad et al., 2026) documented three mechanisms that change how each link is traversed:

When automation duplicates effort, because part of the work stays in the new tool and part in the same old spreadsheet, the loop sends you back to link 1 to clarify roles, not to link 4 to tweak the model. This is a case of productive misalignment: friction works as a signal that the design is not right yet, not as a moral failing of the team.

Digital capacity leakage (turnover, seasonality, people who learn and leave) also forces links 2 to 4 to be designed with low friction and permanent scaffolding: less heroic configuration that only its author understands, more defaults validated with the people who operate the system. A weekend crash 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.

Why continuity is the product

Each of these disciplines can be hired separately on the market. What is scarce is continuity:

The differentiator does not lie in mastering four disciplines separately. It lies in knowledge not degrading at the edges, because the chain is traveled as one integrated practice and not as a succession of specialists passing the problem along.

That is why, in the end, the method is judged not by the disciplines it brings together but by a single thing: whether the person at the start (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 on them, it worked. If it closes on a dashboard nobody looks at, it was once again technology without reading. The four disciplines are the path; the person is both the point of departure and the point of arrival.

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