GDP keeps technical capability, an AI or user request, the current local permission envelope, and fresh execution evidence as separate facts. This separation is the foundation for safe manual and delegated automation.
Separate capability, request, policy, and evidence
Capability describes what a connected GDP component can technically do. A request describes what an AI, user, or workflow asks GDP to do. Policy describes what the exact current target and local permission envelope allow. Evidence records what an authorized action actually produced.
Collapsing these layers creates false success and unsafe authority. A visible tool, a submitted request, a plan entitlement, a continuation lineage, or agreement between agents can be relevant context without proving that the exact current operation was authorized or completed.
Request is not authority.
Technical capability is not permission for the current task.
Billing, license, entitlement, or account state does not create repository or terminal authority.
A model statement is not execution evidence.
Distinguish queue, execution, and proof
GDP intentionally records intermediate states. A patch can pass Patch Doctor, enter local intake, and still not be applied. A Suggested Check can be accepted as structured metadata and still not have run. A command can run and fail. Each state needs its own evidence.
For repository work, strong evidence includes current Git status or diff, exact patch/apply receipts, command exit codes, bounded command output, and recorded GDP check runs tied to the relevant repository or operation.
Identify the exact repository, task, node, or operation whose outcome matters.
Read the current GDP state instead of inferring from an earlier assistant response.
Separate intake or queue evidence from material apply or command evidence.
Read verification evidence for the effect that actually ran.
Continue only from the first step that remains unproven.
queued=true, a green transport response, or a confident assistant message cannot substitute for fresh material evidence.
Use delegated automation without widening authority
Active, AFK, Custom, and Run Everything change how GDP Desktop evaluates and continues eligible local work. They do not turn the hosted gateway or model into an unrestricted shell and they do not erase exact-target, risk, command, timeout, lease, or evidence checks.
A durable Lane, continuation package, previous approval, coworker message, account plan, or replacement worker also cannot transfer authority that the destination worker or current target does not independently have.
Delegation can reduce repeated prompts inside a previously selected envelope.
Foreground or otherwise specially gated work can still require explicit local action.
Uncertain mutations must be reconciled rather than blindly replayed.
Completion still depends on the applicable fresh proof, not on how autonomous the workflow was.
