Approvals are supposed to protect the system. Too often they protect nobody and slow everything down.

The usual approval field says pending, approved, or rejected. That is barely a model. It does not say what decision is being made, who has authority, what evidence is required, what risk is being accepted, how long the decision should take, or what happens when the approver stays silent.

So approval becomes performance. People submit because the workflow says submit. Approvers click because they trust the requester, want the work to move, or do not have enough context to object. Hard cases drift into Slack, side meetings, and executive interrupts.

A real approval is a decision gate. It should exist because the work crosses a threshold: money, risk, customer impact, legal exposure, security, brand, operational complexity, architecture, staffing, or strategic direction.

If there is no threshold, the approval is probably habit.

Good gates have named semantics.

First, what is being decided? "Approve launch" is too broad. Approve readiness? Approve risk acceptance? Approve budget? Approve exception to policy? Approve customer commitment? Each decision needs a different approver and evidence set.

Second, who can decide? A stakeholder is not automatically an approver. A reviewer is not automatically a decision owner. A senior person is not automatically the right authority. The workflow should identify the role with the right to approve, reject, request changes, or delegate.

Third, what evidence is required? Approvals should not depend on whether the requester wrote a persuasive paragraph. A gate should name the artifacts: test results, legal review, cost estimate, customer impact, rollback plan, margin analysis, implementation plan, risk register, exception rationale.

Fourth, what are the allowed outcomes? Approved, rejected, and changes requested are obvious. Conditional approval is often more honest: approved if the rollback plan is ready, if finance confirms budget, if the customer accepts the revised scope, if the data migration test passes.

Fifth, what is the clock? Approvals without service expectations become hidden queues. If the gate matters, it needs an SLA or review cadence. If it does not matter enough for a service expectation, it may not deserve to block the work.

Decision gates fail in predictable ways. Too many gates create learned helplessness. Vague gates create political navigation. Rubber-stamp gates create false safety. Missing gates create late surprises. Silent gates create delay nobody owns.

The workflow should make the cost visible. How many items are pending approval? Which gates are aging? Which approvers are bottlenecks? Which requests are repeatedly sent back for missing evidence? Which gates are bypassed in emergencies because the normal path is too slow?

Approvals are not inherently bureaucracy. Bad approvals are bureaucracy. Good approvals are how a company makes risk, authority, and evidence explicit before work crosses a meaningful line.

The test is simple: if an approval fails, can the company explain what decision was missed and why it mattered? If not, the gate is decoration with latency attached.

This is part 7 of 10 in Workflow Ontology.