How to develop and assess constraint identification in AI-enabled work

Separate real limits from preferences and assumptions

NASA's Systems Engineering Handbook treats constraints as part of requirements, calls for traceability to higher-level needs and scope, and advises documenting design constraints created as decisions evolve. The UK Government Functional Standard for Project Delivery sets expectations for governance, planning, control, and solution delivery across projects and programmes. These principles make constraints operational: a limit needs a source, an affected decision, and a way to verify compliance.

A constraint is not the same as an assumption. A constraint says what the work must or must not do within the current task. An assumption states something treated as true despite uncertainty. A preference can be negotiated. A dependency describes something the work relies on. Misclassification matters because it can make a flexible choice look fixed or a mandatory rule look optional.

Use the LIMIT constraint record

Create one LIMIT row for each condition that could invalidate the work:

| Field | Question | Evidence to retain | | --- | --- | --- | | Label | What precise condition restricts the work? | Testable statement using must, must not, no later than, or only if | | Issuer | Who or what has authority to impose it? | Policy, contract, brief, system rule, or accountable owner | | Mechanism | Which design, calculation, data use, sequence, or output does it change? | Affected task step and artifact | | Impact | What happens if it is breached or cannot be met? | Invalid output, rework, exposure, delay, or escalation | | Test | How will compliance be checked, and who can approve an exception? | Verification step, owner, time, and evidence |

Add a type such as scope, time, cost, data, technical, legal-policy, format, accessibility, approval, or capacity. Then mark the status as confirmed, interpreted, conflicting, superseded, or unresolved. The type supports scanning; the fields make the limit actionable.

AI can extract possible constraints from a brief and challenge a plan against them. The worker must open the source, resolve conflicts, and distinguish binding language from illustrative or outdated text. A model's summary is not the authority for a constraint.

Worked example: a synthetic supplier-options note

Consider a synthetic team preparing an options note for a small software service. The evidence pack includes a procurement brief, security guidance, a budget spreadsheet, an implementation calendar, and an email requesting a preferred supplier. This example is invented and does not describe Two Prune or a live procurement.

The initial AI-generated plan recommends a feature-rich option and says implementation can begin next month. The participant builds LIMIT rows and finds six conditions:

The email's request for one preferred supplier is recorded as an output request, not authority to bypass the required three-option comparison. A line in an old slide deck about a two-week migration is recorded as an assumption because no current plan supports it.

The chosen option fits the budget but cannot confirm identity-provider support from the available evidence. Instead of describing it as compliant, the participant marks the technical constraint unresolved, identifies the vendor evidence required, and makes the recommendation conditional. The note also shows that missing the approval date would compress the transition window. The result links each limitation to the option analysis and next check.

• the total first-year cost must remain within the approved budget;
• production data must stay in an approved region;
• the service must support the organization's identity provider before launch;
• contract signature requires procurement and security approval;
• the legacy contract ends on a stated date, creating a transition deadline;
• the final note must compare three viable options using the criteria in the brief.

Practice with a conflict-and-change drill

Give a learner a brief containing constraints in several locations and formats. Include one conflict, one preference phrased as if mandatory, one outdated restriction, and one dependency that becomes a constraint only if a chosen option is selected. Ask for a plan and LIMIT register.

After the first plan, change one condition, such as the deadline, available data, or approval threshold. The learner should identify which tasks, options, evidence requests, and recommendations need revision. This tests traceability rather than simple extraction.

A strong practice cycle includes:

• scanning the objective, evidence pack, policies, messages, data definitions, and delivery environment;
• rewriting vague limits as checkable statements;
• naming authority and resolving conflicts before treating a condition as binding;
• tracing each constraint to the choices and outputs it affects;
• designing a compliance check or escalation path;
• maintaining change history when constraints are clarified or superseded.

Assess whether constraints control the work

Use a realistic simulation where no single document contains every condition. Ask the participant to produce a decision artifact under time pressure and retain the LIMIT register, questions, source locations, AI interactions available within the assessment, and revisions.

Score observable evidence such as:

Counting rows is not a useful score by itself. A long list of harmless formatting preferences can coexist with a missed data boundary. Likewise, naming a deadline without changing sequencing or escalation does not show that the constraint controlled the work.

• material constraints are found across the whole evidence environment;
• constraints, assumptions, preferences, dependencies, and acceptance criteria are distinguished;
• every binding condition has a credible authority and source location;
• the participant traces constraints to affected options and work steps;
• conflicts and missing evidence are escalated rather than silently resolved;
• verification checks are performed before delivery;
• new information leads to targeted changes in the plan and artifact.

Verify through a bidirectional trace

Run the trace in two directions. From each constraint, locate the plan step, option, claim, or deliverable element it changes. Then move from each consequential decision in the artifact back to the constraints that shaped it. An unconnected LIMIT row is probably not operational. A decision with no constraint trace may rest on an overlooked condition.

Test compliance using the stated method, not a final visual scan alone. Recalculate cost limits, inspect data-handling evidence, verify approvals, and compare output structure with the brief. Where an exception is needed, record the authorized decision and its scope rather than deleting the original limit.

Constraint identification is task-dependent and does not by itself establish sound judgment. A participant may find every stated limit and still choose a weak option. In a Two Prune assessment, the register, source navigation, plan changes, and final checks can contribute bounded evidence about Context Framing, Evidence Navigation, Verification & Risk Control, and Judgment & Synthesis. They do not prove future outcomes or determine suitability for employment.

Sources

NASA Systems Engineering Handbook

• UK Government Functional Standard GovS 002: Project Delivery

Sources: [1] [2]