PaperlayerView exact revision on arXiv

Source-linked AI summary

Constraint-Driven Context Engineering: Designing Domain Interfaces for AI Systems

Xiwei Xu, Chen Wang, Mengmeng Yang, Yipeng Zhang, Jacky Jiang, Suyu Ma, Youyang Qu, Ming Ding, Liming Zhu

arXiv:2609.27354v1cs.SEcs.AI

TL;DR

Domain-specific AI systems need context that addresses constraints as well as domain knowledge, but existing context engineering offers limited support for systematically identifying and operationalising those constraints. CDCE treats constraints as design drivers and examines the approach across three domains, where cases demonstrate distinct ways constraints shape domain interfaces.

  • Problem

    Existing context engineering focuses on supplying domain knowledge, while domain constraints are not systematically identified and operationalised; context quality, scope, and structure can limit domain-specific AI solutions.

    Source: §1 · p. 1, §5.1 · p. 9

  • Method

    CDCE identifies and characterises domain constraints, determines required context assets, and designs representations that make those assets available to AI systems.

    Source: §10 · p. 19

  • Results

    The three cases demonstrate progressive context enrichment in educational assessment, explicit boundaries and verification in healthcare decision support, and context reconstruction and dynamic constraint refinement in financial-distress prediction.

    Source: §10 · p. 19

  • Takeaways & Limitations

    Across the cases, constraints shape domain interfaces in distinct ways, including guiding behaviour, enforcing boundaries, and supporting verification of AI-generated outcomes.

    Source: §10 · p. 19

    In the constraint-identification case, decisions provide evidence of judgement applied in practice but do not necessarily constitute internally consistent ground truth.

    Source: §8.1 · p. 16

Abstract

from arXiv · show

Generative AI systems are increasingly deployed to address domain problems. These systems operate under technical, regulatory, institutional, and normative constraints that define acceptable AI behaviour and outcomes within their domains. We observe a recurring pattern in our industry engagement: partners often arrive with a functioning but relatively generic AI solution. The challenge is no longer to build an AI system from scratch, but to improve the quality and domain appropriateness of an AI-generated solution. In these settings, the limiting factor is often the quality, scope, and structure of the context available to the system. Yet, existing context engineering approaches primarily focus on supplying domain knowledge through retrieval, memory, and tools, with limited support for systematically identifying and operationalising the constraints that govern AI systems in their operational environments. This paper proposes Constraint-Driven Context Engineering (CDCE), a design approach for engineering domain interfaces for AI systems. Drawing on software architecture design and Domain-Driven Design (DDD), CDCE treats domain constraints as first-class design drivers. It identifies and characterises constraints, determines the required context assets, and designs representations through which these assets are made available to AI systems. We conducted a comparative multiple-case study with industry and public-sector partners across educational assessment, healthcare decision support, and financial-distress prediction. Depending on their characteristics, constraints can guide AI behaviour, enforce permissible boundaries, or support verification of AI-generated outcomes. The cases demonstrate CDCE's applicability across contrasting domains and show how constraint characteristics shape the resulting domain interfaces.

1 Introduction

Domain-specific AI needs more than domain knowledge: constraints also shape acceptable behaviour and outcomes, but often are not directly accessible to AI systems. CDCE treats those constraints as design drivers for domain interfaces, and a comparative case study shows how they can be made explicit, structured, and available for different purposes.

1 Introduction

  • Domain knowledge alone is insufficient: constraints govern acceptable decisions, appropriate actions, and valid justifications, yet may be fragmented or implicit and require operationalisation.Source: §1 · pp. 1–2
  • The domain interface structures explicit constraints, externalises implicit ones, and makes them available to guide behaviour, enforce boundaries, and verify AI-generated outcomes.Source: §1 · p. 2
  • CDCE treats domain constraints as first-class architectural drivers for identifying required context, constructing or curating assets, and choosing their representations.Source: §1 · p. 2
  • The cases show how constraint-driven design can make relevant domain conditions explicit, structured, and available to AI systems for different purposes.The comparative study covered educational assessment, healthcare decision support, and financial-distress prediction.Source: §1 · p. 2

2 Related Work

Existing context engineering focuses on supplying and managing information for AI, while CDCE adds a constraint-driven design perspective. It connects domain understanding and architectural reasoning, and recognises human knowledge and professional practice as sources of implicit constraints to externalise.

2.1 Context Engineering for LLM Systems

  • Context engineering covers retrieval, generation, processing, and management, while CDCE makes constraints drivers of what context is identified, structured, represented, and operationalised.Source: §2.1 · p. 2

2.2 Domain-Driven and Architecture-Driven Design

  • CDCE connects DDD's identification and modelling of meaningful domain constraints with ADD's translation of those drivers into context assets and representations.Figure 1 presents DDD as the means to understand the domain and its boundaries, and ADD as the source of architectural drivers for AI tasks.Source: §2.2 · p. 3, Figure 1 · p. 3

2.3 Human Knowledge and Human-in-the-Loop

  • CDCE seeks to externalise implicit constraints from human knowledge and professional practice, which may contain constraints not yet articulated for AI systems.Source: §2.3 · p. 4

3 Constraints

CDCE treats domain constraints as design drivers, characterising them to shape how AI behaviour and outcomes are guided, bounded, or evaluated. It distinguishes constraint types and incorporates them into context-management processes.

3 Constraints

  • Constraints are environmental signals that guide, restrict, or evaluate AI-system behaviour and outcomes within a domain.Source: §3 · p. 4

3.1 Characterisation of Constraints

  • Constraints are characterised by explicitness, temporality, and binding strength, which inform how they are identified and treated in context engineering.Explicitness distinguishes articulated from tacit constraints; temporality distinguishes predefined from dynamic constraints; binding strength distinguishes mandatory from flexible guidance.Source: §3.1 · pp. 4–5

3.2 Types of Constraints

  • Technical, regulatory, institutional, and normative constraints are complementary design categories, not a fixed or exhaustive taxonomy.Source: §3.2 · p. 5
  • Technical limits such as finite context windows can drive selective retrieval, prioritisation, summarisation, or incremental context loading.Source: §3.2 · p. 5
  • Regulatory and institutional constraints differ: regulations specify what an organisation must comply with, while institutional constraints shape how work is performed there.Source: §3.2 · p. 5

3.3 Incorporating Constraints into Context Management Harnesses

  • The harness formulation is implementation-agnostic, allowing constraints to be realised through different component compositions.Source: §3.3 · p. 6
  • Human review can expose unmodelled inconsistencies, prompting refined institutional constraints and reruns of the same input.Source: §3.3 · p. 6
  • Context admission and AutoVerify check agent outputs against known constraints, while HumanCheck updates institutional constraints when inconsistencies emerge.Source: §3.3 · p. 6

4 Constraint-Driven Context Engineering (CDCE)

CDCE transforms operational-environment information into machine-accessible context by identifying task-relevant constraints and assets, then designing suitable representations. Its domain interface is the engineered boundary between an AI system and its environment.

4 Constraint-Driven Context Engineering (CDCE)

  • CDCE identifies operational constraints, relevant context assets, and suitable representations to produce a domain interface for domain-specific AI tasks.The AI remains responsible for its task and responses; CDCE governs the quality, scope, and structure of its domain context.Source: §4 · pp. 7–8

4.1 Constraint Identification

  • Shared domain language and bounded contexts help establish consistent terminology and delimit the scope of constraint identification.Source: §4.1 · p. 8
  • Constraint identification is task-oriented: it finds conditions that guide, restrict, or evaluate behaviour, rather than modelling the entire environment.Constraints may be drawn from artefacts or elicited from experts; the result is a task-specific constraint set.Source: §4.1 · p. 8

4.2 Context Asset Identification

  • Context assets are information artefacts needed to represent or operationalise constraints, and multiple assets may support one constraint or vice versa.The assets and constraints together form a domain sub-model for AI tasks in the operational environment.Source: §4.2 · p. 8

4.3 Context Representation

  • CDCE adapts Architecture Design Decisions by treating the AI task as a functional requirement, context qualities as quality attributes, and technical limits as design constraints.Source: §4.3 · p. 9
  • Representation choices account for task use, desired context qualities, technical constraints, and asset characteristics.Relevant qualities include explainability, traceability, consistency, and timeliness; technical constraints include context-window limits, latency, and cost.Source: §4.3 · p. 9
  • The asset-to-representation mapping is many-to-many: one asset may use complementary forms, and one structure may integrate multiple assets.Separating assets from representations lets representation technologies evolve independently of the underlying assets.Source: §4.3 · p. 9

5 Comparative Multiple-Case Study Methodology

The comparative multiple-case study examines CDCE in real-world systems across contrasting domains and tasks. A shared protocol supports cross-case comparison while retaining each case’s particular context.

5 Comparative Multiple-Case Study Methodology

  • The study examines domain-interface construction between AI systems and operational environments through a comparative multiple-case design.Source: §5 · p. 9

5.1 Case Selection

  • Cases span educational assessment, healthcare decision support, and financial-distress prediction with Australian industry and public-sector partners.Source: §5.1 · p. 9
  • Partners had functioning but generic AI solutions, with projects focused on improving solution quality and domain appropriateness rather than building systems from scratch.The limiting factor was often context quality, scope, and structure rather than underlying model capability.Source: §5.1 · p. 9

5.2 Case-Study Protocol and Analytical Focus

  • A common protocol analyses each case through constraint identification, context-asset identification, and representation design, then records its distinctive observation.This structure supports comparison while preserving domain, task, and partner differences; context engineering remains iterative and case-specific.Source: §5.2 · p. 10

6 Case Study I: Educational Assessment

The educational-assessment case applies CDCE to an LLM-based marking and feedback pipeline for exam preparation. It shows how assessment constraints and progressively constructed context assets shape marking and feedback.

6.1 Constraint Identification

  • Curriculum requirements are relatively firm, while professional judgement can be softer and allow legitimate variation in interpreting student responses.Judgement may be implicit in expectations about sufficient evidence, misconceptions, and partial credit, or codified in authorised materials and moderation practices.Source: §6.1 · p. 11
  • The marking pipeline operationalises curriculum and assessment constraints through contextual guidance and verification, rather than relying on a single prompt.Source: §6.1 · p. 11

6.2 Context Asset Identification

  • Assessment context assets include curriculum and marking materials, question metadata, syllabus mappings, verification results, and artefacts of intermediate assessment.Source: §6.2 · p. 11
  • The pipeline uses authorised curriculum materials, directive-verb definitions, and performance descriptors to construct marking criteria, then uses assessment principles to verify them.These assets also form the educational-assessment domain sub-model and provide contextual guidance as well as verification.Source: §6.2 · p. 12

6.3 Context Representation Design

  • The case represents documents, vector-indexed materials, structured data and objects, key-value runtime state, and semi-structured provenance logs.Source: §6.3 · p. 12

6.4 Observation: Progressive Context Enrichment

  • The marking context is progressively constructed from a question through syllabus outcomes, concepts, skills, directive verbs, and cognitive demand to criteria, response evaluation, and feedback.Each stage creates assets that become inputs to later reasoning stages.Source: §6.4 · p. 12
  • Progressive enrichment turns raw educational resources into an increasingly structured domain interface between the AI system and its operational environment.Source: §6.4 · p. 12

7 Case Study II: Healthcare Decision Support

The healthcare case examines context needs for MDT chronic-disease planning, where patient history must be retrieved accurately and referenced, and care plans grounded in evidence and medical guidelines.

7.1 Constraint Identification

  • Context retrieval must find relevant paragraphs in an expanding corpus, extract information, and connect it with other evidence; guideline compliance requires high-recall retrieval and links to applicable rules.Source: §7.1 · p. 13
  • Each treatment-plan item must connect patient-history evidence to its reasoning, while context management must accommodate longitudinal record growth and include important patient evidence.Source: §7.1 · p. 13

7.2 Context Asset Identification

  • Applicable Australian clinical guidelines can impose hard requirements, while other guidelines, handbooks, and medical literature generally offer soft guidance balanced against patient-specific considerations.Source: §7.2 · p. 13
  • The system uses clinician-confirmed care plans as ground truth for generation and an independent evaluator to assess reasoning correctness and coverage.The agent also generates fine-grained decision provenance.Source: §7.2 · p. 14

7.3 Context Representation Design

  • Care-plan representations link medical rules to decisions and plan items, with each item declaring support status and whether it relies on patient-record evidence alone or also guideline rules.Source: §7.3 · p. 14

7.4 Observations: Skill Acquisition and Robust Care Plan Generation

  • The verification-oriented design surfaced a patient-record inconsistency: a bowel cancer screening result was pending despite the patient being outside the kit’s age range, and a clinician confirmed the discrepancy.The design can also raise clinicians’ awareness of potential problems.Source: §7.4 · p. 15
  • The agent personalized care plans by retrieving knowledge from broader handbooks, including vegetable-preparation advice to further reduce potassium, in line with dietitian advice.Source: §7.4 · p. 15

8 Case Study III: Financial Distress Prediction

The Risk IQ case examines how CDCE translates regulatory, organisational, professional-judgement, and longitudinal-data constraints into AI-usable context for financial-distress prediction, with auditor review helping clarify assessment criteria. It also considers how human review and disagreement can refine normative constraints and allow the domain interface to evolve with professional understanding and organisational practices.

8.1 Constraint Identification

  • Assessment was constrained by reporting and auditing requirements, organisational processes, auditor judgement, and longitudinal data, with explicit criteria alongside implicit judgement about signal combinations and risk types.Historical decisions showed how judgement had been applied but did not necessarily provide internally consistent ground truth.Source: §8.1 · p. 16

8.2 Context Asset Identification

  • Regulatory and institutional context assets included audit reports, benchmarks, historical assessments, dashboard data, assessment categories, and calculation procedures that captured organisational practice.These assets linked reported financial measures to their underlying data.Source: §8.2 · p. 16
  • Historical assessments captured auditor judgement about interpreting financial signals, including operating losses, available cash, and small or declining populations.The initial prediction model exposed inconsistencies in how criteria were applied across councils and years.Source: §8.2 · p. 16
  • Year-prefixed, sparse indicators with varying temporal persistence required context to account for both the indicator and its historical lag.The data structure also created a need for temporal alignment, feature selection, provenance preservation, and reuse across prediction years.Source: §8.2 · p. 16

8.3 Context Representation Design

  • Risk IQ represented observations as relative lags (n-3, n-2, n-1) and used lag-aware causal discovery to select upstream covariates while excluding future-year information and label columns.This reduced the broad feature set to task-specific contextual information and helped prevent target leakage.Source: §8.3 · p. 17
  • Financial distress context combined heterogeneous documents, data, computation structures, rules, human feedback, and model artefacts; domain-literature factors were mapped to local-government features and combined with discovered covariates.The representations transformed raw observations into aligned feature families, formulas into explicit computations, assessments into judgement signals, and literature factors into mapped domain knowledge.Source: §8.3 · p. 17

8.4 Observation: Human-AI Co-Evolution of Constraints

  • Auditor review of the first modelling iteration exposed inconsistent criteria, clarified cash-liquidity versus longer-term sustainability risk, and improved the second iteration’s alignment with auditor judgement.Review led to revised criteria and additional contextual data, giving the second iteration a richer, more clearly defined set of environmental signals.Source: §8.4 · pp. 17–18
  • AI interaction can reveal ambiguities or inconsistencies in human practices, so normative constraints need not remain static rules encoded before deployment.Constraints articulated through model development and human review can become explicit, predefined constraints for subsequent iterations.Source: §8.4 · p. 18
  • Capturing human overrides, revised criteria, additional evidence, and reasons for disagreement lets the domain interface evolve with professional understanding and organisational practices.As professional understanding and organisational practices are refined, dynamically refined constraints can become explicit for subsequent iterations.Source: §8.4 · p. 18

9 Discussion

The three cases show CDCE following a shared design approach while producing domain-specific interfaces. The discussion explains how those interfaces are constructed, how constraints operate, and how both context and constraints evolve.

9.1 Domain Interface Construction

  • Educational assessment enriches curriculum resources into task-specific assessment context, healthcare composes patient evidence and medical knowledge into care-plan relationships, and financial distress prediction reconstructs context from heterogeneous sources.Source: §9.1 · p. 18
  • Depending on the domain and task, context may need to be retrieved, constructed, composed, or reconstructed into a domain interface for AI use.Source: §9.1 · p. 18

9.2 Constraints as Guidance, Enforcement, and Verification

  • A constraint may guide generation, be enforced, or support independent verification; these roles can complement one another, with enforcement depending on binding strength and violation consequences.Source: §9.2 · p. 18
  • Curriculum requirements and clinical guidelines guide reasoning, while generated assessment criteria, care-plan items, and model outcomes can be checked against domain criteria and evidence.Source: §9.2 · p. 18

9.3 Evolving Domain Interfaces

  • The cases differ in what changes: assessment constraints stay stable as task context is built, healthcare patient evidence and care plans evolve, and Risk IQ criteria are revised after auditor review.Source: §9.3 · p. 19
  • Operational environments may produce new context under stable constraints, while interaction with experts may expose ambiguities requiring constraint refinement; interface design must support both forms of change.Source: §9.3 · p. 19

10 Conclusion

The conclusion presents CDCE as a way to engineer domain interfaces by treating constraints as design drivers. Its three cases show distinct ways those interfaces address domain requirements.

10 Conclusion

  • CDCE treats technical, regulatory, institutional, and normative constraints as first-class design drivers, then identifies and characterises them to determine context assets and representations.Source: §10 · p. 19
  • The engineered elements form domain interfaces through which constraints guide AI behaviour or inform complementary enforcement and verification; context engineering constructs and maintains these interfaces.Source: §10 · p. 19
  • Across the cases, constraint-driven context engineering takes distinct forms: progressive enrichment in educational assessment, boundaries and verification in healthcare, and reconstruction with dynamic refinement in financial-distress prediction.Source: §10 · p. 19
Loading 2609.27354v1…