Explanation

The Delegated-Work Loop

How OOMU organises real work, and proves what it actually did.

Answering questions is the easy part. The harder, more valuable thing is delegated work: you hand OOMU a job, walk away, and come back to a finished result you can trust. OOMU is built around one loop that makes that safe:

Configure a Project once → delegate or schedule work → intervene only when asked → receive a polished artifact → inspect verified evidence → run it again.

This page explains the two structures that hold that loop together; Tasks and an honest evidence vocabulary, and how delegation and learning build on them.

Why "Task" is a first-class idea

OOMU runs many kinds of work: chat-driven agent actions, workflow runs, scheduled Routines, browser and Mac-app automation, document builds, and delegated helpers. If each kept its own private history, you could never get a straight answer to "what is OOMU doing, and did it work?"

So every runtime reports into one Task control plane. A Task is the canonical record of a unit of work, with a shared lifecycle:

You can see everything that is running, waiting, blocked, finished, failed, or cancelled in one place (Tasks → Now), filtered by Project.
You can cancel, resume, retry, or acknowledge a failure, and the control is routed to the runtime that actually owns the work.
Retries are safe. Effectful steps carry idempotency records, so retrying a task that already sent an email or wrote a file does not do it twice.
Restarts are safe. If OOMU (or your Mac) restarts mid-task, it reconciles each unfinished task against its owning runtime. Work with valid authority resumes; anything it can't verify is marked lost; never quietly reported as success.

The Task plane is a read-and-control model over the real runtimes, not a second execution engine. It observes and steers; it doesn't re-implement.

The evidence vocabulary

The most important idea in OOMU's design is that it refuses to blur five very different things. When OOMU reports what happened, it keeps these distinct:

Level	What it means	Example
Model assertion	The model said something.	"I updated the spreadsheet."
Observed result	OOMU looked and saw a state.	A fresh snapshot shows the new value in the cell.
Executed mutation	OOMU actually performed a change through a permissioned action.	The write went through the sandbox with your approval.
Verified postcondition	OOMU checked the change against an expected outcome.	The file now parses, the page shows the confirmation, the PDF renders.
Signed artifact	A final output bound to its provenance with a signature.	The exported PDF plus a receipt of its hash, source task, and checks.

A model *claiming* it did something is the weakest possible evidence, and OOMU treats it that way. A browser automation "click" isn't done until a post-action observation confirms it. A document isn't finished until it's rendered and structurally checked. This is why OOMU can be trusted to work unattended: it doesn't confuse intention with result.

This is also why some things deliberately *stop*. When OOMU can't verify; a stale reference, a CAPTCHA, an ambiguous dialog; it pauses and asks, rather than guessing and reporting a success it can't stand behind.

Authority stays in one place

No connector, workflow, model, background helper, remote device, or child agent can grant permission. Every consequential action flows through the native authority boundary (the "Shield"), which evaluates it against the current Project policy and your approval. A few consequences of that single rule:

Approval scopes let you approve a *class* of action once (reviewed, audited) instead of clicking through every step; without handing over blanket authority.
Headless work fails closed. A Routine running while you're away can only do consequential things it was pre-authorized for; a missing approver never becomes an approval.
Irreversible actions always confirm. Nothing destructive or outward-facing happens silently.

Delegation: many hands, one authority

For research-heavy work, a parent Task can fan out to a bounded set of helpers; read-only workstreams running in isolated contexts, each with its own goal, sources, budget, and no ability to write, send, or change anything. They *gather*; the parent *decides*. The parent alone synthesises the findings and performs any mutation, behind your approval, and the interface keeps child findings visibly separate from verified conclusions.

This gives you the throughput of parallel work without multiplying authority or blurring whose evidence is whose.

Learning: getting better, reversibly

When a Task succeeds, OOMU can notice a repeatable method and *offer* to remember it; "Want OOMU to remember this?" Nothing is learned silently:

You review, edit, scope (this Project or everywhere), or reject each offer.
Learned methods are stored as declarative, versioned recipes that run through normal Task authority; not as opaque replays.
You can turn one off, roll it back, or forget it entirely, and OOMU tracks whether it actually saved you effort.
Secrets, unverified claims, identity, permissions, and executable code can never become learned state. Learning improves *method*, never authority.

The loop, end to end

Put together: you set up a Project with its folders and data policy; you ask for work directly, as a workflow, or on a schedule; OOMU runs it as a Task, escalating to helpers or connected tools only as allowed; it produces a verified document; you inspect the evidence behind it; and; if it went well; you let OOMU keep the method for next time. Every step is local-first, permissioned, and auditable.