Concepts
Runs, approval and review
A run is the durable record of one admitted piece of work. It keeps the exact task, source, requester, policy, status and output, so anyone with access can see what was asked, what was allowed and what happened.
What a run records#
Runs are stored by Core, not by the window that started them. Closing a tab, reloading or switching devices does not lose a run or change its status. Retrying a request with the same identity returns the same run instead of creating a duplicate.
- RequestedExact task, source, policy
- ReviewIf the Project requires it
- QueuedAdmitted by Core
- RunningHarness in its environment
- CompletedResult returned
- VerifiedChecks passed
- AcceptedBy a person
- Failed
- Cancelled
- Interrupted
- Outcome unknown
- Changes requested
Approval binds to exact intent#
When a Project requires review before work starts, an approver sees the exact task, source, requester and full policy. Their approval is bound to a fingerprint of exactly that content. If anything changes before they decide — the task, the source or the policy — the approval no longer applies and must be requested again.
- Only a current owner, admin or approver of that Project can approve. Losing the role between opening the review and pressing approve is enough to block it.
- An approval admits the run. It does not grant extra source access, change device consent or declare the result correct.
- A decision cannot be recorded twice. After an uncertain response, refresh the run instead of approving again.
Completion, verification and acceptance#
These three words are easy to blur. Floating Keys keeps them apart because each one answers a different question.
| State | Question it answers | Who decides |
|---|---|---|
| Completed | Did the agent stop and return a result? | The run’s own lifecycle |
| Verified | Did the configured checks — tests, audits, policy — pass on that result? | Automated checks recorded with the run |
| Accepted | Does a person agree this result should stand? | A human reviewer |
Failures and unknown outcomes#
Failed, cancelled and interrupted runs keep their status. When the outcome of an outside action is genuinely uncertain, the run says so instead of guessing. Inspect the existing run before trying again; do not create a replacement for work that may already have happened.
Child runs and self-driving goals#
- DelegationLocal
- A run can create bounded child runs, each with its own thread and traceable link to the parent. Delegation is off by default and enabled per Project.
- Self-driving modeLocal
- You record an explicit, versioned goal with acceptance criteria and press Start working. A supervisor run works within configured time, run and child limits. Pause, resume and stop are server operations. Completion still requires review of acceptance evidence.
- Scheduled and recurring workPlanned
- Recurring runs are planned after the hosted scheduler, overlap and missed-run behavior are specified and tested.
Status reflects September 2026. Planned items are design targets, not commitments to a date.