A record of how it behaves

When E31 Consulting leaves a use case running, it leaves a record beside it. Not a report written at the end, but the running record Agency keeps of every run: what the agent read, which route it called, where it waited for a person, who approved, and which version was running at the time. The site owns this record from the first run, and it is the plainest account of how the thing actually behaves.

What a run record contains

Each run is one entry. The entry names the version, so the operating picture for that run can be read back. It lists the material the agent retrieved from the corpus to produce its result. It lists each declared route it called and what it sent. Where the version marks an approval point, the entry shows which named role approved, or that the run stopped there and waited.

It does not contain guesses about intent or scores invented after the fact. It is the sequence of things that happened, in order, tied to the version that allowed them.

Why the practice hands it over as part of the work

Two people need this record more than anyone else: the operator on the next shift and the person who has to answer for the use case to someone outside the floor.

For the operator, the record is how to tell the difference between the agent doing something wrong and the agent doing exactly what the version said. A disposition that looks odd is explained in the record: here is the document it read, here is the bound it honoured, here is the role that approved. The fix, if one is needed, is a new version, and the record shows which part to change.

For the person answering to an auditor, the record is something an auditor can read. It does not claim anything; it shows what the agent could reach and what it did reach, run by run. The practice does not make compliance claims on the customer's behalf, and it does not need to, because the record speaks for itself.

Building so the record is useful

A record is only as readable as the version it describes. The practice makes design choices during the engagement with the record in mind.

Approval points are placed where a person would actually want to have been asked, so the record shows a meaningful stop rather than a rubber stamp. Routes are declared narrowly, so the list of calls in a run is short and legible. The corpus is organised so that the material an agent retrieves can be named in plain terms, not as an opaque chunk.

During a forward-deployed engagement the desk reads the record with the engineers as the work proceeds. The test is always the same: whether the person who owns this outcome can look at this entry and understand it. Where they cannot, the version is changed until they can.

Where the record stays

The record is on the appliance, in the customer's rack, inside the posture the customer chose. On an air-gapped site it never leaves. On a connected site it is reached through the systems the customer already secures. The practice holds no copy and has no path to one after the engagement ends.

That is part of what what the customer keeps means in practice: the record of every run is theirs, back to the first test case the engineers ran on site.

Using it after the handoff

The record is the site team's first tool when something changes. Before publishing a new version, they can read how the current one behaved on the cases that matter. After publishing, they can compare. When a new desk asks for the same agent, the record shows what the agent has been doing for the first desk and where it has been waiting for people.

It is also how the site decides when a change is big enough to scope as a new project rather than make themselves. If the record shows a pattern the current version cannot express, the record is the brief. That path is described in after the engagement: support and the next version.