Labor as Code™ is the practice of writing a unit of work down (its purpose, evidence, authority, limits, exceptions, and tests) precisely enough that it can be assigned to a person or a machine and then inspected and changed. Work becomes governable when its purpose, evidence, authority, limits, exceptions, and tests are written clearly enough to inspect and change.
Treat it as an operating discipline
Labor as Code™ is not a metaphor for replacing people with software. It is a way to state work so another person can inspect it, compare it with practice, test it, assign it, and revise it.
The useful primitives include worker, work unit, trigger, state, evidence, input, output, decision, action, authority, policy, risk, review, escalation, memory, handoff, outcome, incident, dependency, rights, and version.
Observed work becomes a Work Unit, receives a Worker Contract, enters a work graph, and is tested as a versioned operation.
Write the work unit
A work unit names the purpose, outcome, origin, trigger, preconditions, evidence, inputs, source priority, decisions, actions, outputs, authority, credentials, risks, handoffs, systems, timing, failure modes, learning value, rights, and acceptance test.
Not every field applies every time. Missing fields should be omitted deliberately, not forgotten.
A bounded piece of work is defined through purpose, evidence, decision, authority, handoff, risk, and outcome.
Use a worker contract
The worker contract adds scope, permitted reasoning, prohibited action, output shape, human owner, confidence policy, privacy, security, fallback, recovery, retention, audit, recertification, and rollback.
A model or prompt can change underneath it. The contract remains the reviewable statement of what the worker was supposed to do.
The contract states both what the worker may do and the conditions that stop or limit it.
Represent the work as a graph
Consequential work rarely follows one clean sequence. Work units, decisions, states, and evidence events form nodes. Handoffs, dependencies, escalation, state changes, and provenance form the connections.
The graph exposes bottlenecks, duplicated work, fragile handoffs, unclear ownership, missing evidence, credential constraints, and places where one failure reaches many outcomes.
Begin with packets
A packet worker gathers evidence, checks completeness, organizes it, and prepares a recommendation for review. It does not change live state or communicate a consequential decision on its own.
Authority can grow from observation to summary, packet preparation, recommendation, drafted action, approved execution, bounded execution, and only then independent action where that is lawful and supported.
A worker moves from observation through advice and approved action only as measured performance supports each step.
Tie data readiness to the worker
A dataset is not ready for AI in general. It is ready for a named worker when the required evidence is available, timely, complete enough, authoritative, permitted, traceable, and usable under its contract.
State what happens when data is missing, stale, contradictory, or unsafe to place in model context. Generic readiness scores hide the exact dependency that can stop the work.
Version the work
Changes to policy, sources, prompts, models, tools, schemas, authority, and tests need a version and a reason. Replay known cases, inspect differences, approve the release, monitor it, and keep a rollback path.
Software ideas such as diffs and review can help. They should be used only where they make the operation clearer rather than more bureaucratic.
A proposed change is reviewed, replayed on known cases, released with tests, monitored, and rolled back when needed.
Specification review
A useful specification lets an independent reviewer determine whether the work stayed within bounds and produced the intended result.
| Part | Question | Failure signal |
|---|---|---|
Outcome |
What must become true? |
Only an activity is named |
Evidence |
What proves the result? |
The worker grades its own claim |
Authority |
What may change in the world? |
Permission is implied |
Failure |
What happens when work cannot finish? |
Silent partial completion |
Version |
What changed and can it be reversed? |
No reproducible prior state |