Notes on the iceberg.

At Solutions-E, we designed trading floors. This was the early 2000s, for hedge funds and institutional shops that were configuring new offices or reconfiguring existing ones. The work started with a floor plan. The floor plan was always the wrong starting point.

Not wrong because it was inaccurate. The square footage was right. The desk counts were right. Wrong because the floor plan described the official layout of a process, and the process that actually ran was not the official one.

The floor plan showed which positions sat where and how many screens each position had. What it did not show: that two of the traders never sat at their assigned positions during market hours, they moved the floor and talked to people. That three of the screens always displayed the same data feed, because someone had configured them that way once and no one had changed it. That the actual decision-making on certain positions happened in the first twenty minutes of market open, in a conversation between three people, after which those three would operate independently for the rest of the day with no formal coordination at all.

Design to the floor plan, and you have designed for a process that doesn't run. Six months later, someone has moved a monitor to face the hallway, because that's where the information they actually need comes from.

What any map gets wrong

A process map is an abstraction. It captures what's relevant at the scale of the question it was built to answer. The problem in complex organizations is that the question being answered (how does this process work?) is not the same as the question that matters (how are these people actually working?).

A map records the formal logic: the stated steps, the documented handoffs, the official approvals. What it cannot record is what has grown up around, through, and sometimes in spite of that logic over the years since the map was drawn.

In every organization I've worked with over the past thirty years, the informal layer is where the actual work lives. The workarounds that became the workflow, because the official process couldn't handle something real. The edge case that came up twice, got handled quietly, and became the default handling. The approval that isn't in the RACI but whose absence stops everything. The report that nobody reads but that everyone is afraid to cancel, because someone once asked for it and the asking never formally stopped.

This isn't dysfunction. It represents accumulated learning: the organization's response to everything the documented process didn't anticipate. In most cases it is the most reliable part of the system, precisely because it was forged under actual operating conditions rather than designed in a conference room. It is also the part most likely to survive a technology change while appearing to have been replaced.

What the AI moment changes

I have written elsewhere about the discovery problem in platform migration: the work of understanding what a system actually does before you try to replace it, why that work is more consequential than the data conversion, and why it is more consistently underestimated than any other phase. None of that has changed.

What has changed is the consequence of skipping it.

When a human practitioner encounters something that isn't in the documentation, something usually surfaces the gap. A question gets asked. An output looks wrong to someone who knows what right looks like. The person who has run this process every morning for four years notices that the new system is handling a specific situation differently from the old one. The informal logic shows itself because the humans who rely on it are still in the room, and humans can say: wait, that's not how we do it.

An agent trained on the documented process has no such signal. It learned the map. When it encounters the territory below the waterline, it applies the documented logic to the undocumented situation with exactly the same confidence it applies everywhere else. There is no hesitation, no flag, no pause to consider whether this is the kind of situation the documentation didn't cover. The wrong answer arrives looking like the right answer, at the scale and speed the agent operates at, every time that undocumented situation recurs.

The agent doesn't know it's off the map.

The iceberg hasn't gotten smaller. The navigator has lost the ability to feel the hull.

What I keep

The answer is not better documentation. I have read enough post-mortems to know that "improve documentation" is how organizations explain away a structural problem they are not ready to solve. Documentation has a shorter shelf life than the workflows it describes. The informal layer will always outrun the writing.

What I keep, instead, is a sharper insistence on discovery before deployment. Not alongside it, not after it. Before. Every agent deployment is a migration. The question "what does this process actually do?" requires an honest answer before the agent is trained, not after it begins producing confident wrong answers at scale.

The discovery work has not changed. The cost of skipping it has.

// DG