Research program
Labor as Code™
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.
Can real work be represented precisely enough to assign across people and machines without hiding judgment, risk, or failure?
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 |
Research notes
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. This note sets out that hypothesis, states what is being measured to test it, and names the parts that stay hard.
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.
Labor as code
Make work inspectable, assignable, testable, versioned, and governable before attempting broad automation. The pattern turns observed work into Work Units and Worker Contracts that can be tested in shadow mode and versioned, and it stops when specification adds more burden than clarity.
Packet workers before execution workers
Start by preparing evidence for a person, then grant narrow action only after review data supports it. Authority is promoted one level at a time, from observing to independent execution, using error, edit, escalation, and incident evidence. Some work should never progress beyond advice or packet preparation.
The worker contract
State what a worker may do, what evidence it must use, when a person reviews it, and how it fails safely. The contract is versioned so it survives a change of model or vendor. It governs the worker but grants no legal authority the organization lacks, and deployment stops when ownership or failure behavior cannot be stated.
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. Where requirements are certified, regulated, or deep in domain logic, Zero Neo has no claim and the hypothesis is treated as rejected. New software is the last resort, and sometimes that is where a case ends up.
Work Unit record
This note gives a versioned record that another person can inspect and test, so a piece of work is described by evidence and not by intended process. A description of intended process is not evidence of actual work, and the unit should be neither too broad to observe nor too narrow to own a result. Describe one piece of work by its purpose, evidence, authority, risk, handoffs, and accepted outcome.