Surfaced during the v0.1.0 review (PR #2). Filing separately for spec clarity work.
§6 mandates DEFER as one of the five dispositions every conformant Guardian and Observed Agent supports. defer-details.json enumerates resolution_method: ["additional_context", "human_approval", "timeout"] and includes required_context: string[]. The spec doesn't tell the Observed Agent what to actually do with a DEFER response:
- Is there a follow-up wire method ("provide additional context", "poll for resolution")?
- Is there a
deferred_request_id linkage so resolution correlates back to the original request?
- Should the Observed Agent block the in-flight action, retry, or fail open while waiting?
- What does
timeout_decision: "ask" mean for a client that declared no ASK capability?
Two reasonable readings exist:
Terminal DEFER: the response is final. The agent waits resolution_timeout_ms, then enforces timeout_decision. Under this reading, required_context is informational only and resolution_method: "additional_context" is dead surface.
Two-phase DEFER: the agent sends a follow-up request providing the context. The Guardian re-evaluates and returns a non-DEFER decision. This needs a defined wire method, a deferred_request_id linkage, and a correlation rule.
I lean two-phase because required_context only makes sense if the agent is expected to send something back. Either way, the spec should pick one explicitly. Two conformant implementations of ACS-Core will not interoperate on any deferred decision until this is nailed down.
Why deferred from v0.1.0: real ambiguity but defensible as "spec should be clearer," not "implementation is impossible." Could be folded into a single follow-up PR with the other disposition-semantics tightening from the PR #2 review.
References: specification.md §6, defer-details.json, ask-details.json
Surfaced during the v0.1.0 review (PR #2). Filing separately for spec clarity work.
§6 mandates DEFER as one of the five dispositions every conformant Guardian and Observed Agent supports.
defer-details.jsonenumeratesresolution_method: ["additional_context", "human_approval", "timeout"]and includesrequired_context: string[]. The spec doesn't tell the Observed Agent what to actually do with a DEFER response:deferred_request_idlinkage so resolution correlates back to the original request?timeout_decision: "ask"mean for a client that declared no ASK capability?Two reasonable readings exist:
Terminal DEFER: the response is final. The agent waits
resolution_timeout_ms, then enforcestimeout_decision. Under this reading,required_contextis informational only andresolution_method: "additional_context"is dead surface.Two-phase DEFER: the agent sends a follow-up request providing the context. The Guardian re-evaluates and returns a non-DEFER decision. This needs a defined wire method, a
deferred_request_idlinkage, and a correlation rule.I lean two-phase because
required_contextonly makes sense if the agent is expected to send something back. Either way, the spec should pick one explicitly. Two conformant implementations of ACS-Core will not interoperate on any deferred decision until this is nailed down.Why deferred from v0.1.0: real ambiguity but defensible as "spec should be clearer," not "implementation is impossible." Could be folded into a single follow-up PR with the other disposition-semantics tightening from the PR #2 review.
References:
specification.md§6,defer-details.json,ask-details.json