How do you give Super Intelligence useful constraints? You define the boundaries the system must respect while completing the task: source limits, length, audience, deadlines, prohibited actions, required facts, privacy boundaries, tool permissions and conditions that should cause the workflow to stop rather than guess.
Constraints matter because a capable AI system can still optimise the wrong objective. A rewrite may become clearer while changing a deadline. A research answer may become complete-looking by inventing a missing value. A tool-connected workflow may perform an action that the user only wanted drafted. Constraints turn these hidden assumptions into visible rules.
This eduKateSG guide explains how to design effective SI constraints, how to detect contradictions between them, how to scale constraints with risk and how to test whether the system actually obeys them. It follows How to Use Examples to Teach Super Intelligence What You Want in Stage 2 of the How to Learn Super Intelligence Quickly curriculum.
Terminology: SI is our editorial term for practical contemporary AI learning. Constraints guide the task; they do not guarantee perfect compliance or eliminate the need for verification.
The First Principle: A Constraint Protects Something That Matters
A good constraint exists because a failure would change the meaning, usefulness or safety of the result. “Keep the deadline unchanged” protects a commitment. “Use only the supplied source” protects evidence fidelity. “Do not send the message” protects the action boundary.
A weak constraint is decorative. “Be amazing”, “be super intelligent” or “never make mistakes” expresses a preference without specifying observable behaviour. Replace vague restrictions with rules that can be checked.
The strongest constraint therefore answers two questions: what must remain true, and how will we know whether the result respected it?
Constraint Type 1 — Source Constraints
Source constraints define what evidence the system may use. They are useful when the output must remain grounded in a specific notice, document, dataset or set of approved sources.
Example: “Use only the attached policy for eligibility criteria. If the policy does not state an answer, write ‘not specified’ rather than using general knowledge.”
This constraint prevents plausible background knowledge from being blended into source-grounded work. It is especially important in research, summarisation and policy interpretation.
Constraint Type 2 — Preservation Constraints
Preservation constraints identify information that may not change during transformation. Dates, owners, quantities, legal wording, obligations and uncertainty often belong in this category.
Example: “Rewrite for a parent audience, but preserve the examination date, arrival time and required materials exactly. Do not strengthen or weaken any obligation.”
The user should extract protected details before generation and compare them afterward. The constraint becomes operational because the check is visible.
Constraint Type 3 — Length Constraints
Length constraints control output size: word count, sentence count, slide count or number of bullet points. They are useful when the receiver has limited attention or the output must fit a specific format.
Length can conflict with completeness. If you require every detail from a long source in fifty words, the task may be impossible. State priority: “Keep the deadline and required actions even if optional background must be omitted.”
A good length constraint therefore includes an information-priority rule when compression matters.
Constraint Type 4 — Audience Constraints
Audience constraints define language level, assumed knowledge and communication purpose. “Write for a Secondary 1 student” is more useful when paired with what the student should be able to do after reading.
Example: “Explain this to a Secondary 1 student who knows basic fractions but has not learned algebraic fractions. Use one numerical example before symbols.”
Audience is not only tone. It changes vocabulary, prerequisite assumptions, examples and structure.
Constraint Type 5 — Format Constraints
Format constraints define the structure of the output: headings, fields, tables, JSON, checklist or another schema.
Example: “Return five fields: Decision, Owner, Deadline, Source and Status. Use Unknown for missing values.”
Format constraints make output easier to review and hand off. They do not guarantee that the values inside the structure are correct.
Constraint Type 6 — Action Constraints
Action constraints define what the system may prepare versus what it may actually execute. This is essential for tool-connected systems.
Example: “Draft the calendar event details. Do not create the event until I explicitly approve the draft.”
The difference between drafting and acting should be visible in both prompt and tool permissions. A textual instruction alone should not be the only control for high-consequence actions when stronger technical controls are available.
Constraint Type 7 — Permission Constraints
Permission constraints state what information or systems the workflow is allowed to access. A task may be possible technically but inappropriate operationally.
Example: “Use only the public project folder. Do not access personal email or private HR records.”
Use the minimum access required for the job. Narrow permissions reduce the number of things that can go wrong.
Constraint Type 8 — Privacy Constraints
Privacy constraints minimise unnecessary personal or confidential information. They can require anonymisation, role labels, redaction or synthetic data for practice.
Example: “Use student IDs rather than names in the analysis, and do not include medical or family information.”
Privacy should be designed before data is sent to the system, not added as a cosmetic instruction after the information has already been exposed.
Constraint Type 9 — Uncertainty Constraints
Uncertainty constraints tell the system what to do when information is incomplete or conflicting. These are among the most valuable constraints because they prevent false completeness.
Example: “If two sources disagree, list both values and stop. Do not choose one unless the source authority is clear.”
Another example: “If the denominator is missing, return ‘cannot calculate’ rather than estimating it.”
Constraint Type 10 — Tool Constraints
Tool constraints define when a tool should or should not be used. A current fact may require search. Exact arithmetic may require a calculator. A sensitive task may prohibit external connectors.
Example: “Use the official website for the current requirement. Do not answer from memory.”
Tool constraints are effective only when the tool is actually available. If the required tool is absent, the workflow should expose the limitation.
Constraint Type 11 — Time Constraints
Time constraints can refer to the period covered by the evidence, the deadline for the task or the duration of the plan.
Example: “Use sources published or updated in 2026 for the current-state section; older sources may be used only for historical background.”
A time constraint prevents historical evidence from being presented as current without explanation.
Constraint Type 12 — Quality Constraints
Quality constraints define acceptance conditions such as source traceability, calculation checks, test coverage or reading level.
Example: “Every numerical claim must include the formula or source value used. Every factual claim about current policy must be traceable to an official source.”
Avoid impossible guarantees such as “100% accurate”. Define the checks and standards that make quality observable.
Constraint Type 13 — Learning Constraints
In educational use, constraints can preserve cognitive work. “Give one hint, not the full solution” is a learning constraint.
Example: “Wait for my attempt before explaining the next step. After correction, give one fresh problem without a solution.”
The system may be capable of doing more, but the learning objective deliberately limits assistance.
Constraint Type 14 — Domain Constraints
Domain constraints define which rules, definitions or standards control the task. A mathematics problem may require a particular notation. A report may need to follow an organisational terminology set.
Example: “Use the definitions in the attached glossary. Do not substitute similar terminology from other frameworks.”
This prevents vocabulary drift across systems that use similar words differently.
The Constraint Stack
- Objective: what should be achieved.
- Source: what evidence may be used.
- Preservation: what must not change.
- Audience: who must understand it.
- Format: what shape the output takes.
- Uncertainty: what happens when information is missing or conflicting.
- Tool: what external capabilities may be used.
- Permission: what systems may be read or changed.
- Action: where preparation ends and execution begins.
- Quality: what checks define acceptance.
Not every task needs all ten layers. Use the smallest set that protects the actual failure modes.
Constraint Conflicts: When the Brief Is Impossible
Constraints can contradict one another. “Include every detail” and “write exactly twenty words” may be impossible. “Use only the source” and “fill in all missing background” point in opposite directions.
Before blaming the model, inspect the specification. Decide which constraint has priority. Factual fidelity often outranks style. Safety or policy boundaries often outrank convenience. Human approval may outrank speed.
If two high-priority constraints genuinely conflict, stop and redesign the task. A good workflow should expose impossibility rather than silently violate one rule.
Hard Constraints and Soft Preferences
Separate hard constraints from preferences. “Do not send” is a hard action boundary. “Prefer concise wording” is a soft style preference.
This distinction helps when trade-offs appear. If the output cannot be both fully detailed and extremely short, the soft preference can yield while the hard source-preservation rule remains.
You can label them explicitly: MUST, SHOULD and MAY. The notation is less important than the priority structure.
Positive Constraints and Negative Constraints
Negative constraints state what must not happen: “Do not invent a deadline.” Positive constraints state the desired alternative: “If the deadline is absent, write Unknown.”
Pairing the two often works better because the system knows both the boundary and the acceptable recovery behaviour.
A negative rule without a recovery path can leave the system uncertain about what to do next.
A Worked Example: Rewrite With Protected Meaning
Source: “Parents may attend. Students must attend. Registration closes Monday at noon. Venue to be confirmed.”
Constraints: preserve optional versus compulsory attendance; preserve deadline; do not invent venue; use no more than four sentences; write for parents.
A suitable output can be checked directly. If the rewrite says parents must attend, it violates preservation. If it names a venue, it violates uncertainty. If it uses eight sentences, it violates length.
The task is strong because every constraint has an observable test.
A Worked Example: Research With Source Boundaries
Question: “What are the current eligibility requirements?” Constraint set: use the current official programme page; record the page date when available; secondary sources may explain but cannot override official wording; unresolved conflicts must be listed.
These constraints shape research behaviour. They do not determine the conclusion in advance. They protect source authority and uncertainty.
A Worked Example: Data With Numerical Constraints
Task: calculate attendance rate. Constraints: registrations are the denominator; do not use room capacity; show numerator and denominator; if registrations are missing, return cannot calculate.
This prevents a common semantic error: using an available number that answers a different question.
A Worked Example: Coding With Scope Constraints
Task: fix a failing date parser. Constraints: Python 3.12; no new external dependencies; preserve public function signature; fix only the identified bug; all existing tests must continue to pass.
The constraints reduce the chance that a large rewrite creates unrelated regressions.
A Worked Example: Tool-Connected Calendar Workflow
Task: prepare a calendar event from a message. Constraints: read the approved message; extract date and time; if either is ambiguous, stop; return draft event; do not create it until explicit approval.
After approval, a second step can create the event. The workflow checks the destination calendar afterward.
A Worked Example: Student Tutoring
Task: help with an equation. Constraints: student attempts first; give at most one hint at a time; do not reveal final answer until a second attempt; provide fresh transfer question afterward.
These constraints intentionally reduce assistance because the receiver’s objective is learning, not fastest completion.
A Worked Example: Structured Brief
Task: turn meeting notes into an action brief. Constraints: fields are Action, Owner, Deadline, Status and Evidence; Unknown for missing values; Proposed actions must not be labelled Confirmed; source sentence quoted in Evidence.
The structure and semantic constraints reinforce one another. Format alone would not prevent a proposed action from being mislabelled.
Constraint Testing: Normal, Missing and Adversarial Cases
A constraint is not proven by one normal case. Test a missing-information case and a boundary case.
For a “do not invent room” constraint, normal case contains a room, missing case contains none, boundary case says “we hope to use Room 4”. The boundary should remain Proposed or Unconfirmed.
For an action constraint, test explicit approval, absent approval and contradictory approval messages.
Constraint Failure Mode 1 — Too Many Rules
An enormous prompt can contain so many constraints that important ones become difficult to distinguish. Remove rules that do not protect meaningful failure modes.
Group related constraints. Keep hard boundaries near the task. Maintain stable workflow rules in reusable system or application instructions when appropriate.
Constraint Failure Mode 2 — Hidden Priority
If the prompt says “be concise” and “include every source detail”, the model may choose a trade-off you did not intend. State priority explicitly.
Example: “Factual completeness outranks brevity. If necessary, exceed the preferred length rather than omit required deadlines.”
Constraint Failure Mode 3 — Impossible Guarantees
“Never hallucinate” and “be 100% accurate” are not sufficient controls. Replace them with behaviours: cite source, label unknowns, show calculation, stop on conflict.
Quality emerges from workflow design and verification, not motivational wording.
Constraint Failure Mode 4 — No Recovery Behaviour
A prompt may say “do not guess” without saying what to do instead. The system may become unhelpfully terse or violate the rule to finish the task.
Add recovery: ask a question, return Unknown, list conflict or stop for human review.
Constraint Failure Mode 5 — Constraint Drift in Long Conversations
Long conversations can accumulate old rules. A new task may inherit constraints that no longer apply or conflict with current goals.
Periodically restate the active constraints in a current-state brief. Archive superseded rules rather than relying on conversational memory.
Constraint Failure Mode 6 — Rules Without Technical Enforcement
For consequential external actions, a textual “do not delete” rule is weaker than read-only permissions. Use technical controls where available.
Prompt constraints and permission architecture should reinforce each other.
Constraint Failure Mode 7 — Overconstraining Creativity
Creative work can become generic when every dimension is fixed. Protect the invariant and leave freedom elsewhere.
Example: preserve brand facts and forbidden claims, but allow multiple concepts, structures and tones within the safe envelope.
Constraint Failure Mode 8 — Overfitting to One Example
A rule written after one failure may become unnecessarily narrow. Test whether the failure represents a general category before making the constraint permanent.
Use transfer cases to determine whether the rule protects useful behaviour across different inputs.
A Constraint Matrix
- Fact integrity → source and preservation constraints.
- Missing information → uncertainty constraints.
- Wrong audience → audience constraints.
- Too long or too short → length and priority constraints.
- Wrong structure → format constraints.
- Unwanted external action → action and permission constraints.
- Private data exposure → privacy constraints.
- Outdated evidence → time and source constraints.
- Wrong calculation meaning → numerical and definition constraints.
- Overhelping a learner → learning constraints.
A Practice Lab: Build a Constraint Set
Choose one recurring task. Write the final objective first. List the three failures that would matter most. Convert each failure into a constraint with observable behaviour.
Example: failure—deadline changes. Constraint—preserve deadline exactly and quote source. Failure—missing room is invented. Constraint—Unknown when absent. Failure—draft is sent. Constraint—draft only; no external action.
Run the task on one normal case, one missing-information case and one boundary case. Record which constraint failed and why.
A Practice Lab: Simplify an Overconstrained Prompt
Take a long prompt containing many rules. For each rule, ask which failure it prevents. Remove rules without a clear owner failure. Merge duplicates.
Rank remaining rules as hard or soft. Run the simplified prompt against the old evaluation set. If quality remains stable, keep the simpler version.
This exercise prevents prompt complexity from becoming permanent bureaucracy.
A Practice Lab: Convert Policy Into Operational Constraints
Choose a short official policy or school rule. Extract only the parts relevant to one task. Convert them into observable conditions.
Example: policy says personal data must not be shared externally. Operational constraint: use anonymised IDs and public/non-sensitive source material in the external SI tool.
Do not let the AI system reinterpret policy authority. Human or organisational governance determines the actual rule.
A Practice Lab: Build a Stop Condition
Choose a workflow that currently tries to complete every task. Add a state where it must stop: missing approval, conflicting source, unavailable tool or absent key input.
Test the stop condition deliberately. The correct result may be a clarification request rather than a finished artifact.
This is one of the most important transitions from chatbot use to controlled workflow design.
Receiver-Centred Constraints
Constraints should protect what the receiver needs. A parent receiving a school notice needs accurate logistics. A manager needs source-backed decisions and risks. A downstream API needs schema compliance. A student needs enough challenge to learn.
Ask what failure would mislead the receiver most. Put that protection into the constraint set.
Receiver-centred constraints prevent the prompt from becoming an abstract list of rules disconnected from use.
Constraint Maintenance
Constraints should evolve with the workflow. When a policy changes, update the relevant rule. When a failure disappears because a better system control exists, remove redundant prompt text.
Keep historical failures as tests even after simplifying the instruction. The test proves the control still exists somewhere in the system.
Version high-value constraint sets. Record the reason for major changes.
The Constraint Exit Test
Before calling the task specification complete, ask: what must not change, what may not happen, what should happen when information is missing, what permissions apply and what would cause the workflow to stop?
If those answers are clear, the system has a usable envelope. If they are hidden, the model may choose trade-offs on your behalf.
Frequently Asked Questions
How many constraints should I use?
Use as many as needed to protect meaningful failure modes, but remove decorative or redundant rules. Simpler constraint sets are easier to test and maintain.
Should constraints be written negatively?
Use negative rules for specific prohibited behaviour and pair them with the desired recovery action. “Do not invent; return Unknown” is stronger than “do not invent” alone.
Can constraints guarantee safety?
No. Prompt constraints are one layer. Important workflows also need permissions, verification, testing and appropriate human review.
What if two constraints conflict?
Define priority or redesign the task. Do not assume the system will choose the trade-off you intended.
Are constraints the same as system prompts?
Constraints can appear in different instruction layers. The concept is the behavioural boundary; implementation depends on the application.
Can constraints make creative work worse?
Yes, if they over-specify irrelevant details. Protect the real invariants and leave room for exploration elsewhere.
What comes next?
Continue with How to Get Structured Answers From Super Intelligence, where constraints become explicit output schemas, fields and machine-readable contracts.
Constraint Architecture: Which Layer Owns Which Rule?
In simple conversations, a user can place every constraint in one message. In recurring workflows, that becomes difficult to maintain. A stronger system assigns stable rules to stable layers and task-specific rules to the current task.
For example, a universal rule such as “never perform an external write without approval” belongs at the workflow or application level. A task-specific rule such as “keep this response under 250 words” belongs in the current request. A source-specific rule such as “use the 30 September version, not the 15 September draft” belongs with the current context.
This separation reduces contradiction. It also makes maintenance easier because you can update one layer without rewriting every prompt.
Stable operating rules
These rarely change: permission boundaries, privacy rules, default source hierarchy, error handling and escalation conditions. Keep them in a reusable workflow or system layer when the platform supports it.
Task rules
These change per job: audience, length, output format, deadline, focus and required deliverable. Keep them close to the current request so the active task remains easy to inspect.
Source rules
These identify which records control the answer and how conflicts are handled. They should travel with the relevant source set rather than being memorised informally.
Constraint Priority: Build a Hierarchy Before You Need One
When two constraints collide, priority decides what survives. A useful hierarchy often places safety, legality, explicit permission and factual integrity above style or convenience. The exact order depends on the organisation and task.
Consider a report with two constraints: “keep it under 200 words” and “include every confirmed safety issue”. If the safety issues cannot fit, the word limit should yield. Without a hierarchy, the system may omit material that the user actually considers non-negotiable.
Write priority only where conflict is plausible. You do not need a legal code for every prompt. But recurring high-value workflows benefit from clear precedence.
Constraint Bundles for Common SI Tasks
Research bundle
- Use current authoritative sources for current-state claims.
- Separate source fact from interpretation.
- Record date and scope.
- Do not invent missing evidence.
- Expose source conflicts.
- Limit conclusions to what the evidence supports.
This bundle can be reused across research tasks, with the specific source hierarchy changed when necessary.
Editing bundle
- Preserve dates, names, quantities and obligations.
- Do not add promises or commitments.
- Change style only where requested.
- Flag ambiguous source wording instead of resolving it silently.
- Keep unknown information unknown.
This protects the semantic content while allowing language transformation.
Learning bundle
- Require an independent attempt first where appropriate.
- Give limited hints before full solutions.
- Use fresh transfer questions.
- Do not misrepresent generated work as independent student performance.
- Preserve the learning objective even when the system could complete the task faster.
The learning bundle deliberately constrains capability to protect skill development.
Tool-use bundle
- Use only authorised tools.
- Use minimum required permissions.
- Stop when required inputs are missing.
- Return tool errors explicitly.
- Do not claim success without tool evidence.
- Require approval before consequential writes.
This bundle turns conversational intent into operational boundaries.
Constraint Compression: Reduce Rules Without Losing Protection
As workflows mature, prompts often become bloated with historical rules. Constraint compression asks whether several rules can be represented by one clearer invariant.
For example, “do not change the date”, “do not change the time”, “do not change the venue” and “do not change the owner” may be compressed into: “Preserve every confirmed logistical fact exactly; list any uncertain logistics separately.”
Compression is safe only when the combined rule preserves the old failure coverage. Keep historical tests after simplifying the instruction.
A shorter rule that survives the old test set is better than a long collection of clauses nobody can maintain.
Constraints as Tests
The best constraints can be converted directly into tests. “Do not invent missing values” becomes a test case with one missing field. “Do not send without approval” becomes a case where approval is absent.
This turns the prompt from a statement of intention into a behavioural specification. You can observe whether the workflow obeys the rule.
For recurring systems, keep the tests even when the wording of the constraint changes. The tests protect the invariant across revisions.
A Constraint Regression Set
- Normal case where all required information is available.
- Missing-information case where the system should stop or return Unknown.
- Conflict case where two sources disagree.
- Boundary case where wording is tentative or ambiguous.
- Permission case where an external write is not authorised.
- Historical failure that previously caused a real problem.
- Fresh transfer case not used to design the prompt.
Run this small set after major prompt or model changes. It is the constraint equivalent of regression testing in software.
A Worked Case Study: School Notice Rewriting
Source: “Students must report by 7.30 am. Parents may enter the hall from 8.00 am. Parking is not guaranteed. The dismissal time will be announced on the day.”
The task is to rewrite the notice for parents. Hard constraints: student arrival time, parent entry time, parking uncertainty and unknown dismissal time must be preserved. Soft preferences: friendly tone and concise wording.
A flawed answer says, “Parking is available” and “Dismissal will be at noon.” Both failures violate uncertainty constraints. A polished tone does not compensate for them.
The repair is to encode uncertainty behaviour explicitly: “Do not infer availability or dismissal time. Keep both uncertain states visible.” Then test on a second notice with different missing logistics.
A Worked Case Study: Research Summary
Suppose you are comparing two reports about the same programme. One is an official 2026 report; the other is an older commentary article. The task is to explain current eligibility and historical context.
Constraints: official current source controls current eligibility; older commentary may provide history only; any conflict must be labelled; no current claim may rely solely on the older source.
The constraint architecture now mirrors source authority. If the system quotes the older article for a current rule, the failure is easy to diagnose.
A Worked Case Study: Spreadsheet Analysis
A spreadsheet contains registrations, attendance and room capacity. The task is to calculate attendance rate.
Constraints: registrations are the denominator; capacity must not be substituted; missing registrations produce cannot calculate; percentages must be shown to one decimal place; interpretation must not claim why people were absent.
These rules protect both arithmetic and meaning. The structure makes it clear which failures belong to data quality, calculation or interpretation.
A Worked Case Study: Code Modification
An existing function has a bug with timezone conversion. The user wants the smallest repair.
Constraints: public function signature remains unchanged; no new dependencies; all existing tests must pass; add one regression test for the bug; do not refactor unrelated modules.
The system still has room to choose implementation details, but the change envelope is narrow enough to reduce accidental scope expansion.
A Worked Case Study: Agentic Workflow
An SI agent reads approved meeting notes and prepares a task list. Later it may write tasks into a project system.
Constraints: source folder is read-only; proposals are labelled Proposed; missing owners stop task creation; write action requires explicit approval; after writing, destination state is checked; failures are reported rather than retried indefinitely.
These constraints operate at several layers: source, semantic classification, permission, action and verification. The agent is useful because it has freedom inside a controlled envelope.
Constraint Negotiation: When the User Wants Two Incompatible Things
Sometimes the system should not simply choose a priority. It should expose the conflict to the user. “You asked for every detail and a 50-word limit. These cannot both be satisfied for this source. Which should take priority?”
Constraint negotiation is appropriate when the trade-off reflects user preference rather than an established system rule. It preserves agency and prevents silent compromise.
For automation, negotiation can become an escalation state: workflow pauses and requests a decision.
Constraint Provenance: Where Did the Rule Come From?
Important constraints should have an origin. A deadline may come from a course portal. A privacy rule may come from company policy. A style preference may come from the user.
Knowing provenance helps when rules conflict. An official compliance requirement should not be treated as equivalent to a temporary stylistic preference.
For high-value workflows, record the source or owner of major constraints. This makes later maintenance and review much easier.
Constraint Freshness
Constraints can become stale. A deadline changes. A permission is revoked. A course rule is updated. A maximum word count changes.
Time-sensitive constraints should be refreshed from their authoritative source. Do not let an old conversation preserve an obsolete rule indefinitely.
A useful context packet can include a “checked on” marker for constraints whose freshness matters.
Constraint Minimalism
Constraint minimalism does not mean using few rules at all costs. It means every rule should protect a meaningful property of the task.
Ask of each constraint: what failure does this prevent? How is that failure tested? If nobody can answer, consider removing the rule.
Minimalism improves both model clarity and human maintainability.
Constraint Observability
A constraint that cannot be observed is hard to enforce. “Be thoughtful” is not directly testable. “List assumptions before the recommendation” is.
Translate internal aspirations into external behaviours. “Be safe” becomes concrete only when the workflow specifies permissions, stop conditions, validation and escalation.
Observability is what turns prompt language into system design.
Constraint Recovery
When a constraint is violated, the workflow needs a recovery method. Some failures require regeneration with corrected context. Others require human review. Some external actions require rollback.
Define recovery for high-consequence tasks before deployment. “If the destination update fails, do not mark the workflow complete; return the error and keep the approved draft.”
Recovery prevents one constraint failure from turning into silent system drift.
A Constraint Review Meeting for Teams
Teams can periodically review recurring SI workflows using three questions: which constraints caught real failures, which rules are now redundant and which new failure modes have appeared?
Keep examples from actual incidents, anonymised where necessary. Convert recurring incidents into tests or stronger system controls.
Avoid adding permanent rules for every rare anomaly. Prioritise frequent, high-consequence or hard-to-detect failures.
A Constraint Design Worksheet
- Final deliverable.
- Receiver.
- Three highest-consequence failure modes.
- Hard constraints protecting those failures.
- Soft preferences.
- Source hierarchy.
- Missing-information behaviour.
- Conflict behaviour.
- Tool permissions.
- External action boundary.
- Acceptance checks.
- Stop conditions.
- Recovery path.
- Constraint owner or source.
This worksheet can be completed in a few minutes for ordinary tasks and more formally for recurring systems.
A Final Constraint Examination
Choose one workflow you already use. Remove all stylistic wording and leave only the objective, sources, hard constraints, uncertainty behaviour and checks. Run the task on one normal and one boundary case.
Then add back only the soft preferences that genuinely improve receiver usefulness. Compare the two versions. This reveals which rules control correctness and which rules control presentation.
Finally, hand the constraint set to another authorised person. Ask whether they can explain what the system may do, may not do and must do when information is missing. If they cannot, the constraint set is still too implicit.
The examination is complete when the envelope is understandable to both the model and the human operator.
Constraint Governance: What Belongs in Prompting and What Belongs Outside It
A recurring SI workflow should not depend on prompt wording alone for every important protection. Some constraints belong in the application, permissions, data pipeline or organisational process rather than in natural-language instructions.
For example, if a tool should never delete production records, read-only or limited permissions are stronger than a sentence saying “do not delete”. If sensitive files should never leave a protected environment, access architecture is stronger than asking the model to remember a privacy rule.
Prompt constraints remain useful because they explain intended behaviour and guide the model inside the allowed environment. The strongest systems align natural-language rules with technical controls.
Prompt-level controls
Best for task-specific behaviour: tone, format, source scope, output length, missing-information handling and local action boundaries.
Workflow-level controls
Best for repeatable sequencing: approval before send, source validation before drafting, checks before external write and escalation on conflict.
Permission-level controls
Best for preventing unauthorised capabilities: read-only access, restricted folders, limited APIs and narrow scopes.
Human-governance controls
Best for decisions requiring accountability, professional responsibility or value judgment. A prompt should not be used to conceal where a real human decision still belongs.
The Cost of Overconstraint
Constraints protect quality, but every constraint adds coordination cost. A workflow with fifty rules may become difficult to understand, expensive to maintain and brittle when circumstances change.
Overconstraint can also reduce useful flexibility. A creative writing system told exactly what sentence structure, vocabulary, paragraph count, examples and transitions to use may produce technically compliant but lifeless work.
Measure whether a constraint prevents an important failure. If it rarely matters and creates significant friction, consider moving it to a softer preference or removing it.
The optimal constraint set is therefore not the largest. It is the smallest set that reliably protects the task’s important invariants.
Constraint Trade-Offs: Accuracy, Speed, Cost and Flexibility
Real systems optimise several objectives at once. More verification may improve reliability but increase time. More retrieval may improve freshness but increase cost. Narrower permissions may reduce risk but require more human handoffs.
Make trade-offs explicit. If a task is low consequence and reversible, lighter controls may be appropriate. If it affects many users or is difficult to reverse, stronger checks may be justified.
Do not allow the system to choose the trade-off implicitly. State which properties matter most for the task.
Constraint Drift Across Teams
When several people use the same SI workflow, informal rules can diverge. One person adds a stricter source rule; another adds a different output format; a third assumes approval is automatic.
Keep one canonical constraint set for recurring shared workflows. Record changes and the reason for them. Retire superseded variants so users do not unknowingly operate different systems under the same name.
This is a content-governance problem as much as a prompting problem. Shared SI workflows need ownership.
Constraint Drift Across Time
Even one user can accumulate contradictions over months. Old instructions remain in saved prompts, project notes and copied templates after the task has changed.
Schedule occasional cleanup. Compare the active workflow with current reality. Remove dead constraints, update source references and verify that approval boundaries still reflect the actual process.
A stale constraint can be as harmful as a missing one because it pushes the system toward an obsolete version of the world.
Constraint Conflict Resolution Ladder
- Check whether the conflict is real or only apparent.
- Identify which constraint protects the higher-consequence property.
- Identify the source or owner of each rule.
- Resolve factual or policy conflicts using the authoritative source.
- Resolve preference conflicts by asking the responsible human.
- Record the priority or exception if the conflict is likely to recur.
- Add a test so the same conflict does not become invisible later.
This ladder prevents the model from silently resolving institutional or human disagreements through generated convenience.
A Constraint Audit for Published Content
When SI assists with a public article, constraints should protect source accuracy, attribution, current dates and claims. For example: current claims must have current sources; quotations must be accurate and short; unpublished pages must not be linked as if live; and named statistics must preserve population and time period.
A content workflow may also include editorial constraints: avoid duplicated search intent, preserve canonical ownership and maintain internal links that reflect the site’s actual architecture.
These constraints improve both reader trust and site structure because they connect content quality with publishing discipline.
A Constraint Audit for Education
Educational SI use requires a special question: does the constraint protect the learner’s development? A system that gives complete solutions instantly may satisfy task completion while undermining the learning objective.
Useful educational constraints include delayed hints, independent attempts, fresh transfer tasks and explicit separation between assisted work and assessment work.
The receiver is not only the student today. It is the student’s future unaided performance. Constraints should protect that future capability.
A Constraint Audit for Business Operations
Business workflows should identify who owns final approval, what data may be used, which sources are authoritative and what external systems may be changed.
Add stop conditions for missing owners, conflicting instructions, uncertain financial values and unavailable tools. A workflow that cannot stop safely is not ready for broad automation.
Record the external action separately from preparation. Drafting, approving and executing should remain distinguishable states.
A Constraint Audit for Software Development
Coding constraints may include supported runtime, dependency policy, public interfaces, performance targets, security requirements and test expectations.
Generated code should be constrained by the actual repository and environment, not by abstract preference. Preserve working APIs unless change is intentional. Add regression tests before broad refactoring.
The system can help propose architecture, but human engineering ownership remains necessary for production decisions.
A Constraint Audit for Research
Research constraints should define the question, source hierarchy, time window, population, treatment of disagreement and distinction between evidence and interpretation.
A strong research constraint set also limits overclaiming. “Do not infer causation from correlation unless the design supports it” is a semantic boundary that protects the conclusion.
When the evidence is mixed, the correct output may be a bounded conclusion rather than one definitive answer.
A Final Constraint Governance Gate
Before deploying or reusing an SI workflow, identify the five most important constraints and ask where each one is enforced: prompt, workflow, permission, human review or another system control.
If a high-consequence rule exists only as a fragile sentence inside a long prompt, consider whether a stronger enforcement layer is available. If the same rule exists in several places, check that the copies agree.
Then run one failure case per major constraint. Confirm that the system fails visibly, recoverably and without silently violating the protected property.
The constraint set is mature when another authorised operator can explain the envelope, the priorities, the stop conditions and the recovery path without relying on undocumented knowledge.
Good Constraints Give SI Freedom Inside the Right Envelope
The purpose of constraints is not to make SI timid. It is to define the space in which useful generation can occur without violating the parts of the task that matter.
Strong users know what should be flexible and what should be invariant. They give SI room to help while keeping evidence, permissions, obligations and uncertainty under control.
Use the complete SI learning hub to continue Stage 2. The next article turns those boundaries into structured outputs that are easier for humans and software to inspect.