Skip to content
ELEMENT 31

Glossary: the packet

The packet is the unit of work that arrives at a desk: what it contains, what a good result looks like, which step a person still takes, and where the result lands. Engineers learn the real one on site.

· 2 min read

IN SHORT

The packet is the unit of work that arrives at a desk and has to be handled: what it contains, what a good result looks like, which step a person still has to take, and which system the result has to land in. Forward-deployed engineers learn the real packet by sitting with the people who handle it, and it shapes the corpus, bounds, approval points, and routes of the version.

The packet is the unit of work that arrives at a desk and has to be handled: what it contains, what a good result for it looks like, which step a person still has to take, and which system the result has to land in. Forward-deployed engineers learn the real packet by sitting with the people who handle it.

Why it matters

A use case built from a description of the packet is built from a guess. The description says a request arrives with the fields filled in; the real packet arrives with the fields half filled and a note from the sender. The description says the result goes to the warehouse system; the real result goes to the warehouse system after a supervisor has looked at it.

Learning the real packet is the difference between an agent that handles the work and an agent that handles an idealised version of it. It is also where the approval points come from: the steps a person still takes today are the steps a person should still approve in the version.

How it works here

In a forward-deployed engagement the engineers watch packets arrive and watch the desk handle them. They note what varies, what is routinely wrong, what a good result looks like to the person who signs it, and which system of record it has to reach. That knowledge becomes the corpus the agent reads, the bounds Agency enforces, the approval points marked in the version, and the routes Substrate declares.

In an in-house project the packet is described in the scope. The practice asks for examples rather than a specification, and for the names of the people who handle them, so that the handoff can be checked against real cases.

The packet also shapes the notes. Operators are taught to change the use case in terms of the packet they know: what to do when a new kind of request starts arriving, what to do when the system it lands in changes. The run record describes each run in the same terms, so an operator can read it and recognise the packet.

Questions this raises

Why not work from a specification of the packet?
Specifications describe the packet as it should arrive. The real one arrives with fields half filled and a note from the sender, and goes to the system of record only after a supervisor has looked at it. Building for the real packet is what makes the agent handle the actual work.
How does the packet affect the approval points?
The steps a person takes today, such as a supervisor checking a disposition before it is written back, are the steps a person should still approve in the version. Learning the packet is how those steps are found.
Does the packet matter for an in-house project?
Yes. The packet is described in the scope, and the practice asks for examples rather than a specification, plus the names of the people who handle them, so the handoff can be checked against real cases.

KEEP READING

Related.