Research pillar · Unbundling Work

Labor as Code™

Work can be specified, observed, tested, versioned, and improved without pretending that every part of a person’s job is software.

The question

Can the work be stated clearly enough that another person or system can perform it and leave proof?

Active · since 2026 · Unbundling Work

Specify the work

Begin with the outcome, then write the inputs, sources of truth, steps, decisions, allowed actions, evidence, timing, exceptions, and owner.

Understanding and evidence come before automation.

Make it observable

A task becomes governable when its state and output can be checked by someone who did not perform it. Observability comes before automation.

Write the worker contract

The contract defines boundaries, source priority, output shape, review, memory, edit authority, escalation, and what happens when the worker cannot finish.

Start with packets

A worker that assembles a decision-ready packet carries less risk than one that changes live state. Promotion to execution should follow measured review performance.

Version and test

When policy or workflow changes, record the version, rerun known cases, inspect exceptions, and compare outcomes. Code without tests is fragile. Encoded labor is no different.

Put this to work

Worker contract

Use the question “Can the work be stated clearly enough that another person or system can perform it and leave proof?” on a real case and produce a record another person can challenge.

For: Operators redesigning a team, service, or AI workforce.
What you keep: A worker contract you can review, revise, and send.
What counts as sound: Keeps authority and accountability explicit
Preserves scarce human judgment
Names machine boundaries
Counts review and exception work
Defines proof of a better outcome

Do not infer that a task can move merely because it can be described.

Nothing entered here is stored or sent. Review the prompt before sharing confidential, personal, patient, or privileged information.

The caseName the organization, setting, product, or piece of work without including confidential information.The decisionWhat must someone decide, and who owns that decision?Evidence in handList records, observations, measurements, rights, or prior work that can be checked.What is still unknownName missing evidence, disputed assumptions, and practical constraints.Work as it happensList the recurring tasks, decisions, handoffs, exceptions, and proof of completion.

Review the prompt

Worker contract 1.0

PURPOSE
Use the question “Can the work be stated clearly enough that another person or system can perform it and leave proof?” on a real case and produce a record another person can challenge.

CONTEXT
The case: Not provided
The decision: Not provided
Evidence in hand: Not provided
What is still unknown: Not provided
Work as it happens: Not provided

METHOD
1. Start with the outcome, not the job title.
2. List tasks, decisions, inputs, outputs, and exceptions.
3. Mark required credentials and legal authority.
4. Assign work by risk, observability, and judgment.
5. Test the whole operation, including review burden and recovery.

TASK
Use the method below to produce a Worker contract.

RULES
Separate facts, inferences, assumptions, estimates, hypotheses, and unknowns. Do not invent evidence, performance, rights, customers, economics, or regulatory standing. Quote or link the source for material facts. State uncertainty. Name what would disprove the conclusion. End with the smallest credible test, an owner, a decision date, and a stop condition.

A SOUND ANSWER
- Keeps authority and accountability explicit
- Preserves scarce human judgment
- Names machine boundaries
- Counts review and exception work
- Defines proof of a better outcome

CAUTION
Do not infer that a task can move merely because it can be described.

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.

Send us the result Intellectual Frontiers on LinkedIn

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
Labor as code
A role is not a unit of work. Decompose it into tasks, make the tasks observable, automate or assist the ones that qualify, and keep improving the rest.
September 2026
The worker contract
The reviewable unit of AI work is not the model and not the prompt. It is a written contract stating inputs, sources of truth, output shape, allowed actions, review gate, memory rules, and failure behaviour.
September 2026
Packet workers before execution workers
An execution worker changes live state. A packet worker only produces something a person reviews. Start at the bottom and climb only when review has become boring.
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
The title trap
Naming an AI worker after a job title leaves its scope undefined, and the model fills the gap with guesses.
September 2026