Assignment is a field. Ownership is a responsibility.

Companies confuse the two constantly. A task has someone's name on it, so the organization assumes it is owned. Then the work stalls, and everyone discovers the assigned person was waiting for input, coordinating between teams, lacking authority, or carrying the task as a reminder rather than an accountability.

The name was real. The ownership was not.

A workflow ontology needs a sharper definition. The owner is accountable for moving the work to its next meaningful state. That includes clarifying scope, finding the next action, surfacing blockers, coordinating dependencies, asking for decisions, updating state, and closing the loop.

That does not mean the owner does all the work. In many workflows, the owner is not the main executor. A customer success manager may own an escalation that requires product, support, and legal input. A product manager may own a launch that requires design, engineering, marketing, and enablement. A finance operator may own an approval path that depends on procurement and the business owner.

Ownership means the work has a spine.

Assignment without authority creates fake ownership. The assigned person can be blamed for delay but cannot make the decisions required to move the work. This is common in approval-heavy workflows, cross-functional launches, implementation projects, security reviews, and customer escalations. The workflow says one person owns the item. Reality says the next move belongs elsewhere.

Good workflows separate at least four roles.

The requester creates the demand or need. The accountable owner moves the work through the system. Contributors perform pieces of the work. Approvers or decision owners have authority at defined gates.

Many tools collapse these roles because it makes the interface cleaner. The company then pays for that cleanliness in meetings.

You can see the failure in the language people use:

"I thought legal owned that."

"Engineering has the ticket."

"It is with finance."

"We sent it to the customer."

Those sentences are not ownership. They are location updates. Work has moved somewhere, but no one has named who is responsible for getting it out.

A useful ownership rule sounds more like this: every active work object has exactly one accountable owner at a time, and that owner is responsible for next-state movement until ownership is explicitly transferred and accepted.

The accepted part matters. Handoffs often fail because the sender declares transfer before the receiver accepts responsibility. A Slack message, ticket mention, or email forward is not ownership transfer. It is a request for transfer.

Ownership also needs escalation rights. If the owner cannot resolve a blocker, they must know how to escalate without looking political or helpless. Escalation is not a failure of ownership. Quiet stagnation is.

The audit is straightforward. Take a sample of work items. For each one, ask:

  • Who is accountable for the next state change?
  • What authority do they have?
  • Who contributes but does not own?
  • Who can approve, reject, or unblock?
  • Has ownership ever been transferred without acceptance?

If the team argues about these answers, the assignment field is doing too much work.

Real ownership feels slightly heavier than assignment. It should. Work needs someone responsible for its movement through ambiguity, not someone whose name happens to be on the card.

This is part 4 of 10 in Workflow Ontology.