Feasibility-Negotiated Intent Contract

Problem

An ordinary tool call has two outcomes, success or error, and the caller learns which one applies only by making the call. Applied to a declarative goal against a constrained plant, that shape is unsafe. A goal that the plant cannot honour is discovered during actuation, after configuration has already been written and other traffic has already been disturbed, and the error that comes back says an action failed without saying which expectation was unreachable or by how much. The caller cannot replan from that, because a bare failure carries no information about what would have been achievable. Translating stated goals straight into configuration through heuristics produces exactly this: unpredictable behaviour on a live plant with no stable notion of what counts as a safe request.

Solution

Split the exchange into a proposal and a contract. The caller submits a goal as a set of expectations, each with a target, an object it applies to, and the context in which it holds; nothing about how to reach it. The handler does not actuate on receipt. It first runs a deterministic audit of the whole expectation set against a model of the controlled system — live resource state, physical limits, standing commitments already accepted for other callers — and decides whether every expectation can hold at once. That audit has three outcomes, not two. If the set is satisfiable, the handler accepts and the expectations become the contract it is now measured against. If the set is unsatisfiable but a nearby set is not, the handler returns a counter-offer: the same goal with one expectation relaxed, naming which one and quoting the shortfall as a number, so the caller can accept the degraded contract or restate the goal. If no relaxation inside the caller's stated bounds is reachable, the handler refuses and names the binding constraint rather than returning a generic failure. Only an accepted contract reaches the actuator. After actuation the handler keeps measuring delivered values against the accepted targets and reopens the negotiation when the contract degrades, which keeps the audit honest as the resource situation moves. The model may propose any goal at all, because the component that decides achievability is not the component that wrote the goal.

When to use

• The caller states an outcome with measurable targets rather than a sequence of steps, and the handler controls a system with hard capacity or physical limits.
• Actuating an unreachable goal is expensive or damaging, so infeasibility must be found before configuration is written rather than during it.
• A partly satisfied goal is genuinely useful to the caller, so a named relaxation is worth more than a failure.
• Goals from several callers compete for the same finite resources and have to be reconciled against commitments already accepted.
• A natural-language front end proposes goals, and actuation must stay deterministic regardless of how confident that front end is.