The operating picture you keep

A use case that runs on your appliance after the engineers have gone needs more than working code. It needs a picture the site can read: who may publish a change, which model the work runs on, where a person has to approve before anything lands, and which systems it is allowed to call. E31 Consulting leaves that picture inside the published version, so it stays true when nobody who built it is in the room.

What the picture holds

The operating picture has four parts, and each one answers a question an operator will ask on an ordinary morning.

Who may publish. A version is published by a named role, and the version records that role. When someone asks why the desk started behaving differently, the answer begins with who published the change and when.

Which model it uses. The version names the model the work runs on and any adaptation that has been applied to it on site. If the model is changed, that is a new version, not a quiet swap.

Where a person approves. Some steps wait. A draft waits for the desk to sign it; a call to a system of record waits for the role that owns that system. The version marks those points, and Agency enforces them as bounds rather than as advice.

Which systems it may call. Routes to on-premise systems are declared in the version. A route that is not declared does not exist for that agent. The list is short enough to read aloud.

Why it lives in the version and not in a binder

Documentation written beside a system drifts away from it. The binder says one thing, the running configuration says another, and by the time anyone notices, the engineers who could reconcile the two have moved on.

The practice puts the picture in the version because the version is what actually runs. Publishing is the act that makes a change real on the appliance, and the picture is read from the same object that publishing produces. There is no second copy to fall out of date.

This also means the picture is complete by construction. A version cannot be published without a publishing role, a named model, declared routes, and marked approval points, because Agency will not publish it otherwise. The engineers do not have to remember to write it down.

Reading it without an engineer

The operating picture is meant for the people who own the outcome, not for the people who built the stack. A plant manager should be able to open the current version and see that the quality desk approves before a disposition is written back, and that the agent reads the inspection corpus and nothing else.

During a forward-deployed engagement the engineers walk the desk through the picture as it takes shape, so the words in it are the site's words. In an in-house project the picture is part of what is handed back, and the handoff is not finished until the operators can explain it in their own terms. See the published version and the notes to change it for what sits alongside it.

When the picture changes

Sites change. A new system of record arrives, a role is renamed, a second desk wants the same agent with a different approval. Each of those is a new version, published by the role that holds that right, and the picture updates with it.

Because every version carries its own picture, the history is also readable. The site can look at the version that was running on a particular shift and see exactly who could publish it, what it ran on, where it waited, and what it could reach. That is the same record described in a record of how it behaves, seen from the configuration side rather than the run side.

The practice treats the picture as the first thing the site keeps and the last thing the engineers touch. If an engagement ends and the operators cannot read the picture of what they now own, the engagement is not over.