Skip to main content

41  Labor OS and Typed Jobs

41.1 Chapter status

Field	Value
Chapter ID	labor-os-and-typed-jobs
Part	Part II - Planning, Memory, Reasoning, and Execution
Status	conceptual
Manuscript maturity	v0.3 manuscript draft
Last updated	2026-07-15
Primary source records	talos, viea, genesiscode, software_magic_grimoire, talos_md, moecot, ext_temporal_docs, ext_airflow_dag_docs, ext_bpmn_2_0_2_spec, ext_kubernetes_jobs_docs
Claim label	Design rationale
Evidence level	argument
Source queue	primary: talos; supporting: viea, genesiscode, software_magic_grimoire; external comparators: ext_temporal_docs, ext_airflow_dag_docs, ext_bpmn_2_0_2_spec, ext_kubernetes_jobs_docs; variant: talos_md; connector/recovery: moecot
Source loading state	source notes: talos, deterministic_capability_compilation, viea, genesiscode, software_magic_grimoire, talos_md, moecot, ext_temporal_docs, ext_airflow_dag_docs, ext_bpmn_2_0_2_spec, ext_kubernetes_jobs_docs; raw cache: talos, viea, genesiscode, software_magic_grimoire, talos_md; connector/recovery: moecot
Test state	Exact authored scaffold: 3 valid/10 rejecting plan-execution fixtures; exact 2 valid/7 rejecting delivery and 2 valid/9 rejecting durable-lifecycle suites; 7 reachable stages, 29 routes, and 42/42 rejected mutations; 1 accepted no-promotion decision; 56 live declarations across two modules and 5 public targets, with 3 weak declarations retired. No deployed scheduler, worker, permissions, approvals, adapter, external-effect observer, durable workflow, task-success result, natural workload, causal advantage, reproduction, transfer, or core support effect.

41.2 Drafting guardrail

Labor OS owns admission, lifecycle custody, and terminal receipt of one bounded authorized work unit from dispatch request through delivery, evidence-readiness eligibility, cancellation, compensation, expiry, or retirement. It binds the job to its contract and plan parent, attempts, leases, permissions, approvals, workspace, adapter, observed effects, artifacts, costs, residuals, and receipts.

It does not own intent, plan correctness, permission or approval authority, runtime effect truth, context mutation, artifact provenance, verification adequacy, evidence acceptance, support, model learning, or release. A complete job record can describe unauthorized or incorrect work. A durable workflow can reliably execute the wrong contract. Evidence-ready is only eligibility for a separate evidence decision, not proof that the work is useful, safe, or true.

41.3 Human Reading Path

Concrete lens. The process baseline calls exit code zero complete. The typed-job path requires identity, permission, artifact, verification, delivery, residual, and acknowledgment closure.

After planning, verification, and review, the stack has to turn accepted work into bounded execution. A Labor OS is the layer where tasks become typed jobs with lifecycle, parentage, inputs, outputs, approvals, isolation, logs, failure behavior, and completion criteria.

This is where “agent” becomes less useful as a word. The architecture does not need a free-floating actor; it needs jobs that say what they are allowed to do, which gate can stop them, what evidence they must return, and how their work can be audited or replayed later. A job is small enough to govern and durable enough to inspect.

Typed work turns execution from a personality problem into a recordkeeping and authority problem.

That shift is what makes large-scale AI labor auditable rather than mysterious. The work item becomes something a team can inspect, replay, deny, or improve.

Execution becomes safer when the smallest useful unit is a record rather than a persona, because typed work makes delegation reviewable before personality enters the story. Records precede delegation so execution remains bounded after handoff begins downstream.

41.4 Problem

Intelligence must become typed work with lifecycle, permissions, artifacts, logs, and approvals.

The previous chapters decide what should be believed and reviewed. Execution begins when accepted plans become work. Talos supplies the right frame: an AI labor operating system turns plans into typed jobs with contract locks, permissions, isolated workspaces, adjudication, delivery, feedback, audit, and replay.

A job is the unit that keeps agency bounded. It carries a contract, lifecycle state, inputs, outputs, permissions, approval state, runtime adapter, failure behavior, audit events, and replay status.

This makes jobs the execution-side partner of command contracts. Commands expose the semantic fields; plans decompose those fields; jobs bind each dispatchable node to an execution state that can be approved, denied, audited, retried, or retired.

The job boundary is also where the stack distinguishes work from evidence. A job can run and produce something useful without proving that the work was authorized, verified, replayable, or safe to reuse. The labor OS should make that difference explicit instead of collapsing it into a single “done” status.

41.5 Why existing approaches are insufficient

Chat outputs do not provide deterministic job lifecycle, tool isolation, auditability, or repeatable cognitive manufacturing.

Chat is not a factory. It does not lock a contract, isolate tools, enforce permission boundaries, require approvals, preserve logs, or tell a later verifier how to replay what happened. Without jobs, the system has vibes and side effects instead of controlled work.

AutoGen (ext_autogen_2023) gives an external multi-agent workflow baseline, and SWE-bench (ext_swe_bench_2023) gives an external software-task benchmark baseline with repository-scale context and patch evaluation. Labor OS uses those comparison points to ask for typed job lifecycles, artifact receipts, replay, and approval boundaries around agentic work. The baseline references do not claim that Talos jobs reproduce AutoGen workflows or solve SWE-bench tasks.

Workflow and job systems already solve important adjacent problems. Temporal (ext_temporal_docs) supplies durable workflow execution, event history, worker, and failure-recovery vocabulary. Airflow (ext_airflow_dag_docs) supplies DAG, schedule, task, dependency, callback, retry, and timeout vocabulary. BPMN 2.0.2 (ext_bpmn_2_0_2_spec) supplies stakeholder-readable process-notation and process-component translation lineage. Kubernetes Jobs (ext_kubernetes_jobs_docs) supplies batch-job completion, failure, backoff, deadline, terminal-condition, and cleanup vocabulary. The Labor OS does not claim to replace those systems; it asks what must be added when the work is AI labor that carries authority, tool permissions, approvals, artifact/evidence receipts, residuals, and support-state effects.

GenesisCode reinforces the distinction: proposals and effects are different things. Effects require capability boundaries and replay logs. Software Magic adds that workflows need entry rules, exit rules, guards, loops, and recovery paths.

Agent swarms often fail at this boundary. They start many plausible subtasks but lose the lifecycle state, permission scope, parent contract, or artifact trail that would let a reviewer know which work was authorized and which work merely happened. A Labor OS should make unauthorized work hard to start and unlogged work hard to hide.

The same failure can happen in a single-agent workflow. A model may create files, messages, patches, summaries, or decisions that look complete but lack approval state, effect receipts, or replay metadata. The unit of governance is therefore not the agent; it is the typed job record.

41.6 Core Claim

[labor-os-and-typed-jobs.core, label: Design rationale, support: argument] The execution layer should convert plans into typed jobs managed by a governed labor operating system.

Reader claim. A job is not complete because a worker stopped running; completion requires the right contract, authority, artifact, verification, receipts, residuals, and acknowledgment to close together.

Operational rule. Lower each plan node into a versioned job with explicit inputs, permissions, lease, idempotency key, cancellation behavior, evidence requirements, and terminal states. Refuse execution or closure when any required identity or receipt is missing, and make terminal states absorbing.

41.6.1 Worked job lifecycle: output exists, acknowledgment does not

A worker receives a typed job to render one chapter. The contract names the plan node, input digest, renderer version, output path, authority ceiling, scheduler lease, cancellation token, verifier, idempotency key, and expected completion receipt. The render succeeds and the output file exists, but the artifact digest has not been verified and the consumer has not acknowledged delivery. A process-based baseline would mark the job complete when the command exits 0; the labor OS keeps it in delivered-but-unacknowledged state.

After verification binds the output digest and the consumer acknowledges the exact job version, the six-event modeled run reaches closure. A retry with the same idempotency key cannot create a second logical completion, and cancellation or mutation after closure is rejected. The refinement checks 29 routes and rejects 42 mutations across approval, lease, retry, cancellation, evidence, identity, replay, authority, receipts, and residuals. These finite records do not prove scheduler behavior, useful work, effect truth, recovery, or deployed idempotence.

The claim remains at argument support. Talos supplies the labor-OS frame, contract-lock discipline, job pipeline, evidence-bound artifact, audit, replay, and explicit non-claim boundaries. VIEA supplies the intent-to-artifact-to-runtime trace, permission envelopes, approval roles, side-effect classes, runtime-adapter maturity levels, and feedback loop. GenesisCode supplies the proposal/effect separation, host-provided capability boundary, deterministic effect logs, replay semantics, obligations, provenance, and semantic patch discipline. Software Magic Grimoire supplies workflow guard vocabulary for bounded instruction artifacts, output contracts, verification, failure behavior, and gated spell stacks. The Markdown Talos release remains a variant context; the complete authenticated MoECOT connector text is passage-reviewed, but neither supplies reproduced runtime evidence.

41.6.2 Claim-source mapping status

Appendix C maps the core claim to all ten assigned sources. Four local raw caches are passage-reviewed; talos_md remains source-note/connector bounded, the authenticated moecot text is passage-reviewed, and the four external workflow comparators have bounded official-documentation or specification notes. The mappings support execution- contract design and comparison, not a working scheduler, durable runtime, permission service, adapter, replay engine, or useful-outcome result.

Source	What it supports	Limit
talos	Passage-reviewed across all 30 related tabs: Operating System for AI Labor and control-plane framing, contract lock, MVI routing, typed tests, topological execution, job-based asynchronous custody, factory-to-tribunal flow, intent sanitation, lossy claim extraction, evidence binding, bounded adversarial review, claim/evidence/state/artifact records, proof bundles, audit/replay pressure, and the final corrections from deterministic/zero-copy/truth language to hardware-bounded, handle/cache-separated, accountability-only claims.	One repeatedly revised author lineage, not corroboration. No Talos scheduler, approval service, runtime, replay log, benchmark, security result, or proof bundle has been reproduced here; thresholds, costs, targets, compliance mappings, and “standard” status remain proposals.
viea	Passage-reviewed: generation-not-execution framing, intent to command to artifact graph to routed specialist execution to runtime target to verification gate to execution and feedback, command contracts, artifact graph, permission model, specialist/runtime adapter subsystems, least-privilege permission envelopes, approval roles, integration contracts, side-effect classes, rollback limits, irreversible side-effect gates, runtime-adapter maturity levels, and runtime-specific verification.	No deployed intent-to-job pipeline, permission service, runtime adapter, feedback loop, or verified execution trace exists here.
genesiscode	Passage-reviewed: untrusted AI-output premise, small pure kernel, capability boundary for nondeterminism, deterministic effect logs, replay semantics, obligation engine, canonical IR validators, semantic patches, AI as proposer not authority, sealed effect requests, host-provided capabilities, evidence artifacts, registry rejection until obligations pass, content-addressed packages, and accepted-patch provenance.	No local GenesisCode implementation, effect runner, replay checker, proof artifact, security audit, registry policy, or obligation run exists here.
software_magic_grimoire	Passage-reviewed: bounded instruction artifacts, artifact/objective/constraint/output/truth-condition framing, eight-limb role/objective/context/constraints/procedure/output-contract/verification/failure-behavior anatomy, risk-scaled cast levels, exploration/execution separation, artifact/invariant/search/output/verification/failure workflow, prompt pathologies, spell-stack coordination, FEATURE-RAIL, loop rules, and verification-bundle shape.	Workflow vocabulary only; not empirical evidence that a labor OS performs better or safely executes work.
talos_md	Connector/source-note mapped: public-release Talos terminology around typed AI labor, deterministic manufacturing, five-phase lifecycle, control-plane ledgers, evidence, isolation, auditability, blind handles, and Digital SCIFs.	Variant/canonicalization aid only; local cache is an auth-gate placeholder, and reported benchmark or security claims remain unverified.
moecot	Authenticated connector text passage-reviewed: runtime-reference context for governed orchestration, specialist lanes, fail-closed ledgers, readiness gates, replay, handoff, promotion blockers, and residual tracking.	Runtime code, logs, benchmark artifacts, and replay records have not been inspected or reproduced here.

The external comparator mappings prevent novelty laundering. Temporal grounds durable workflow and event-history vocabulary; Airflow grounds DAG and task orchestration; BPMN grounds process notation; Kubernetes grounds batch-job lifecycle. None proves a Labor OS scheduler, integration, compiler, controller, workflow benchmark, runtime isolation result, or support transition.

41.6.3 Strongest objection

Labor OS may be an expensive relabeling of mature workflow systems, queues, schedulers, process engines, and batch controllers. Authority metadata does not enforce authority; receipts can omit real side effects; retries can duplicate harm; and approvals can become latency-heavy ceremony. A simple script plus a capable operator may outperform the full layer. The design case therefore needs matched natural execution, fault, usefulness, authorization, side-effect, recovery, fairness, privacy, human-burden, and total-cost evidence.

41.7 Mechanism

The Typed Job is the control-plane record that turns a dispatchable plan node into one bounded work lifecycle. Its first mechanisms freeze the work contract, identity, admission, locks, lifecycle, permissions, approvals, environment, and scheduling state before effects. Its later mechanisms govern leases, observed effects, retries, recovery, delivery, evidence-readiness eligibility, terminal receipts, retirement, feedback, and comparison. The contract has eighteen mechanisms:

1. Freeze one job contract from an accepted contract and dispatchable plan node with exact type, objective, scope, inputs, expected artifacts, acceptance tests, failure behavior, consumer, consequence, risk, authority, rights, budget, deadline, and expiry.
2. Assign stable job, attempt, lease, workspace, adapter invocation, approval, effect, artifact, receipt, residual, and parent identities with causal lineage and idempotency keys.
3. Admit, refuse, defer, split, or quarantine work only after validating parent contract and plan versions, lifecycle state, required inputs, adapter eligibility, resource envelope, authority, rights, and open blockers.
4. Lock material job fields before dispatch and invalidate approval, permission, verification, or replay decisions after relevant contract, plan, input, adapter, policy, threat, environment, or consumer change.
5. Use typed lifecycle transitions for drafted, locked, awaiting approval, approved, dispatchable, queued, leased, running, paused, retrying, adjudicating, delivered, evidence ready, failed, blocked, quarantined, cancelled, compensated, replayed, expired, and retired states.
6. Request exact capability, tool, data, network, secret-handle, disclosure, side-effect, environment, and retention grants from their owners without minting or widening permissions locally.
7. Bind required accountable-human or policy approvals to exact job version, effect class, authority, scope, time, conditions, revocation, and reuse limits before high-impact dispatch.
8. Provision purpose-bound workspace, secret isolation, environment lock, runtime adapter, model/tool versions, input digests, observation hooks, and cleanup policy as separately inspectable boundaries.
9. Schedule admitted work under declared priority, fairness, dependency, capacity, deadline, preemption, starvation, and cost policies while keeping queue acceptance distinct from dispatch and completion.
10. Lease each dispatch attempt with bounded authority, expiry, heartbeat, retry policy, checkpoint, idempotency key, duplicate-effect guard, and exact resume or restart semantics.
11. Observe actual adapter calls, tool uses, reads, writes, messages, external effects, outputs, costs, failures, approvals, denials, interventions, and side records rather than trusting agent or scheduler status.
12. Resume and retry only from declared checkpoints with unchanged or reauthorized authority, reconciled effects, fresh leases, preserved attempt lineage, and explicit at-most-once, at-least-once, or compensated semantics.
13. Route failures, denials, timeouts, partial effects, lost workers, stale leases, policy changes, residuals, and unknown states to typed recovery, escalation, compensation, quarantine, or terminal custody.
14. Separate produced output, delivered output, adjudicated output, verified artifact capture, replay declaration, evidence-ready completion, user acceptance, support, and release.
15. Issue terminal receipts that bind observed pre/post state, attempts, approvals, permissions, adapters, effects, artifacts, tests, audit refs, delivery, evidence-readiness state, replay grade, costs, residuals, and non-claims.
16. Cancel, compensate, expire, revoke, garbage-collect, or retire jobs through owner-authorized transitions that preserve irreversible effects, artifacts, obligations, and historical receipts.
17. Return bounded feedback, failure signatures, reusable procedures, and learning candidates through Artifact Graphs and their owning gates without silently editing plans, memory, policies, models, or support.
18. Compare chat, ambient agents, agent swarms, scripts, queues, DAG orchestrators, durable workflows, BPMN/process engines, Kubernetes batch jobs, and governed typed jobs under matched work, resources, authority, faults, delayed outcomes, and total cost.

flowchart LR
  A["Contract + dispatchable plan node"] --> B["Admit + lock typed job"]
  B --> C["Permissions + approvals + workspace"]
  C --> D["Queue + bounded lease"]
  D --> E["Adapter execution + effect observation"]
  E --> F{"Terminal state?"}
  F -- "retry / recover" --> G["Reconcile effects + fresh lease"]
  G --> D
  F -- "fail / block" --> H["Residual / compensation / quarantine"]
  F -- "deliver" --> I["Artifact + adjudication"]
  I --> J{"Evidence-ready fields complete?"}
  J -- "no" --> K["Delivered, not evidence ready"]
  J -- "yes" --> L["Terminal receipt + evidence eligibility"]

Reading the typed job lifecycle: Admission and authority precede work. Scheduling and leasing precede effects. Actual effects remain observable across retry, recovery, failure, compensation, and quarantine. Delivery then branches from evidence-ready eligibility: a useful output can reach its consumer while verification, artifact capture, replay, cost, or residual fields remain open.

The lifecycle preserves custody rather than promising correctness. Runtime adapters own effects, Artifact Graphs own produced records, evidence owners decide support, and accountable humans own high-impact approval. Labor OS keeps those decisions attached to the same job and attempt history so neither a model response nor a scheduler status can silently substitute for an owning receipt.

Identity continuity ties the lifecycle together. A queue item, worker process, adapter call, produced file, delivery notification, and terminal receipt are different objects with different clocks and failure surfaces. Their shared job and attempt lineage makes later reconstruction possible while preserving the points where custody changed hands, observation was partial, or a downstream owner declined the result.

41.7.1 Asynchrony is a custody contract

Talos’s later revisions make an important correction: verified work may outlive an HTTP request, a model session, a worker lease, or the client’s attention. Moving from chat-style request/response to a ticket, queue, and callback does not merely improve timeout behavior. It creates a durable custody obligation. The system must still know what happened when the client disconnects, a worker restarts, a callback is duplicated, verification exhausts its budget, or an external effect succeeds just before cancellation.

The lifecycle therefore separates seven events that are often collapsed:

Event	What it establishes	What it does not establish
submission accepted	the gateway received a versioned request	admission, authorization, or queue durability
job admitted	policy accepted the job into durable custody	dispatch, useful work, or effect authority
attempt leased	one worker has bounded execution custody	exactly-once effects or terminal completion
output produced	an attempt emitted a candidate artifact	verification, delivery, or user acceptance
delivery attempted	the system tried a declared channel	receipt by the intended consumer
delivery acknowledged	the consumer or its authorized proxy receipted bytes	evidentiary readiness, correctness, or support
terminal receipt issued	completion, refusal, cancellation, compensation, or open residuals are durably recorded	truth, safety, or downstream promotion

Callbacks and pull APIs are interchangeable delivery mechanisms only when they resolve to the same terminal record. Callback signatures, destination and policy versions, idempotency keys, acknowledgement deadlines, retry ceilings, dead-letter custody, pull fallback, cancellation races, and consumer disputes remain part of the job. A 202 Accepted, quiet queue, successful worker exit, or emitted webhook cannot stand in for terminal custody.

This also changes how latency is judged. A deep path can be deliberately asynchronous when the consumer accepts delayed delivery and the expected value of additional verification exceeds its compute, human, opportunity, and freshness costs. That decision is task- and consumer-specific. It cannot be derived from a branded “verification tax,” a fixed risk threshold, or the idea that slower work is necessarily more correct.

41.7.2 Typed job lifecycle states

Typed jobs should use explicit lifecycle states:

State	Meaning	Evidence consequence
drafted	A job packet exists but is not contract-locked.	No dispatch.
locked	Contract, parentage, expected artifact, and failure behavior are fixed.	Eligible for permission review.
awaiting_approval	Required approval is missing or stale.	Cannot run.
approved	Required approval is present and scoped.	Eligible for dispatch if permissions pass.
dispatchable	Permissions, approvals, inputs, and adapter requirements are satisfied.	May run.
running	Runtime work is active.	Audit events required.
adjudicating	Output exists but verification, review, or acceptance is pending.	Not evidence-ready.
delivered	Output has been returned or made available.	Useful artifact; support still bounded.
evidence_ready	Required artifact capture, verification, audit, residual, and replay/non-replay fields exist.	Candidate evidence for downstream ledgers.
failed_or_blocked	The job failed, was denied, or lacks a required gate.	Residual and recovery path required.
quarantined	The job had unauthorized effects, missing provenance, or unsafe behavior.	Cannot support promotion.
replayed_or_retired	Replay completed or the job is no longer valid for reuse.	Historical trace only unless requalified.

The distinction between delivered and evidence_ready is central. Delivery satisfies a user-facing workflow; evidence readiness satisfies the living stack.

The state table is deliberately asymmetric around output. Before output, the record emphasizes authorization, resources, leases, and custody. After output, it emphasizes adjudication, artifact capture, replay status, costs, residuals, and downstream eligibility. That asymmetry leaves a visible interval in which work is useful to a consumer yet still incomplete as governed evidence. The interval has its own operators, timestamps, dispute state, and terminal routes, so delivery history remains legible even when later evidence work ends in a block, downgrade, or retirement.

41.7.3 Foundry work as typed labor

The Executable Capability Foundry can be expressed as typed jobs rather than a privileged monolithic trainer. Charter authoring, scaffold construction, semantic decomposition, corpus generation, expert training, NCO packaging, linking, translation validation, environmental testing, residual updates, tribunal review, reification, and registry publication each have different inputs, authorities, artifacts, stop conditions, failure states, and receipts.

This preserves the paper’s four-plane boundary inside execution. A learning job cannot commit a specification change; a runtime job cannot certify itself; an assurance job cannot grant tool authority; and a reification job cannot erase the disagreement that motivated it. Exact, compiled, shadow, residual, canary, fallback, and quarantine are job modes with explicit transition owners, not informal trainer flags.

41.8 Interfaces

Ownership stays explicit across twelve interfaces:

1. Intent and Command Contracts supply authorized objectives and constraints; jobs cannot reinterpret intent or widen contract scope.
2. Planning supplies dispatchable plan-node identity, dependencies, acceptance conditions, and residuals; Labor OS owns execution lifecycle rather than plan correctness.
3. Proof-Carrying Claims and review owners supply bounded blockers, constraints, required actions, and human decisions; jobs cannot promote verdicts or support.
4. Security, Privacy, Rights, Licensing, and authority owners issue and revoke exact permissions, approvals, secret handles, disclosure limits, and retention obligations.
5. Resource Economics and scheduler policy supply capacity, priority, fairness, deadline, preemption, and cost constraints; queue state is not work completion.
6. Runtime Adapters and tool runners own actual effect execution and effect receipts; Labor OS dispatches and observes but does not declare external effects reversible.
7. Context ABI and Transactions supply exact input views, mounts, taint, deletion, and expiry state; jobs cite rather than mutate context outside authorized transactions.
8. Artifact Graphs own output identity, provenance, replay grade, audit reconstruction, and receipt faithfulness; Labor OS links attempts to produced and delivered artifacts.
9. Verification Bandwidth, Evidence States, and claim owners decide adequacy and support; evidence-ready is an eligibility state, not evidence acceptance.
10. Accountable humans own high-impact approval, exception, adjudication, intervention, appeal, and irreversible-effect decisions within exact authority.
11. Readiness and publication owners decide deployment, delivery claims, and release; a terminal job receipt is not release approval.
12. Temporal, Airflow, BPMN, Kubernetes, Talos, VIEA, GenesisCode, Software Magic, and MoECOT supply lineage and implementation comparators, not local scheduler or runtime evidence.

Minimum fields:

• job_id
• contract_id
• job_type
• lifecycle_state
• runtime_adapter
• inputs
• outputs
• permissions
• approval_state
• failure_behavior
• audit_events
• replay_status

The current public schema is narrower than the expanded contract. It records basic job, contract, lifecycle, adapter, input/output, permission, approval, failure, audit, and replay fields, but not every attempt, lease, workspace, effect observation, idempotency, checkpoint, compensation, cost, expiry, parent-plan, or evidence-readiness field. Those gaps remain implementation residuals.

The job should emit a completion receipt:

• parent_contract_id
• plan_node_id
• approval_record
• permission_basis
• runtime_adapter_ref
• artifact_refs
• verification_refs
• audit_event_refs
• residuals
• replay_or_non_replay_reason
• delivery_state
• evidence_state

This receipt records the boundary needed to detect completion laundering. It does not by itself establish that every effect was observed or that the underlying work was authorized, correct, useful, safe, or evidence worthy.

41.9 Invariants

The invariants preserve work identity, authority, state, effects, and receipts across normal execution and faults. They define when a job remains in Labor OS custody without turning a complete record into proof that the work was correct.

1. Every admitted job binds one exact contract and plan-node version, type, objective, scope, inputs, expected artifacts, acceptance tests, consumer, consequence, risk, authority, rights, budget, deadline, expiry, and owner.
2. Job, attempt, lease, workspace, approval, permission, adapter invocation, effect, artifact, receipt, residual, and parent identities remain stable, distinct, and causally linked.
3. Lifecycle transitions use the declared state machine; requested, admitted, queued, leased, running, paused, retrying, delivered, evidence ready, failed, blocked, quarantined, cancelled, compensated, replayed, expired, and retired states never collapse into a generic done state.
4. Material contract, plan, input, adapter, policy, threat, environment, authority, rights, consumer, or deadline changes expire affected locks, approvals, permissions, leases, verification, and replay decisions.
5. Permissions, approvals, budgets, data access, secret handles, network access, side effects, disclosure, retention, and release authority are explicit, least-privilege, purpose-bound, revocable, and non-escalating across dispatch, retry, resume, delegation, and replay.
6. High-impact or irreversible work cannot dispatch without the exact required approval for the current job, effect class, authority, scope, conditions, and time.
7. Queue acceptance, scheduler assignment, lease acquisition, agent response, tool return, file existence, delivery, and user acknowledgment are not equivalent to durable completion or evidence readiness.
8. Actual reads, writes, tool calls, messages, external effects, artifacts, approvals, denials, failures, retries, interventions, costs, and cleanup remain independently observable.
9. Retry and resume preserve attempt lineage, fresh lease state, authorization, idempotency or compensation policy, checkpoints, observed prior effects, and duplicate-effect handling.
10. Lost workers, expired leases, partial effects, timeouts, policy changes, unknown outcomes, and residuals cannot become silent success; they route to exact recovery or terminal custody.
11. Workspace, secret, context, adapter, and cleanup boundaries preserve taint, rights, authority, retention, and side-effect obligations through every produced derivative.
12. Produced, delivered, adjudicated, verified, artifact-captured, replay-declared, evidence-ready, user-accepted, supported, and released states remain distinct.
13. Evidence-ready completion requires exact approvals, permissions, observed effects, artifacts, verification refs, audit refs, residuals, replay or non-replay declaration, costs, terminal receipt, and non-claims for the declared boundary.
14. Cancellation, compensation, rollback, expiry, revocation, cleanup, and retirement preserve irreversible effects, external copies, disclosures, downstream artifacts, open obligations, costs, and residuals.
15. Feedback, procedures, memory candidates, policy changes, model updates, and support changes pass through their owning gates and are never inferred from job success.
16. Fairness, priority, starvation, deadline, preemption, and resource decisions remain inspectable with rejected, delayed, cancelled, and abandoned work in the denominator.
17. Every attempt, failure, denial, retry, timeout, lease loss, intervention, partial effect, compensation, quarantine, appeal, human work, privacy exposure, delay, cost, missed help, and residual remains in the denominator.
18. Schemas, authored fixtures, finite route theorems, documentation comparators, and local green checks establish only their exact record, formal, source, and environment boundaries.

41.10 Failure modes

These failures either let work escape its admitted boundary or substitute an operational status for an observed consequence. The taxonomy keeps authority, effects, recovery, delivery, evidence eligibility, and cost failures visible:

1. Ambient-agent execution allows work or side effects without an admitted typed job, exact parent contract, authority, owner, or terminal receipt.
2. Contract or plan drift executes stale, widened, substituted, or outcome-edited work after the material boundary changed.
3. Lifecycle laundering treats queueing, leasing, running, output, delivery, acknowledgement, or idleness as completion or evidence readiness.
4. Permission and approval laundering widens grants, reuses stale approvals, self-approves, delegates beyond authority, or dispatches irreversible work without the current gate.
5. Tool, adapter, workspace, network, data, or secret overreach crosses the declared capability, purpose, context, isolation, disclosure, or retention boundary.
6. Unlogged-effect laundering omits actual reads, writes, messages, tool calls, disclosures, external changes, costs, or side records from receipts.
7. Scheduler theater reports a planned or available queue while work is starved, unfairly prioritized, repeatedly preempted, or never dispatched.
8. Lease and worker amnesia loses ownership, heartbeat, expiry, checkpoints, locks, prior effects, or terminal custody after crash or partition.
9. Retry duplication repeats non-idempotent effects, widens authority, reuses stale inputs, or resumes without reconciling prior partial outcomes.
10. Compensation and rollback laundering reports restoration while external effects, disclosures, artifacts, messages, model updates, or descendants remain.
11. Swarm explosion creates unbounded recursive jobs, duplicate work, circular dependencies, uncontrolled delegation, contention, or unauditable coordination.
12. Parentage loss severs job, attempt, contract, plan, approval, permission, context, adapter, artifact, and residual lineage.
13. Artifact and receipt theater accepts empty, stale, unverifiable, self-reported, wrong-environment, or reality-false outputs as completed work.
14. Delivery and evidence laundering converts user-visible output into verified, replayable, supported, safe, or released standing.
15. Failure and residual abandonment leaves blocked, quarantined, timed-out, partially effective, disputed, or expired jobs without owner, recovery, expiry, or terminal record.
16. Feedback and learning laundering turns successful work into silent plan edits, procedural memory, policy changes, model updates, or support promotion.
17. Failure and cost survivorship removes rejected, delayed, cancelled, retried, human-repaired, privacy-expensive, slow, missed-help, or residual work from comparisons.
18. Portability theater treats one authored fixture, scheduler, orchestrator, backend, model, domain, authority regime, fault schedule, or horizon as general Labor OS evidence.

41.11 Minimum Viable Implementation

The current minimum is an authored zero-model record-and-route scaffold:

• one public typed-job schema;
• three valid and ten rejecting plan-execution fixtures;
• two valid and seven rejecting delivery/evidence-readiness traces at experiments/typed_job_delivery/results/2026-07-02-local.json;
• two valid and nine rejecting durable-lifecycle traces at experiments/typed_job_durable_lifecycle/results/2026-07-02-local.json;
• one accepted no-promotion decision at evidence_transitions/v1_x_measured/typed_job_durable_lifecycle_probe_no_change.json; and
• a seven-stage AsiStackProofs.TypedJobRefinement contract-lock, authorization, dispatch, execution-observation, adjudication, and acknowledged-closure lifecycle with twenty-nine routes, thirty-two declarations, and an independent consumer that rejects 42/42 mutations; and
• twenty-four retained exact approval, execution-route, and durable-lifecycle declarations, with three validity/summary projections physically retired, for 56 live declarations across two modules and five public targets.

The reachable refinement preserves represented job, contract, plan, authority, permission, lease, scheduler, retry, cancellation, adjudication, residual, and consumer custody without executing their services. The retained legacy declarations remain finite approval, route, and negative-case consequences. The Python fixtures reject contract/receipt gaps, approval bypass, permission overreach, delivery laundering, missing artifacts/audit, retry without idempotency, authority widening, expired-lease dispatch, missing replay/residual/non-claim fields, and fixture-driven support promotion.

No current artifact runs a scheduler, worker, workspace, secret broker, permission or approval service, adapter, independent effect observer, durable workflow engine, Temporal/Airflow/BPMN/Kubernetes integration, natural multi-step workload, useful-advantage comparison, causal ablation, clean reproduction, or transfer. The public schema is narrower than the expanded contract, and the finite theorems do not connect to a runtime implementation.

The next honest minimum must execute prospectively frozen natural multi-step work through actual scheduler, worker, workspace, permission, approval, adapter, artifact, crash, retry, recovery, compensation, adjudication, delivery, and evidence-readiness paths. Strong chat, ambient-agent, swarm, script, queue, Airflow-like DAG, Temporal-like durable workflow, BPMN/process, Kubernetes batch-job, and governed typed-job routes must receive matched work, models, tools, authority, resources, faults, and time.

Independent observers must measure authorized useful completion, unauthorized or unobserved effects, lifecycle and receipt correctness, duplicate effects, recovery, compensation closure, evidence-readiness error, false refusal, missed help, latency, privacy, human work, fairness, starvation, and total cost. Mechanism ablations, clean reproduction, and transfer across a second model, domain, backend, scheduler, organization, authority regime, fault schedule, and time period precede promotion.

41.12 Mature Research Target

A mature Labor OS executes bounded cognitive work through actual schedulers, workers, workspaces, permissions, approvals, adapters, artifact capture, effect observation, retries, crash recovery, compensation, adjudication, delivery, and evidence-readiness gates. Ambient agents become implementation details behind typed jobs rather than independent sources of authority.

Its frontier is joint: useful authorized throughput, lifecycle accuracy, external-effect fidelity, duplicate-effect rate, recovery and compensation, receipt truth, false refusal, missed help, latency, privacy exposure, human burden, fairness, starvation, and total cost. Chat, ambient agents, swarms, scripts, queues, DAGs, durable workflows, process engines, and batch jobs form strong matched baselines rather than straw comparisons.

Every proposed mechanism needs a prospective causal signature under matched ablation. Removing permission snapshots changes unauthorized effects; removing leases and idempotency changes duplicate effects and recovery; removing delivery/evidence separation changes false evidence readiness; removing complete denominators changes apparent efficiency. Clean replay and transfer across models, domains, backends, schedulers, organizations, authority regimes, fault schedules, and time remain separate gates.

Failed gates produce exact null, negative, narrowed, refuted, deprecated, cost-dominated, or blocked-after-full-attempt results. They do not become a deployed Labor OS claim because the job records look orderly.

No current result meets this accountable-delivery endpoint; support remains argument until natural jobs, independent outcome and effect observation, fault campaigns, complete costs, reproduction, and transfer pass.

41.13 Codex test plan

Test	Purpose	Status
Typed job fixture validation	Check that the typed-job fixture matches the public schema and declares contract, type, lifecycle state, adapter, inputs, outputs, permissions, approval state, failure behavior, audit events, and replay status.	implemented by protocol validation; validated locally
Typed job lifecycle predicate	Check that a transition record marked valid uses the declared finite lifecycle relation.	implemented in AsiStackProofs.TypedJobs; checked by Lean build
Typed-job versioned execution and closure refinement	Check exact job, contract, plan, authority, permission, lease, scheduler, retry, cancellation, artifact, audit, verification, receipt, replay, residual-owner, and consumer custody while separating represented execution from support assignment and external effects.	implemented by python3 scripts/validate_typed_job_refinement.py: exact 32-declaration surface, arbitrary-run lifecycle and custody invariants, exact 2/7 delivery and 2/9 durable suites, seven stages, twenty-nine routes, and 42/42 rejected mutations; support-state effect none
Plan-execution typed-job dispatch harness	Check that active typed jobs match the command contract, appear in dispatch receipts, and do not bypass required approval.	implemented in python3 scripts/validate_plan_execution_contracts.py; synthetic records only
Job execution route proof	Check that a finite job-execution review routes missing jobs, unlocked contracts, invalid lifecycles, missing approvals, missing permissions, observed failures, residuals, unverified delivery, verified delivery, scheduler-slot waits, dispatch-ready jobs, and retirement requests to explicit outcomes.	implemented by Lean build; finite job-execution route coverage only
Tool permission enforcement test	Check that declared permissions cover requested adapter capabilities.	planned; not run
Human approval gate predicate	Check that an approval-required job cannot be allowed to run before approval is recorded.	implemented in AsiStackProofs.TypedJobs; checked by Lean build
Typed job delivery and evidence-readiness probe	Check that verified delivery and delivered-but-not-evidence-ready states remain distinct, parentage is present, approval and permissions gate evidence readiness, artifact/audit refs exist, and fixture output cannot promote support.	implemented in python3 scripts/validate_typed_job_delivery_probe.py with two valid synthetic typed-job traces and seven expected-invalid controls; no deployed scheduler, permission-enforcement, approval-service, runtime-adapter, replay-correctness, support-state-promotion, or evidence-transition claim
Typed job durable lifecycle probe	Check that retry/resume, lease blocking, completion receipts, replay refs, residual owners, non-claim boundaries, and fixture support-state boundaries are recorded.	implemented in python3 scripts/validate_typed_job_durable_lifecycle_probe.py with two valid synthetic durable lifecycle traces and nine expected-invalid controls; no deployed scheduler, durable workflow recovery, permission-enforcement, approval-service, replay-correctness, support-state-promotion, or upward evidence-transition claim
Delivery versus evidence-ready test	Check that delivered jobs without verification, artifact capture, audit, residual, and replay/non-replay fields cannot support promotion.	implemented as deterministic synthetic typed-job delivery fixture; deployed delivery/evidence runtime not implemented
Job parentage trace test	Check that each job traces to parent contract, plan node, approval if needed, adapter, artifact, and residual records.	implemented as deterministic synthetic typed-job delivery fixture; deployed job parentage service not implemented

Fixture-shape validation, bounded Lean predicates, the finite job-execution route proof, the synthetic delivery/evidence-readiness probe, and the synthetic durable lifecycle probe are implemented. The remaining tests require a lifecycle checker, deployed permission harness, approval service, adapter runner, durable workflow engine, replay engine, or job runner that can reject invalid transitions, missing approvals, unauthorized effects, invalid retries, expired leases, missing receipts, and completion laundering in an executable environment.

41.13.1 Formalization hooks

Tag	Module	Target	Status
lean:jobs.lifecycle.operational_invariant	AsiStackProofs.TypedJobRefinement	A reachable versioned typed-job lifecycle preserves exact job, contract, plan, authority, permission, lease, scheduler, and consumer custody from lock through acknowledged closure without assigning support or external effects.	implemented
lean:jobs.lifecycle.failure_blocks_promotion	AsiStackProofs.TypedJobRefinement	Approval, permission, lease, scheduler, retry/idempotency, cancellation, artifact/audit, verification, completion/replay, residual-owner, and consumer-acknowledgment failures block lifecycle progress.	implemented
lean:jobs.lifecycle.execution_route_envelope	AsiStackProofs.TypedJobRefinement	An independent consumer covers twenty-nine typed-job lifecycle routes and rejects 42 identity, ordering, authority, approval, permission, lease, retry, cancellation, artifact, audit, adjudication, receipt, replay, residual, and acknowledgment mutations.	implemented
lean:jobs.lifecycle.delivery_probe_fixture_bridge	AsiStackProofs.TypedJobRefinement	The versioned lifecycle consumer preserves the exact two-valid/seven-invalid typed-job delivery suite without treating delivery or verification fields as task success, output truth, support, or external effects.	implemented
lean:jobs.lifecycle.durable_lifecycle_probe_bridge	AsiStackProofs.TypedJobRefinement	The versioned lifecycle consumer preserves the exact two-valid/nine-invalid durable retry and lease suite without treating declared idempotence, recovery, enforcement, receipt, or replay fields as real service behavior.	implemented

The family contains 56 live declarations across two modules: thirty-two reachable refinement consequences/countermodels/witnesses plus twenty-four retained exact approval, execution-route, and durable-lifecycle declarations. The valid-record projection and two authored-summary bridges are physically retired with frozen lineage. All five public targets resolve to the refinement. They do not make trusted fields, route order, or a represented execution observation into runtime behavior, task success, semantic evidence, support, or effects.

These declarations do not prove scheduler behavior, worker custody, permission enforcement, approval authority, workspace or secret isolation, adapter-effect fidelity, idempotency, crash recovery, compensation closure, artifact reality, delivery correctness, evidence readiness, useful throughput, fairness, safety, or transfer.

41.14 Source crosswalk

Source ID	Title	Layer	Planned use	Readiness
talos	Talos Protocol	labor_execution_os	AI labor OS. Deterministic cognitive manufacturing, typed jobs, control planes, auditability, tool isolation.	source note available; local raw cache available
viea	Verified Intent-to-Execution Architecture	whole_stack_execution_spine	Keystone source. Human intent -> command contracts -> artifacts -> routing -> runtime targets -> verification -> deployment -> feedback.	source note available; local raw cache available
genesiscode	GenesisCode	executable_specification	Tiny pure calculus + obligations + provenance for auditable AI-symbiotic programming.	source note available; local raw cache available
software_magic_grimoire	Software Magic Grimoire	command_contracts_promptcraft	Structured command contracts and semantic density of software words.	source note available; local raw cache available
talos_md	Talos_Protocol_v1.0.md	labor_execution_os	Markdown/public release version.	source note available; local raw cache available
moecot	MoECOT-Agent Architecture Whitepaper	implementation_reference	Concrete implementation evidence: governed low-parameter multi-core runtime, readiness gates, ledgers, replay.	source note available; connector or recovery required
ext_temporal_docs	Temporal Documentation: What is Temporal?	durable_execution	External comparator for durable workflow executions, event histories, worker processes, and failure recovery.	source note available
ext_airflow_dag_docs	Apache Airflow Documentation: Dags	workflow_orchestration	External comparator for DAG schedules, tasks, dependencies, callbacks, retries, and timeouts.	source note available
ext_bpmn_2_0_2_spec	Business Process Model and Notation Specification Version 2.0.2	business_process_modeling	External comparator for stakeholder-readable process notation and translation into software process components.	source note available
ext_kubernetes_jobs_docs	Kubernetes Documentation: Jobs	batch_job_lifecycle	External comparator for finite batch-job completion, failure, retry, deadline, terminal condition, and cleanup vocabulary.	source note available

The labor-OS sources support typed execution discipline across lifecycle, permissions, approvals, artifacts, and replay. Four local raw-cache sources and the complete authenticated moecot connector text have passage-reviewed mappings, while talos_md remains a same-lineage variant. External comparators ground durable workflow, DAG orchestration, process-notation, and batch-job lifecycle vocabulary. This does not claim a Talos, MoECOT, GenesisCode, VIEA, Temporal, Airflow, BPMN, or Kubernetes labor runtime has been executed in this repo.

41.14.1 Manifest source assignment reconciliation

These rows keep Labor OS and Typed Jobs’s manifest assignments visible at their recorded review boundary. Passage review does not establish local reproduction, performance, safety, deployment, or support-state movement.

Source	Intake role	Boundary
deterministic_capability_compilation	Passage-reviewed Corben architecture source: Deterministic Capability Compilation: A Capability-Preserving Ladder from Executable Scaffolds to Governed Adaptive Agents. Corben-authored July 2026 architecture and research program for compiling executable scaffolds into contract-bound experts and linked Neural Capability Objects while retaining semantic obligation mass balance, candidate-specific translation validation, fallback, residual escrow, authority ceilings, reification, and effect-complete recovery. Existing chapters are upgraded first; no foundry implementation, learned-capability result, preservation result, safety result, SOTA result, AGI, ASI, or support-state promotion is inferred.	No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.

41.15 Summary

Labor OS and Typed Jobs owns admitted work lifecycle and terminal receipt custody. It keeps contract and plan parentage, authority, approvals, permissions, attempts, leases, workspace, adapter, observed effects, artifacts, costs, failures, delivery, evidence eligibility, compensation, and retirement attached to one bounded work history.

The present evidence is an authored zero-model scaffold: one schema, three fixture families, one no-promotion decision, and fifty-six finite declarations. It establishes record and route discipline only. A scheduler, runtime effects, recovery, useful advantage, causal contribution, reproduction, and transfer remain unshown.

Produced artifacts and receipts pass next to Artifact Graphs. Labor OS records which attempt produced them and under what job state; Artifact Graphs determines their durable identity, provenance, replay grade, and evidential continuity.

The useful boundary is accountable delivery: work may finish, fail, or expire without silently becoming evidence.

41.16 Evidence reconciliation (2026-07-16)

The invariant protocol, field meanings, and inference limits are stated once in Living Book Methodology. This packet contains only the chapter-specific projection; its authoritative per-atom rows are the labor-os-and-typed-jobs slice of experiments/claim_family_terminal_coverage/results/result.json.

The core remains blocked after full attempt at argument support. The strongest family attempt was Intent-to-execution vertical refinement. Its exact boundary is: Structured local scenarios only; no natural-language semantic sufficiency, production backend, transfer, or deployment claim. Across 76 atoms, the terminal ledger records 76 blocked_after_full_attempt.

Chapter-specific field	Value
Family / atom denominator	CF-03 / 76 atoms
Terminal dispositions	76 blocked_after_full_attempt
Core	labor-os-and-typed-jobs.core: blocked_after_full_attempt at argument
Core attempted / missing lanes	source-synthesis / causal, empirical, executable, formal, normative, transfer
Attempted local lanes	source-synthesis
Missing or unproved lanes	causal, empirical, executable, formal, normative, transfer
Strongest family bundle	Intent-to-execution vertical refinement (end_to_end): Nine versioned scenarios and 89 events from governed intake through six observed local effects and terminal outcomes.
Negative controls	pre-effect refusal; failed rollback quarantine; 30 rejecting mutations.
Accepted transitions	none
Maximum inference	Structured local scenarios only; no natural-language semantic sufficiency, production backend, transfer, or deployment claim.
Reproduction / next burden	Replay scripts/validate_intent_execution_vertical_refinement.py and scripts/validate_claim_family_terminal_program.py; fill the named atom-specific lanes under a new prospective protocol.

41.17 Handoff

Typed jobs give execution a bounded work unit. From Chat to Organizations: AI Work Surfaces and Agent Harnesses next asks what changes when the system absorbs a larger unit: answer, suggestion, task, project, role, team, organization, or network. It preserves the Labor OS boundary by treating each expansion as a separately admitted change in context, tools, authority, review, effects, and residual custody rather than as an automatic consequence of job completion.