Saved, approved, started, completed: automation states
Keep saved drafts, reviewed versions, invocations and completed runs separate across automation formats.
Ouros editorial team
Saving an automation records something you can review. Approval records a decision about it. Starting creates work. Completion describes the outcome of that work. Keep those events separate, especially when more than one execution system is involved.
Follow the right identity
In a hosted loop workflow, a loop can have several versions. A run is an attempt to execute work, not another name for a version. An invocation identity helps you find a request, while a run identity helps you inspect its execution. Write down which object you are looking at before interpreting a status.
The public loop reference describes these read routes:
GET /hvy/v1/loops
GET /hvy/v1/loops/{loopId}/versions/{version}/artifact
GET /hvy/v1/loops/invocations/{idempotencyKey}
GET /hvy/v1/loops/runs/{runId}
These are method-and-path references, not ready-to-run requests. The placeholders identify objects; they do not supply a service address, authentication or permission to act. Do not add guessed credentials or send requests to a made-up host to make the example executable.
Consider a review of version three. A reviewer approves that version. Someone then edits the draft. The approval of version three does not automatically describe the new draft, and a successful run of an older version does not verify the new one. Tie the review and result to the exact version they concern.
Do not mix two formats
A governed action workflow is a separate track from a hosted loop artifact. This example describes a prepared note-saving action with start set to false:
{
"schema": "ouros.loop-execution.v1",
"name": "Save a reviewed note",
"revision": 1,
"steps": [
{
"functionId": "notes.save",
"functionRevision": 1,
"args": {
"title": "Reviewed note",
"body": "This text was reviewed before preparation."
}
}
],
"start": false
}
Reading or downloading this JSON does not save a note. The example is a shape to study, not a universal import format or an instruction to submit it to one of the hosted routes above. The function identity and revision belong to this governed example. They do not make it interchangeable with a hosted version artifact.
This distinction is practical. A page that shows “saved” might mean a draft was retained. It might not mean a version was approved, a schedule activated or a run started. Read the object and the action together instead of interpreting one reassuring word as all four events.
Review before starting, inspect after starting
Before a real action, identify the exact version or prepared input, intended effect, required access and person authorizing it. Check the output destination and the consequences of repeating the action. For scheduled work, include the schedule identity and whether it is actually active; saving schedule text is not evidence that anything will run.
After starting, retain the request and run identities. An accepted request is not a completed job. MDN's explanation of HTTP 202 makes that distinction explicit: acceptance does not promise eventual success. Inspect the existing run and its actual output before declaring the task finished.
Use the review card to record those facts, and the state explorer to practice the distinctions without starting anything. Neither tool activates a schedule or performs a product action.