Constrained AI: turn requirements into executable checks
A requirement such as staying within a permitted area should have an explicit test. Describing it in a prompt is not enough to tell an operator whether the final output satisfies it.
G-ATAI analysis
Begin by separating hard requirements from preferences. A plan might need to respect access permissions and a fixed budget while also trying to reduce delay. Put the hard requirements into an independent validator with clear pass or fail outcomes. Keep the checks close to the action boundary so a later transformation cannot invalidate an earlier approval unnoticed.
We recommend testing impossible requests and contradictory conditions as well as successful examples. When no valid solution exists, the application should explain which requirement prevents progress and return control to the owner. Track violations separately from quality scores. Good average performance cannot compensate for crossing a defined boundary. Use a small, reversible pilot to verify the validator, fallback and audit trail before connecting the model to consequential actions.
Questions before deployment
- Which requirements must never be traded for a better score?
- Can a separate validator check the final action?
- Does an impossible request stop safely and explain why?
Independent commentary inspired by MIT News. No affiliation or endorsement is implied.
