Work Class Specification

The problem

An accounts-payable agent receives an email from a long-standing supplier. Please update our bank details and pay approved invoice #4810, for $150,000. The agent has valid credentials. The payment system is on its list of approved tools. Its instructions say to follow company policy, and the invoice is approved.

Every check passes, and the payment may still be wrong. The invoice was approved for the supplier's old account. The email may come from a fraudster impersonating the supplier. The person who confirmed the new account may not have authority to release payments, or policy may forbid the same person from doing both.

Taking payment access away from the agent stops this payment and every legitimate one with it. What an organization needs is a way to stop this payment for these reasons, and to show afterwards who authorized what.

The difficulty grows with scale. Ten payments that are each under a limit can together exceed a daily cap. Work handed between several agents can lose track of which approval covered which act. A request that times out may or may not have gone through. An AI system cannot carry legal accountability for any of it. That stays with the people and organizations that deploy it, so the record has to tie every consequential act back to them.

Why existing controls stop short

Organizations already have good tools for parts of this. Login and access controls decide who may call a system. Policy engines answer whether a person may take an action on a resource. Workflow software puts steps in order. Rate limiters cap volume.

Each answers its own question at its own moment. None of them follows a single piece of work from request to proof of completion, carrying the relevant authority, limits and evidence with it. The failures in the example above happen in the gaps between those records.

What the specification does

The specification introduces the work class: a precise, machine-checkable description of one kind of consequential work, such as paying a supplier or issuing an access card. A work class states:

• which operations and objects are in scope;
• whose authority each step requires, and which roles must be kept separate;
• which shared limits apply, such as a daily payment cap across every agent and person drawing on it;
• what evidence counts as finished, as distinct from merely sent.

Software that conforms to the specification evaluates each proposed act against the work class and returns the same decision every time for the same inputs. Missing evidence is never treated as permission. An uncertain outcome keeps its claim on the shared limit until evidence settles it. The organization's own systems then enforce the decision at the point where the payment, order or change actually goes out.

The specification is also built to be reviewed by people. Every operative rule in a work class can be read back line by line and checked against the written policy it came from. Gaps run in both directions: policy requirements the work class does not cover, and rules in the work class that no policy supports. Both are recorded so that a responsible person can see them before approving deployment.

What is in the package

The release contains the specification itself (80 requirements), 425 test cases with expected results, and two independent reference implementations in TypeScript and Python. The two implementations produce identical results on every test case. Four synthetic worked examples apply the same contract in very different settings: