Every company has a model of work. Usually it is accidental.

You can see it in the ticket fields, project boards, support queues, implementation trackers, approval chains, Slack rituals, spreadsheets, and meeting notes. Somewhere in that mess, the company has definitions for what counts as a request, who owns a task, when something is blocked, what "done" means, when a handoff has actually happened, and who can approve a change.

The problem is that those definitions rarely agree.

A support ticket says pending, but the customer thinks the company is working on it. A project says on track, but the team is waiting for an executive decision. A finance approval says submitted, but no approver knows what evidence would be enough. A roadmap item says assigned, but the assigned person is really coordinating five other people who each own a piece of the outcome.

This is work state drift: the gap between what the system says and what is operationally true.

Work state drift is expensive because it makes managers inspect everything manually. It creates update meetings where the real work is reconstructing reality. It turns dashboards into rumor with formatting. It forces strong operators to run the company through memory, relationships, and private backchannels because the formal workflow cannot be trusted.

That is why work needs an ontology too.

Ontology sounds grand. In this context it means something plain: a shared model of the objects of work, their states, their relationships, and the rights people have to act on them. What is a task? What is a blocker? What is an owner? What is an approval? What does done mean? What state transitions are allowed? Who can move work from one state to another? What evidence is required?

This is not taxonomy for its own sake. Nobody needs a beautiful dictionary that sits in Confluence and dies. The point is operating reliability. If the company cannot trust the state of work, it cannot manage throughput, capacity, risk, or accountability.

The first useful move is to stop treating workflow fields as admin debris. A status field is a claim about reality. An owner field is a claim about accountability. A blocker field is a claim about what kind of intervention is needed. An approval field is a claim about decision rights. If those claims are vague, the workflow is not weakly documented. It is lying.

Humans have lived with this for a long time because humans can compensate. They ask around. They remember the exception. They know that "waiting" in one team's board means legal review, while "waiting" in another team's board means nobody looked at it yet. That compensation is invisible labor.

AI makes the ambiguity harder to ignore. An agent cannot safely act on "pending" if pending means four different things. It cannot escalate a blocker if the blocker might be a dependency, a decision, a customer delay, or ordinary backlog aging. It cannot close a task if done is defined by optimism instead of acceptance criteria.

But AI is not the reason to fix this. It is the forcing function.

The human reason is enough: work should be legible. A leader should be able to look at a workflow and know what is moving, what is stuck, who owns the next action, what decision is missing, and where state is unreliable. A teammate should be able to inherit work without reconstructing it from chat history. A customer should not experience the company's internal ambiguity as delay.

A good workflow ontology gives the company fewer places to hide. It makes the implicit explicit. It turns work from a pile of labels into a system with meaning.

That is the spine of the series: define the objects of work, reduce state drift, and make workflow reality trustworthy enough for humans first and agents second.

This is part 1 of 10 in Workflow Ontology.