What the Map Leaves Out

A map earns your trust by being useful. It gets you to the river. It shows you the bridge. After enough successful journeys, the small omission in the corner stops looking like an omission. You assume somebody checked it.

This is a dangerous moment in the life of a map.

In *The World in the Words*, I used the image of a blind cartographer building a map from other people's descriptions. That essay asked how much structure those descriptions might contain. This one asks the practical question that comes after: what would make you willing to follow her directions?

You could ask how the map was made. You could ask whether its maker understands rivers in the same sense that you do. Those are good questions. You would still need to know whether the bridge is there.

Useful for what?

Consider a deliberately simple example. Someone gives you a map of a city with the railway stations omitted. For a walk to the bakery, it may be excellent. For a commuter trying to cross the city before work, its principal feature is an absence.

The map is the same map. The job has changed.

I think we should bring that question into far more conversations about AI: useful for what, under which conditions, with what happening when it fails? It is a less entertaining conversation than deciding whether the machine is a genius or an impostor, and it can end with a workable decision.

A draft you intend to examine is one kind of object. An instruction a system will carry out without you is another. The difference belongs in the design, where a reassuring sentence beneath a button can't stand in for it.

Suppose you ask a tool to turn a long meeting into a list of commitments. (This is a hypothetical workflow, not a client story.) You need names, obligations and enough context to distinguish a suggestion from a promise. A fluent summary might be pleasant to read while quietly losing the only distinction you needed it to preserve.

You could respond by writing a more elaborate prompt. You could also change the shape of the work: require a source passage for each commitment, make uncertain items visible, and let the people responsible confirm them. The second response is a system decision, and it doesn't require pretending the first response is useless.

The parts we can check

My preference is to put the checks where the consequences are.

For generated code, that may mean tests, review and a place to run the change without exposing a customer to it. For a document, it may mean a reviewer who knows the subject and can reach the underlying sources. For a proposed action, it may mean a person who can decline it before anything happens.

These are design choices for a particular situation; there is no universal recipe. A check that nobody has time to perform is a decoration. A reviewer who cannot inspect the evidence is being asked to approve a tone of voice. A fallback that has never been exercised is an encouraging paragraph in a document.

The tool and the check should be designed together. So should the ordinary route out of the system when it becomes inconvenient, expensive or unreliable. A business should not have to rediscover how it operates in order to switch off an assistant.

Keep asking how it works

None of this requires us to stop being interested in what these models might be learning. I remain interested in the possibility that a great deal of the world's structure is recoverable from descriptions of it. I also want the invoice to contain the right number.

Those interests can inhabit the same person. They have to inhabit the same engineering practice.

An impressive capability is an invitation to investigate. It does not decide where we should connect it, whose judgment it should replace, or how much uncertainty a particular business can afford. Those decisions still need people willing to become specific.

The cartographer may be extraordinary. Before you drive a truck over the bridge, somebody should look at the bridge.