InquirySpec - Narrative Arc: Translate the architecture into situated work: initiator, target, action, role, context, artifact, and consequence. - Paradigm Shift: The reader learns to see work as structured interaction rather than vague productivity. - Reader Exit State: The reader can map a work event without pretending the machine understands everything globally.

How We Actually Do the Work

Most work systems are very good at showing that something moved.

A ticket changed state. A meeting note was posted. A model generated a summary. A metric went up. A document was approved. A handoff happened somewhere in the thread. Everyone can point to the visible event, so the system treats the work as if it has become legible.

But motion is not yet work.

Work is situated action. Someone or something acts, toward a target, through an artifact, inside a field of constraints, with some level of authority, and with consequences that eventually return. If those relations are not preserved, the system may still move quickly, but it cannot explain what it is doing. It can only say that a field changed, a message was sent, or a status was marked complete.

That is why this Field Guide has to slow down before it talks about sophisticated workflows. The first question is not "How do we automate more?" It is "What is actually happening when work happens?"

The Action Is Not the Checkbox

Imagine a team under deadline pressure. A manager asks for a risk update. Someone opens the dashboard, sees that the risk count is lower than last week, and posts: "Risk is improving." The project moves forward.

That sentence may be useful. It may also be dangerously thin.

Who produced the underlying risk count? What counted as a risk? Was the decrease caused by actual repair, by reclassification, by delayed reporting, by a change in threshold, or by people learning that naming risks creates after-cost? What action did the posted sentence authorize? Did it support inquiry, release a decision, close a concern, or merely keep the conversation moving?

The checkbox says "risk update complete." The work record should say much more: actor, target, artifact, context, warrant, and consequence.

This is the public surface of The Anatomy of Action. Work is not only the visible move. Work is the accountable relation around the move. A message, dashboard cell, patch, decision memo, generated answer, transcript, or approval is not the situation itself. It is an artifact carrying part of the situation forward.

When the artifact is treated as the whole situation, the system becomes lighter to operate and harder to repair.

Who Or What Acted?

The first repair is to stop assuming that the actor is obvious.

Sometimes the actor is a person. Sometimes it is a team, a workflow, an organization, an automated process, a model, a sensor, or a policy that forces a path by making other paths expensive. A status update from a junior analyst, a reviewed standard from a governance group, and an automated risk flag can all appear as text in the same interface. They should not carry the same authority.

Persona Alignment is the discipline of situating the acting entity before interpreting its output. In public terms, it asks:

Who or what produced this artifact?

At what scale was it acting?

What could it perceive?

What was it authorized to do?

What constraints shaped the output?

What feedback would correct it if it failed?

This matters because work often breaks at the scale boundary. An individual gets blamed for a field condition. A team promise is treated as if it were an organizational standard. A model answer is read as if it had institutional authority. A sensor reading is handled like a human judgment, or a human report is handled like neutral telemetry.

These errors do not require bad faith. They are the ordinary result of systems that do not preserve actor position. Coordination is expensive. Labels are cheap. Under pressure, the system reaches for the cheap label: "the team," "the customer," "the model," "the policy," "the data." The label keeps the workflow moving, but it drops the position from which the signal emerged.

Once that position is gone, the next actor has to guess.

What Was Targeted?

An action also has a target. This sounds simple until the work becomes complex.

"Review the plan" could mean reviewing a document, a budget, a risk exposure, a staffing assumption, a customer burden, a compliance claim, or the shared confidence of the team. "Fix the onboarding issue" could target a user interface, a training gap, an eligibility rule, a handoff script, a broken metric, or a deeper mismatch between policy and practice.

When the target is vague, the action cannot close cleanly. People may do real work and still miss each other because they were acting toward different objects. One person fixes the document. Another expected the process to change. A model summarizes the text. The team needed the operational constraint extracted. The artifact says "done," but the field still carries the unresolved burden.

This is one reason generic productivity language fails. It talks about tasks, priorities, ownership, and deadlines, but often skips the ontology of the target. A task can be complete while the target remains unchanged. A deadline can be met while the wrong object was acted on. Ownership can be assigned while the actor lacks the authority or capacity to move the thing that actually matters.

The action map forces specificity. What was supposed to change? A record? A person's understanding? A rule? A relation between teams? A runtime state? A decision boundary? A future commitment?

If the target cannot be named, the work is not yet ready to move as accountable action.

What Did the Artifact Carry?

Every work system depends on artifacts. Notes, tickets, metrics, diagrams, prompts, emails, pull requests, policies, ledgers, dashboards, and model outputs let people coordinate across distance and time. They are necessary. The problem begins when the artifact is asked to carry more than it contains.

A transcript is not the meeting. A metric is not the condition. A summary is not the source. A decision memo is not the full debate. A model output is not the domain. A green status light is not closure.

Artifacts work by leaving things out. That is not a flaw. It is how any signal becomes movable. A useful artifact translates a messy situation into a form that another actor can handle. The question is whether the translation preserves the context needed for the next move.

For example, a model can turn a long conversation into three action items. That can be useful if the receiving system knows what the summary is allowed to do. Is it a memory aid? A proposed interpretation? A draft for review? A commitment? A release note? If the artifact does not carry that role, the next actor may treat a rough synthesis as an authorized decision.

The same pattern appears in ordinary human work. A dashboard number may be a prompt for inquiry, but it gets used as a performance verdict. A quick note may be intended as a hypothesis, but it gets copied into a plan. A team lead may say "looks okay" as a local assessment, but the phrase travels upward as organizational approval.

The artifact did not lie. The route stripped away its role.

Capability Is Part of the Work

A humane work system does not pretend that action is free.

People have limited attention, working memory, reserve, time, authority, and domain contact. Teams have coordination bandwidth. Organizations have inherited routines and delays. AI systems have context windows, training limits, retrieval boundaries, and no direct embodied contact with the field. Sensors perceive some variables and ignore others. Workflows can route state but cannot decide what a situation means unless the meaning has been modeled and reviewed.

This is where digitality contact knowledge matters, even if the phrase stays mostly below the surface. Effective work requires contact with the domain, contact with the digital medium, and contact with the learning or review process around the artifact. Tool fluency is not enough. A person can know how to click through the system and still misunderstand what the signal can support. A model can process the text and still miss the environmental friction that produced it.

Capability also changes under load. A person with high reserve may handle ambiguity, negotiate scope, and preserve context. The same person under high demand and low reserve may rely on the lightest artifact that keeps the workflow moving. That does not make the person careless. It means the field has changed the available policy.

The lesson is not to moralize every miss. The lesson is to design work so that critical context does not depend on private stamina.

The System Should Carry More Than the Actor

At this point the shape of the problem is visible. Accountable action asks for more than most actors can carry alone.

The actor has to know the target. The artifact has to preserve role and warrant. The context has to travel far enough to be useful. The capability constraints have to be visible. The consequence has to return. The next actor has to know whether they are reading evidence, instruction, hypothesis, commitment, or closure.

If all of that lives in one person's memory, the system is fragile. If all of it is assumed to live inside a model, the system is pretending. If all of it is pushed into a manager's judgment, the system will drift toward bottlenecks and plausible shortcuts.

This is why the Field Guide later spends so much time on the Workflow Engine. The point is not to build an artificial worker that magically understands everything. The point is to build a support field that carries state, routing, memory, review, access, and consequence so bounded actors can make situated judgments without being forced to become the whole system.

Supported agency is more realistic than heroic agency.

A person should not have to remember every prior decision to make a local judgment. A model should not have to infer governance from scattered text. A team should not have to reconstruct the history of a risk from chat fragments. A reviewer should not have to guess whether a generated artifact is evidence, proposal, or approved action.

The work system should carry enough structure that each actor can do the part they are actually positioned to do.

Consequence Completes the Work

An action is not mature because it was executed. It becomes assessable when something returns from the field.

The patch worked, or it did not. The customer burden eased, or it remained. The policy reduced ambiguity, or it created a new workaround. The model summary helped the team move, or it erased the disagreement that needed to stay visible. The dashboard metric changed, but the people closest to the work report that the lived condition did not.

That return signal matters. It is how work learns.

Without a consequence path, a workflow can only keep moving forward. It cannot tell the difference between completed motion and effective action. It cannot see that a decision was locally reasonable but globally harmful, or that a messy handoff preserved exactly the context that a cleaner artifact would have lost.

The consequence path does not need to be dramatic. It may be a review comment, a reopened ticket, a user complaint, a test failure, a field note, a changed metric, a late correction, or a quiet pattern of after-cost. The important thing is that the system has somewhere to put it and a way to route it back into interpretation.

Work without return signals becomes performance. Work with return signals can become learning.

A Compact Map For Work

When a work event matters, slow down enough to map it.

Who or what acted?

At what scale and in what role?

What was targeted?

What artifact carried the move?

What context and warrant traveled with it?

What capability limits shaped the action?

What consequence will return for review?

This map will not make work simple. It should not. Complex work is complex because reality does not compress neatly into our artifacts. The map does something more useful: it keeps enough of the situation attached that people and machines can coordinate without pretending the machine understands everything globally or the human can remember everything privately.

That is how we actually do the work. Not by turning every action into a form, and not by trusting every visible motion as evidence of progress. We do it by preserving the accountable relation around the move, then letting consequence teach the next move what the first one could not yet know.