[EAAPL-WRK015] Iterative Constraint Satisfaction

Category: Agentic Workflows Sub-category: Constraint Enforcement Architecture Version: 1.0 Maturity: Proven Tags: constraint-satisfaction, schema-validation, hard-constraints, regulatory-constraints, safety-rules, iterative-refinement Regulatory Relevance: EU AI Act Art. 15, APRA CPS 234, ISO 42001 §8.4

1. Executive Summary

The Iterative Constraint Satisfaction Pattern defines an architecture in which an agent iteratively refines its output until it satisfies a defined set of HARD constraints — binary pass/fail rules such as schema compliance, regulatory requirements, safety rules, and structural requirements — rather than quality criteria. This pattern is fundamentally different from the Reflexive Agent (EAAPL-AGT006), which evaluates qualitative output quality through a critic LLM; Iterative Constraint Satisfaction evaluates objective, mechanically-verifiable constraints through a deterministic constraint checker. The agent refines output until all constraints pass or the maximum iteration limit is reached.

For CIO/CTO audiences: quality evaluation asks "how good is this output?" — a subjective question answered by an AI reviewer. Constraint satisfaction asks "does this output comply with these mandatory rules?" — an objective question answered by deterministic code. For regulated outputs — financial disclosures that must not exceed a risk threshold, contracts that must contain mandatory clauses, communications that must not reference competitor prices — the question is not "is this good enough?" but "does it comply?" This pattern enforces compliance mechanically, not subjectively. The constraint checker does not have opinions; it evaluates rules. An output either passes all constraints or it doesn't, and if it doesn't, the agent must revise until it does.

2. Problem Statement

Business Problem

Regulated and safety-critical outputs must meet hard requirements that are not matters of quality but of compliance: a financial product disclosure statement must contain specific mandatory disclosures; a clinical summary must not recommend contraindicated medications; a generated contract must include specific clauses required by law. These requirements cannot be enforced through qualitative review — they require deterministic, rule-based checking.

Technical Problem

LLMs do not reliably self-enforce hard constraints. A model instructed to "include mandatory disclosure X" may omit it, include a paraphrase that technically satisfies the spirit but not the letter of the requirement, or include it in one section but contradict it in another. Soft quality review (Reflexive Agent) may not detect these failures because the model critic has the same systematic omissions as the generator.

Symptoms of Absence

• Generated outputs occasionally omit mandatory content that is required for regulatory compliance
• No systematic checking that generated outputs satisfy structural requirements (schema, word count, required sections)
• Compliance review identifies the same categories of missing requirements repeatedly, suggesting they are not being enforced at generation time
• Each output requires manual compliance review because there is no automated constraint gate

Cost of Inaction

• Regulatory Risk: Outputs with missing mandatory disclosures or non-compliant content create regulatory liability
• Manual Review Cost: Every output requires compliance review because there is no automated constraint gate
• Incident Cost: Discovering constraint violations post-delivery is more costly than preventing them at generation time

3. Context

When to Apply

• Output must satisfy binary (pass/fail) hard constraints that can be expressed as mechanical rules
• Constraints are stable, articulable, and can be implemented as deterministic code or structured queries
• Non-compliance with a constraint makes the output categorically unacceptable regardless of quality
• The organisation has a compliance obligation to demonstrate that outputs meet defined standards

When NOT to Apply

• Requirements are qualitative and subjective (use Reflexive Agent, EAAPL-AGT006)
• Constraints cannot be mechanically verified (require expert judgment)
• Constraints are so numerous or complex that the constraint checker becomes unmaintainable
• Output generation cannot feasibly satisfy all constraints even with iterative refinement (architectural issue)

Prerequisites

• Defined constraint set (each constraint: name, rule, machine-verifiable check)
• Constraint checker implementation (deterministic code, not LLM-based)
• Revision prompt that provides specific constraint failure context
• Maximum iteration limit and behaviour on exhaustion

Industry Applicability

4. Architecture Overview

The Iterative Constraint Satisfaction architecture separates the generation of output from the deterministic checking of constraints and the targeted revision of non-compliant content.

Constraint Set Definition The constraint set is a machine-readable specification of all hard requirements. Each constraint has: (a) a unique identifier (e.g., "DISC-001"), (b) a human-readable description, (c) a machine-checkable rule implementation (regex, XPath, schema validation, keyword presence, numerical threshold, structural check), (d) the constraint category (schema, regulatory, safety, structural), (e) the severity (blocking vs. warning), and (f) a remediation hint used in the revision prompt. The constraint set is owned by compliance/domain SMEs and version-controlled.

Initial Generation The agent generates the initial output using its standard generation workflow (sequential chain, ReAct loop, or direct generation). The initial generation is not constrained to satisfy all requirements — it focuses on producing a high-quality draft. Constraint satisfaction is a post-generation refinement phase.

Constraint Checker The Constraint Checker evaluates the generated output against every constraint in the constraint set. The checker is implemented as deterministic code — it does not use an LLM. Each constraint check is independent and produces a binary result (PASS/FAIL) and, for failures, a specific failure message identifying the exact nature of the violation. The checker produces a structured report: {constraints_total: N, passed: K, failed: N-K, failures: [{constraint_id, description, failure_detail}]}.

Targeted Revision When the constraint checker reports failures, the Revision Engine is invoked with: the current output, the full constraint failure report, and a revision prompt that instructs the agent to address each specific failure without introducing new violations. The revision prompt is targeted: "Revise the following draft to address these specific constraint violations: [failure list]. Do not change content that has already passed constraints. For each violation, explain the change you made."

Iteration Until Compliance or Max Iterations After revision, the Constraint Checker is re-applied to the revised output. If all constraints pass, the output is accepted. If failures remain, another revision cycle is triggered. The maximum iteration count is enforced; if maximum iterations are reached without full compliance, the output is escalated to human review (never silently delivered as compliant).

Difference from Reflexive Agent The Reflexive Agent (EAAPL-AGT006) uses an LLM critic to evaluate qualitative output quality. The Iterative Constraint Satisfaction pattern uses deterministic code to check objective compliance requirements. Both use an iterative refinement loop, but the quality criterion, the checker, and the failure mode (quality score vs. constraint pass/fail) are fundamentally different. They are complementary, not alternatives: a high-quality output (Reflexive Agent) that fails hard constraints (Constraint Satisfaction) is still non-deliverable.

5. Architecture Diagram

6. Components

7. Data Flow

Error Flow

8. Security Considerations

Constraint Checker as Tamper-Proof Gate

• The constraint checker must not be modifiable by the LLM generation or revision steps
• Mitigation: Constraint checker is implemented as separate code, not injected into the LLM context; LLM cannot modify the rules; constraint set changes require authorised deployment

OWASP LLM Top 10

9. Governance Considerations

Constraint Set Ownership

• Each constraint in the constraint set must have a named business owner responsible for its accuracy, currency, and relevance
• Constraint additions and removals are change-controlled events requiring compliance review and regression testing
• The constraint set is as important a governance artefact as the output schema

Governance Artefacts

10. Operational Considerations

SLOs

11. Cost Considerations

Constraint Checker Cost

• Deterministic constraint checking is negligible vs. LLM inference cost
• The primary cost is revision LLM inference; minimise by: (a) improving initial generation to pass more constraints on first attempt, (b) identifying the most commonly violated constraints and strengthening the generation prompt for those specifically

12. Trade-Off Analysis

13. Failure Modes

14. Regulatory Considerations

EU AI Act

• Art. 15 (Accuracy and Robustness): For high-risk AI systems producing regulated outputs, the constraint satisfaction pattern directly implements the requirement for accuracy and robustness by ensuring outputs meet mandatory requirements before delivery.

APRA CPS 234

• For financial services organisations, generated outputs that interact with customer information assets must pass information security constraints (no PII leakage, no cross-customer data mixing) enforced by the constraint checker.

ISO 42001

• §8.4: The constraint set is an operational specification for the AI system; it must be version-controlled, tested, and managed as a change-controlled artefact.

Australian Context

• ASIC RG 263 (Digital financial product advice): Automated generation of financial product disclosures is subject to content requirements; the constraint satisfaction pattern is the appropriate architectural mechanism for enforcing these requirements at generation time.
• Privacy Act 1988 (APP 3, 6): For generated communications referencing personal information, constraints enforcing appropriate purpose limitation and disclosure minimisation can be mechanically checked.

15. Reference Implementations

AWS

Azure

On-Premises

16. Related Patterns

17. Maturity Assessment

Overall Maturity: Proven

18. Revision History