Labor as Code™
Work becomes governable when its purpose, evidence, authority, limits, exceptions, and tests are written clearly enough to inspect and change.
The question
Can real work be represented precisely enough to assign across people and machines without hiding judgment, risk, or failure?
Active · since 2026 · Unbundling Work
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.
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.
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.
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.
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.
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 |
Put this to work
Worker contract
Write a bounded piece of work so its evidence, authority, failure, outcome, and version can be inspected.
- For
- Operators specifying work for people, software, and AI workers.
- What you keep
- A worker contract you can review, revise, and send.
- What counts as sound
- Names an observable outcome
- Uses approved sources
- Makes authority explicit
- Plans safe failure
- Can be versioned and replayed
A specification does not make tacit or consequential work safe to automate.
Nothing entered here is stored or sent. Review the prompt before sharing confidential, personal, patient, or privileged information.
Review the prompt
You can leave any field blank. The prompt will mark it as not provided.
If the record survives your review, send the question, evidence, unknowns, and requested next step.
Notes under this pillar
Design Patterns
- From applications to work
Businesses do not need CRM software; they need work performed. Decompose the outcome into roles, tasks, workflow, and capabilities, and the application stops being the organizing unit.
September 2026
- Work Unit record
Describe one piece of work by its purpose, evidence, authority, risk, handoffs, and accepted outcome.
September 2026
- The worker contract
State what a worker may do, what evidence it must use, when a person reviews it, and how it fails safely.
September 2026
- Labor as code
Make work inspectable, assignable, testable, versioned, and governable before attempting broad automation.
September 2026
- Packet workers before execution workers
Start by preparing evidence for a person, then grant narrow action only after review data supports it.
September 2026
Operating Theorys
- AI changes the configuration economics
Specialized SaaS won largely because configuring general-purpose platforms was expensive. If AI collapses that cost, the reason for the historical result stops applying.
September 2026
- When Zero Neo should fail
The conditions under which specialized software remains the right answer, stated precisely enough to be used in an actual review.
September 2026