Human Authority
Pioneer separates reasoning from consequential action. Inspection can inform a proposal, but a proposal does not grant permission to change state.
The boundaries
| Boundary | What it permits | What it does not permit |
|---|---|---|
| Proposal | Explain a candidate change and evaluate it against current guards. | Apply, save, run, or claim that anything changed. |
| Apply to draft | Attempt the approved mutation against the guarded current Canvas draft. | Save the draft or run it. |
| Apply to saved Flow | Attempt an atomic update to one identified saved Flow revision. | Update an open draft or run the Flow. |
| Save | Persist the current definition as a saved Flow revision. | Execute it. |
| Run approval | Attempt one execution of an identified saved Flow snapshot. | Approve later runs or nested Script execution. |
| Nested Script approval | Permit the specific Script boundary presented during a run. | Broaden the parent run approval or authorize other Scripts. |
| Execution | Record that an operation ran and reached a reported state. | Prove success or correctness. |
| Verification | Compare explicit baseline and post-change evidence. | Automatically repair, retry, rerun, or declare causality. |
In short:
proposal != apply
apply != save
save != run
run approval != nested Script approval
execution != success
verification != automatic repair
Approval is specific
An approval belongs to the action and resource identity shown at the approval boundary. For Flow changes, that identity includes the target and its guards, such as saved Flow ID, revision, and fingerprint.
Approval is permission to attempt the action. Pioneer rechecks live guards after approval. If the Canvas or saved Flow changed while the request was waiting, the operation stops as stale instead of silently rebasing the proposal.
Assent is not always an action request
A response such as “looks good” can acknowledge a proposal without asking to mutate anything. Use explicit language such as “apply this proposal to the current draft” or “run the saved Flow.”
Nested work cannot borrow authority
Read-only delegation and nested orchestration are constrained to observation. They cannot use a parent conversation or approval to widen their authority into mutation or execution.
A saved Flow run and a Script inside that run are also distinct boundaries. The run can be approved while a consequential Script still waits for its own approval. Rejecting, cancelling, or timing out that Script decision remains visible in execution evidence.
After a repair proposal
A safe repair sequence is deliberately explicit:
- inspect one identified failed run;
- ground the diagnosis in evidence IDs;
- inspect the current target and retain its guards;
- evaluate a structured proposal without changing state;
- ask the person to approve the exact apply action;
- report whether the change was applied and whether it was persisted;
- request separate authority for a rerun; and
- compare the baseline and verification runs without automatically looping.
This separation makes it possible to answer “what was proposed?”, “what changed?”, “what was saved?”, “what ran?”, and “who authorized it?” independently.
Why is Pioneer asking me again?
Because the new prompt authorizes a different consequence:
- approving a Chat change to the current Canvas draft lets Pioneer attempt that guarded in-memory mutation; saving it creates durable state;
- approving a saved-Flow change permits one atomic revision update; executing that revision can read data, call providers, or write outputs;
- approving the Flow run permits submission of that exact saved snapshot; and
- approving a nested Script permits native code with its own source identity, working directory, environment, and effects.
The repetition is not a request to approve the same thing twice. Each decision has a different target and consequence.