Get started

How a run works

The useful unit is an accepted work outcome, not a response and not a technically completed run. Every run follows the same seven-stage contract.

The outcome has to be usable, supported by evidence, and ready for the named owner to approve.

  1. 01IntakeYou name the outcome, owner, source material, constraints, exceptions, and completion test.
  2. 02PlanOpulent turns the request into bounded work packages and identifies the decisions that need approval.
  3. 03ExecuteThe run uses approved tools, files, applications, code, and connected systems.
  4. 04ContinueThe workflow waits for a reply, approval, authentication, schedule, or outside event without discarding verified state.
  5. 05VerifyOpulent checks the artifact and the system state, records evidence, and lists unresolved exceptions.
  6. 06ReviewA person accepts the outcome, requests a change, or makes the consequential decision.
  7. 07ImproveReviewed evidence can become a scoped candidate update to Knowledge, a Skill, a validator, a tool rule, or routing guidance.

Completion is semantic rather than ceremonial. Sending a final message does not finish the job while required tools, artifacts, checks, or decisions remain unsatisfied. When a long run reaches a safe execution boundary, Opulent yields and continues under the same workflow instead of presenting partial work as complete.

A useful request has five parts

PartQuestion it answers
JobWhat should exist when the run is complete?
ContextWhich files, systems, examples, and prior decisions are authoritative?
BoundariesWhat may Opulent change, and what must it leave alone?
ProofHow should the result be checked?
ReviewWhich decisions or exceptions must come back to a person?

A request missing the fourth part produces work you cannot check. A request missing the fifth produces a decision nobody agreed to. Those two omissions cause most disappointing runs.

Waiting is part of the run

Real work pauses. An approval takes a day, a vendor replies on Thursday, an OAuth handoff needs a person at a keyboard. A run that loses its state during a pause forces someone to reconstruct the job, which is the cost the system exists to remove.

Opulent holds verified state across those pauses. If a tool requires OAuth, the run presents the connection step and resumes the exact run after you authenticate, with the same workspace, evidence, and pending action. If a decision is yours, the run stops before the consequential action rather than after it.

What finishing means

A run is finished when the named artifact exists, the stated checks pass, the system writes are confirmed, and the exceptions are either resolved or explicitly routed. Anything less is reported as unfinished with the remaining work named, which is more useful than a confident summary over an incomplete job.