Product / How it works
A simple request, a rigorous lifecycle
Describing an outcome in one sentence is easy for the user. Making that sentence resolve into a verified result reliably is the hard engineering problem underneath Omnacta OS. This is the ten-stage lifecycle that does it.
Stages 1, 4, and 5 are implemented for the engineering reference workflow today; later stages have varying maturity, disclosed per step below.
The canonical walkthrough
Every mission moves through these ten stages. Each includes what the user sees, what the OS does, why the stage matters, and its current evidence or limits.
Describe the outcome
What you see: A single field for the desired result, in plain language.
What the OS does: Accepts free-form intent as the mission seed.
Why it matters: Removes the burden of pre-structuring a request before the system can act.
Convert to requirements and acceptance criteria
What you see: A structured restatement of the request with explicit acceptance criteria to confirm or edit.
What the OS does: Extracts constraints, success conditions, and open questions from the described outcome.
Why it matters: Acceptance criteria decided up front prevent the system from grading its own work later.
Assemble minimum sufficient context
What you see: A visible list of what was read, summarized, or excluded, not a black box.
What the OS does: Collects structural, lexical, semantic, and Git context bounded by an active stopping certificate.
Why it matters: More context is not better context; unbounded context wastes tokens and buries the signal.
Produce a versioned plan and dependency graph
What you see: An inspectable plan with ordered steps and dependencies before execution starts.
What the OS does: Builds an immutable, versioned plan the scheduler owns for the mission lifetime.
Why it matters: A plan that can be inspected before it runs is a plan that can be corrected before it runs.
Select workers, models, tools, and Mission Packs
What you see: The specific capabilities chosen for this mission and why.
What the OS does: Negotiates capability requirements against available workers, model routes, and installed Mission Packs.
Why it matters: Capability selection is policy-governed, not a fixed hardcoded chain.
Grant scoped authority and budgets
What you see: Explicit boundaries: what the mission can touch, spend, and for how long.
What the OS does: Issues time-boxed, path- and resource-scoped capability tokens rather than ambient permission.
Why it matters: Autonomy without an authority boundary is not autonomy, it is exposure.
Execute with checkpoints, leases, and recovery
What you see: Progress that survives an interruption instead of restarting from zero.
What the OS does: Persists checkpoints and leases so work can resume after a disconnect, crash, or worker loss.
Why it matters: Long-running missions must outlive the client session that started them.
Verify evidence against acceptance criteria
What you see: A pass/fail/blocked verdict tied to the criteria set in step 2, not a self-reported "done".
What the OS does: Runs verification against captured evidence and the acceptance criteria index.
Why it matters: An agent claiming completion is not the same as a verified outcome.
Repair or block honestly when evidence fails
What you see: An explicit block with a reason, or an automatic repair attempt, never a silently wrong success.
What the OS does: Compares failure classes against retry and repair policy; escalates when it cannot safely proceed.
Why it matters: A system that hides failure is more dangerous than one that reports it.
Deliver changes, artifacts, and inspectable proof
What you see: The actual diff, document, or artifact plus the evidence trail behind it.
What the OS does: Packages the outcome with its verification record for review and acceptance.
Why it matters: Delivery without provenance cannot be trusted or audited later.
Current constraints
This walkthrough describes the target lifecycle. It is not a claim that every stage runs at production maturity for every domain today.
- Requirements extraction quality varies with mission complexity and domain.
- Capability selection currently covers the engineering Mission Pack only.
- Recovery guarantees are proven for local reference execution, not yet for every distributed deployment mode.
- Verification scope and known evidence-integrity boundaries are detailed on the Evidence page.
See the lifecycle in the product
Studio presents this lifecycle as a live, inspectable surface once implementation reaches that maturity.