How do you give Super Intelligence better instructions at work? Give it a task brief rather than a vague request. State the outcome, relevant context, authoritative sources, constraints, expected output, decision rights, stop conditions and verification standard. Better instructions do not mean longer prompts. They mean a clearer operating contract.
This article begins Part V of the eduKateSG workplace series: Delegating Work to Super Intelligence. The previous section built the information layer—context engineering, knowledge, permissions, memory and source of truth. This page owns the instruction layer: how to tell SI exactly what work to perform once the surrounding context is reliable.
In this series, Super Intelligence is the practical machine-intelligence layer commonly described as artificial intelligence, generative AI, assistants, copilots, agents and connected automation. Strong instruction design matters because capable systems can still produce weak work when the objective, evidence, boundaries or acceptance criteria are unclear.
The Short Answer
A good workplace instruction answers eight questions: What outcome do we need? Who is the receiver? What context matters? Which sources are authoritative? What constraints apply? What form should the output take? What may the system decide or do? How will the result be checked?
If one of these is missing, the system may still produce fluent output, but fluency can hide ambiguity.
The Instruction Contract
- Outcome: the real result the task should produce.
- Receiver: who will use the result.
- Context: what local information is required.
- Sources: which evidence may or must be used.
- Constraints: what must not change or be invented.
- Output: the required structure and level of detail.
- Authority: what the system may recommend, prepare or execute.
- Verification: how correctness and completeness will be checked.
This contract can fit into a short prompt for simple work or become a formal workflow specification for recurring work.
Start With the Outcome
Do not begin with “write an email” or “analyse this spreadsheet” if the real goal is to resolve a customer issue, prepare a management decision or explain a budget variance. The output should serve the outcome.
Outcome-first instructions reduce unnecessary generation because the system can distinguish what is useful from what is merely possible.
Name the Receiver
The same facts should be presented differently to an executive, customer, engineer, student or legal reviewer. Receiver context affects vocabulary, depth, evidence and decision relevance.
Do not rely on the system to infer the receiver from tone alone. State it when it changes the work.
Provide the Minimum Reliable Context
Context should include the information required to perform the task correctly—no less and no more. Too little creates guessing; too much creates noise, privacy exposure and conflicting signals.
The context-engineering article explains this broader layer. Instruction design should reference approved context rather than reproduce the whole organisation inside every prompt.
Name the Authoritative Sources
If the task depends on current facts, tell SI which source to use and what to do if the source is missing or conflicts with another source.
A strong instruction can say: “Use the CRM as the source of current account status and the current refund policy as the rule source. If they conflict with the email thread, flag the conflict instead of guessing.”
State the Constraints
Constraints define the fence around the task. Examples include word count, required sections, policy rules, tone boundaries, prohibited claims, data limitations and actions the system must not take.
Constraints should protect the real outcome rather than become arbitrary formatting rituals.
Define the Output Contract
Tell the system what form the result should take: table, decision brief, JSON schema, bullet list, draft email, issue list, checklist or ranked options.
Structured outputs reduce review cost because users know where to look for facts, uncertainty and next actions.
Define the Authority Boundary
An instruction should distinguish prepare from decide and decide from act. The system may draft a refund response without issuing a refund. It may propose a code change without deploying. It may prepare a hiring packet without rejecting a candidate.
Authority is an operating rule, not a language preference.
Define Stop Conditions
A strong instruction says when not to continue. Missing required data, conflicting sources, sensitive categories, failed tools, exceeded thresholds or unknown policy can all trigger abstention or escalation.
Stop conditions reduce the pressure for the system to manufacture completion.
Define Verification
Tell the system what should be checked and what evidence should accompany the output. For example: cite the source paragraph for each contract obligation, recalculate figures with deterministic tools, or show the CRM field supporting the customer status.
Verification becomes cheaper when it is designed into the output.
The Task Brief
A reusable workplace task brief can be compact.
- Task
- Outcome
- Receiver
- Inputs
- Sources
- Constraints
- Steps if needed
- Output format
- Uncertainty handling
- Authority boundary
- Verification
- Definition of done
For recurring work, this brief becomes more valuable than a collection of clever prompt phrases.
Instruction Quality Is Different From Prompt Length
Long prompts can still be ambiguous. Short prompts can be excellent when the system already has reliable context and the task is simple.
Instruction quality is about missing decisions. If the model must guess the objective, source, receiver or acceptance standard, the instruction is weak regardless of length.
The Specificity Balance
Too vague: “Make this better.” Too rigid: a 200-line instruction that dictates every sentence even when cases vary. The goal is enough specificity to define the task while preserving flexibility where judgment is useful.
Tell SI What Good Looks Like
Acceptance criteria are one of the strongest instruction components. A good output may need factual accuracy, complete evidence, concise structure, no unsupported claims and a clear next action.
A rubric is stronger than a vague instruction to “be high quality”.
Examples as Instructions
Examples can show style, structure, edge cases and expected reasoning. They are especially useful when the desired output is difficult to explain abstractly.
Examples should be representative and clearly labelled. Do not let an old example silently become policy.
Counterexamples
Show what bad output looks like when a common failure is predictable. For example, “Do not invent a delivery date when the carrier estimate is missing.”
Counterexamples can make stop conditions and boundaries concrete.
Rubrics
A rubric can define dimensions such as accuracy, completeness, relevance, evidence, tone and actionability. SI can use the rubric for self-check while humans use the same rubric for review.
Schemas
Structured schemas are useful when output feeds another system. Required fields, data types and allowed values can be validated deterministically.
Use language models for interpretation and schemas for structure.
Checklists
Checklists are useful for procedures and review. They reduce omission without requiring the system to reason from scratch about what must be present.
Decision Tables
If rules are explicit, put them in a decision table rather than hiding them in prose. For example: amount below threshold + verified customer + eligible policy → prepare automatic approval; otherwise escalate.
Deterministic logic should stay deterministic where possible.
Instruction Hierarchy
Workplace instructions often have several levels: organisation policy, team standard, workflow instruction, task-specific request and user preference.
The system should know which level wins when they conflict.
Organisation Instructions
These define broad data, safety, brand, legal or governance boundaries. They should be stable and shared.
Team Instructions
These define local terminology, workflow conventions, output templates and shared quality standards.
Workflow Instructions
These define the recurring sequence for one process: inputs, sources, steps, exceptions, output and handoff.
Task Instructions
These define the current instance: customer, deadline, document, question or objective.
User Preferences
These can shape presentation or working style but should not override policy or current source truth.
The Instruction Precedence Rule
Higher-authority instructions should override local preference when they conflict. A user’s desire for brevity cannot remove required legal language. A team shortcut cannot override security policy.
The Instruction Provenance Rule
Important instructions should be traceable to their owner and version, especially when agents execute workflows repeatedly.
The Instruction Currentness Rule
Policies and workflow instructions can change. Recurring SI systems should use the current version rather than an old prompt copied from a personal note.
The Instruction Versioning Rule
When a recurring instruction changes materially, record the version and retest representative cases. The workflow can behave differently even if the model does not change.
The Instruction Change Ledger
Keep a short record of major changes: what changed, why, who approved it and what evaluation was rerun.
The Instruction Simplification Rule
If an instruction keeps growing because it patches many recurring edge cases, inspect the workflow. Some conditions may belong in source data, deterministic validation, policy or routing rather than prompt text.
The Instruction Decomposition Rule
Break complex tasks into stages when one monolithic instruction hides several different operations. Retrieve context, classify, analyse, draft and verify can be separate steps.
This makes errors easier to diagnose.
The Instruction Tool Rule
Tell the system which tools it may use and for what purpose. Read-only search, calculator, database lookup and external write actions should not be treated as equivalent.
The Instruction Current-State Rule
If the task depends on live state, include an explicit refresh step before consequential action.
The Instruction Uncertainty Rule
Specify how uncertainty should appear: list missing information, distinguish fact from inference, give confidence qualitatively or ask for clarification.
Do not instruct the system to sound certain when the evidence is not.
The Instruction Evidence Rule
For research, legal, finance, policy or other factual work, require the system to attach sources to material claims. This turns review into evidence inspection rather than trust.
The Instruction Calculation Rule
Exact arithmetic should be computed with appropriate tools. SI can explain the result but should not be relied upon for complex calculations without verification.
The Instruction Output-Length Rule
Specify length only when it serves the receiver. “One-page executive brief” is useful because the reader needs compression. Arbitrary word counts can distort the task.
The Instruction Tone Rule
Tone belongs after facts and commitments. A warm tone cannot make an unsupported promise acceptable.
The Instruction Audience Rule
Tell SI what the receiver already knows and what decision they need to make. This prevents over-explaining background or omitting necessary context.
The Instruction Definition-of-Done Rule
The output is done when it satisfies the acceptance criteria and can move the workflow to the next state. A draft is not done merely because text exists.
Weak Instruction: ‘Summarise This’
A stronger version might say: “Summarise this contract for procurement. Extract pricing, term, termination rights, service levels and non-standard obligations. Cite the clause for each item. If a field is absent, say Not Found rather than infer.”
Weak Instruction: ‘Write a Reply’
A stronger version might say: “Draft a reply to the customer using the current order status and refund policy. Do not promise a delivery date unless the carrier system provides one. Keep the message under 180 words and end with one clear next step.”
Weak Instruction: ‘Analyse These Numbers’
A stronger version might say: “Using the attached monthly table, calculate changes with the spreadsheet formulas provided, identify the three largest material variances, separate observed fact from possible explanation and list the evidence needed to verify each explanation.”
Weak Instruction: ‘Plan This Project’
A stronger version might say: “Create a candidate implementation plan for the product launch. Use the confirmed launch date, current team capacity and dependencies listed below. Separate assumptions from commitments. Flag any milestone that cannot be supported by the available resources.”
Weak Instruction: ‘Review This Candidate’
A safer workplace instruction may say: “Organise the candidate’s evidence against these job-related criteria. Do not infer protected or sensitive characteristics. Identify missing evidence. Do not rank or reject; return the structured packet to the hiring manager.”
Weak Instruction: ‘Fix the Incident’
A stronger bounded instruction might say: “Review the incident logs and runbook, identify likely causes and prepare the next diagnostic steps. Do not execute production changes. Escalate if logs conflict or if the runbook does not cover the condition.”
Instruction Design for Assist
Assist-level instructions can be conversational because the user remains close. The main requirements are objective, context and review.
Instruction Design for Collaborate
Collaborative work benefits from a clearer brief, examples, rubric and iterative review.
Instruction Design for Automate
Automation instructions need eligibility, exceptions, structured output, tool permissions, validation and world-return state.
Instruction Design for Agents
Agents need objective, tool set, constraints, stopping conditions, state-management rules and recovery. “Handle this” is not a sufficient agent instruction.
Instruction Design for Teams
Shared workflows should store instructions in a maintained location, not rely on private user prompts.
Instruction Design for Personal Work
Personal instructions can remember preferences and style, but current project state and organisational rules should come from the appropriate sources.
Instruction Failure: Missing Outcome
The system optimises the requested artefact but not the business result. Repair by naming the state change the output is meant to enable.
Instruction Failure: Missing Context
The model guesses. Repair the context packet or retrieval path rather than adding vague warnings.
Instruction Failure: Conflicting Sources
The model blends contradictions. Repair by defining source precedence or escalation.
Instruction Failure: Too Many Rules
The prompt becomes a fragile policy manual. Move stable rules into structured workflow logic, schemas or maintained documentation.
Instruction Failure: No Stop Condition
The system completes every case, including those outside scope. Add observable escalation conditions.
Instruction Failure: No Verification
The output looks complete but cannot be checked efficiently. Require evidence or deterministic validation.
Instruction Failure: Hidden Authority
The instruction asks the system to “resolve” a task without specifying whether it may recommend or act. Split the authority.
Instruction Failure: Over-Specification
The instruction is so rigid that it cannot handle normal variation. Define the invariant requirements and let the model adapt within them.
Instruction Failure: Style Before Substance
The prompt spends more detail on tone than facts, sources or acceptance. Reorder the priorities.
Instruction Failure: Private Prompt Drift
Employees copy and modify a shared prompt privately until the team runs several incompatible workflows. Store recurring instructions centrally and version material changes.
Instruction Failure: Prompt as Database
The instruction embeds facts that should be retrieved from current systems. Move volatile state out of the prompt.
The Instruction Review Cycle
- Observe failures.
- Classify root cause.
- Fix source/context if needed.
- Fix instruction only if instruction caused the failure.
- Rerun representative cases.
- Version the change.
- Monitor for new failure patterns.
This prevents prompt tweaking from becoming the default repair for every system problem.
The Instruction Metrics
- First-pass acceptance
- Clarification rate
- Missing-field rate
- Unsupported-claim rate
- Exception quality
- Review time
- Consistency across users
- Instruction length growth
- Number of private variants
- Performance after version changes
The Instruction Audit
- Is the outcome explicit?
- Is the receiver known?
- Is the context sufficient?
- Are sources authoritative?
- Are constraints necessary?
- Is output structured appropriately?
- Is authority bounded?
- Are stop conditions observable?
- Is verification practical?
- Is definition of done clear?
The Instruction Maturity Ladder
Stage 1 — Ad Hoc Prompt
One user gives a one-off request.
Stage 2 — Reusable Prompt
The task instruction is reused manually.
Stage 3 — Task Brief
Context, sources, constraints, output and review become standard.
Stage 4 — Workflow Instruction
Eligibility, tools, exceptions and handoffs are encoded.
Stage 5 — Governed Operating Contract
Versioned instructions, sources, permissions and evaluation support many users or agents.
What This Article Owns
This page owns workplace SI instruction design: the task brief, constraints, output contract, authority, stop conditions, examples and verification.
The next article distinguishes a prompt from a workflow, showing why good instructions are only one component of a repeatable operating system.
Frequently Asked Questions
How long should a good prompt be?
As long as needed to remove ambiguity. Simple tasks can use short instructions; complex workflows need a fuller brief. Length itself is not quality.
What matters most in an instruction?
Outcome, context, source authority, constraints, output standard, decision rights and verification.
Should I include examples?
Yes when examples clarify structure or edge cases. Label examples clearly so they do not become unintended policy.
Should I tell SI how to reason?
Usually focus on the task, evidence, constraints and output rather than micromanaging hidden reasoning. Use explicit intermediate outputs only when they improve verification or workflow handoff.
How do I prevent hallucinations?
No instruction can guarantee zero error. Use authoritative sources, require evidence, allow abstention and verify material claims.
How do I instruct an agent?
Define objective, allowed tools, action boundaries, stop conditions, current-state refresh, verification and recovery.
Should prompts be standardised across a company?
Recurring workflows should have maintained shared instructions. One-off personal requests can remain flexible.
What if the instruction keeps getting longer?
Inspect whether rules belong in data, SOPs, schemas, validation or routing rather than prompt text.
What comes next?
Continue to Prompts vs Workflows: What Is the Difference?, which explains how a good instruction becomes only one component inside a repeatable SI process.
The Core Instruction Rule
Tell Super Intelligence what success means, what evidence it may use, what boundaries it must respect and how the result will be checked. Everything else is secondary.
The best workplace instructions make the task easier to perform and easier to review at the same time.
The Instruction Stack
A mature workplace instruction is usually built from several layers rather than one giant prompt. Stable policy sits above team conventions. Workflow rules sit above the current task. The current task adds the live objective and case-specific data.
- Organisation layer: non-negotiable policies, security and legal boundaries.
- Team layer: terminology, quality standards and shared output conventions.
- Workflow layer: steps, sources, exceptions and handoffs for one recurring process.
- Task layer: current case, document, customer or project objective.
- User layer: personal presentation preferences that do not conflict with higher layers.
This stack reduces duplication. A user should not need to repeat company security rules in every prompt if the workflow already enforces them.
The Stable-vs-Variable Rule
Separate what stays stable across cases from what changes. Stable content belongs in maintained workflow instructions. Variable content belongs in task inputs.
For example, a customer-support workflow can keep refund-policy handling and output format stable while the customer ID, order state and message vary.
The Instruction Input Contract
The system should know which inputs are required, optional or forbidden. A contract-review task may require the current agreement, standard terms and business objective. A missing required input should trigger a stop rather than guessing.
- Required: task cannot proceed without it.
- Optional: useful when available but not necessary.
- Derived: can be calculated or retrieved from other inputs.
- Forbidden: should not enter the task because of privacy, security or scope.
The Instruction Output Contract
The output contract should make the result easy to consume and verify. If the output feeds another system, use a schema. If a human decision follows, structure the result around facts, evidence, uncertainty and requested decision.
Good output contracts reduce downstream clarification and review time.
The Instruction Error Contract
Define what happens when the system cannot satisfy the task. Error output should be structured too: missing source, conflicting evidence, tool failure, out-of-scope case or validation failure.
A useful error response can be more valuable than a guessed answer.
The Instruction Escalation Contract
When the task leaves the normal path, specify who receives the exception and what packet they need. The instruction can require the system to include verified state, reason for escalation and unresolved decision.
The Instruction Tool Contract
List which tools the system may call and what each tool is for. This prevents an agent from using a convenient tool outside the intended task.
- Search approved policy
- Read CRM account state
- Calculate exact totals
- Create draft ticket
- Do not send external email
- Do not change production state
The Instruction Data Contract
Define which data classes the task may use. This is especially important when the system can access large organisational repositories.
The instruction should prefer minimum necessary data rather than maximum context.
The Instruction Time Contract
Time can matter to correctness. State deadlines, effective dates and freshness requirements where relevant. “Use the current price at the time of sending” is stronger than “use the price below” if the price can change.
The Instruction Identity Contract
When actions occur under a user’s authority, the system should know whose identity and permissions apply. A workflow running under a service account may have a different boundary from a user-initiated assistant.
The Instruction Decision Contract
Clarify whether the system is gathering evidence, recommending, deciding or executing. These are distinct roles.
A decision contract can say: “Recommend one option and explain trade-offs. Do not commit the organisation. Return the recommendation to the project owner.”
The Instruction Evidence Contract
For material factual work, require traceability. This can include source links, quoted fields, record IDs or calculations.
Evidence contracts are especially useful for legal, finance, procurement, research and policy workflows.
The Instruction Currentness Contract
Specify which facts must be refreshed before the system acts. If the task depends on customer status, project deadline or inventory, retrieve the live state at the appropriate step.
The Instruction Ambiguity Contract
Tell the system how to handle unclear requests. It may ask a targeted question, choose from bounded interpretations or return the ambiguity to a human.
Do not force every ambiguous input into a confident route.
The Instruction Terminology Contract
Define organisation-specific terms and acronyms that could be misunderstood. Stable terminology belongs in shared context; task-specific shorthand belongs in the current brief.
The Instruction Priority Contract
When several objectives compete—speed, accuracy, brevity, completeness—state the priority order. Without it, the system may optimise the wrong dimension.
The Instruction Risk Contract
High-consequence tasks should state what outcomes are unacceptable and what conditions require additional review.
A risk contract can be more useful than generic phrases such as “be careful”.
The Instruction Retry Contract
Connected workflows need rules for retries. Retrying a read may be harmless; retrying a payment or record creation can create duplicates.
Specify how the system should verify action state before repeating non-idempotent operations.
The Instruction Closure Contract
Define what proves completion. A draft is not a sent message. A proposed update is not an updated system. A code change is not deployed code.
The instruction should tell the system what world-return signal counts as done.
The Instruction Review Contract
State what the human reviewer is responsible for checking. If the reviewer only needs to judge tone and exception policy, do not require them to reconstruct deterministic calculations already validated elsewhere.
The Instruction Learning Contract
Recurring workflows can record material corrections and exception reasons. Those observations should feed instruction or source improvements rather than remain private edits.
A Better Instruction for Research
Weak: “Research our competitors.” Better: “Prepare a competitor brief for the product-strategy team. Use only the approved public sources and current internal market notes. Compare pricing model, target segment, key features, positioning and recent changes. Separate sourced facts from your synthesis. Cite every material factual claim. Flag unknowns rather than infer.”
The better instruction defines receiver, sources, comparison dimensions, uncertainty and evidence.
A Better Instruction for a Management Brief
Weak: “Summarise this project.” Better: “Prepare a one-page management brief for the COO using the current project system as the source of milestone state. Include objective, progress against plan, top three blockers, decisions required this week, owners and deadlines. Do not repeat background unless it affects a decision. Flag any missing update.”
A Better Instruction for Procurement
Weak: “Compare these suppliers.” Better: “Extract each supplier’s price, implementation fee, service level, term, termination rights and exclusions into the common comparison schema. Cite the source page for every value. Do not rank suppliers until the procurement owner confirms a normalised basis.”
A Better Instruction for Sales
Weak: “Prepare for the call.” Better: “Create a pre-call brief from CRM and the latest approved meeting notes. Include current opportunity stage, prior commitments, unresolved customer questions, relevant product information and three discovery questions. Do not infer budget or authority when CRM does not support it.”
A Better Instruction for Customer Support
Weak: “Reply to the customer.” Better: “Use the current account record and active support policy. Draft a response under 180 words that states the confirmed status, what we can do now and one next step. Do not promise refund, delivery date or credit unless the authoritative source confirms eligibility. Escalate disputes or conflicting account state.”
A Better Instruction for Finance
Weak: “Explain the variance.” Better: “Using the approved monthly figures, calculate the variance with the spreadsheet formulas, identify the three material changes above the reporting threshold, and prepare candidate explanations. Separate observed numbers from hypotheses. List which evidence is needed to verify each explanation before the report is final.”
A Better Instruction for HR Administration
Weak: “Review this applicant.” Better: “Organise the applicant’s submitted evidence against the approved job-related criteria. Identify supported, unsupported and missing evidence. Do not infer protected characteristics or make the final hiring decision. Return a structured evidence packet to the hiring manager.”
A Better Instruction for Legal Review
Weak: “Review this contract.” Better: “Compare the current draft against the approved standard template. Identify changed or missing clauses, quote the relevant language and classify each deviation by the legal playbook. Do not provide final legal advice or approve the agreement. Escalate clauses outside the playbook.”
A Better Instruction for Engineering
Weak: “Fix this bug.” Better: “Investigate issue 214 using the current repository and failing test. Propose the smallest code change that addresses the documented behaviour. Add or update tests. Do not modify deployment configuration or merge. If acceptance criteria conflict, stop and flag the ambiguity.”
A Better Instruction for Operations
Weak: “Handle the alert.” Better: “Review the alert, current telemetry and approved runbook. Classify the incident, summarise evidence, identify the next diagnostic step and prepare the escalation packet. Do not execute production remediation unless the runbook explicitly permits this action and the current state meets the defined threshold.”
A Better Instruction for Education
Weak: “Make practice questions.” Better: “Create six practice questions for this learner on the identified algebra misconception, using the approved curriculum objective. Begin with two scaffolded examples, then four independent transfer items. Provide answers and one misconception note per item. Do not introduce concepts outside the current unit.”
A Better Instruction for Executive Decision Support
Weak: “What should we do?” Better: “Prepare a decision brief for the executive team. Separate confirmed facts, assumptions, options, risks, second-order effects and unresolved evidence. Present the strongest case for and against each option. Do not choose on behalf of the executive team; state which assumptions most affect the trade-off.”
The Instruction Compression Test
After a workflow becomes stable, shorten the instruction without removing important invariants. Long prompts often contain historical patches that are no longer necessary once sources, schemas and validation are improved.
A shorter maintained instruction is easier to review and version.
The Instruction Independence Test
Give the instruction to another authorised user. If they obtain very different results because the original user supplied hidden context, the brief is incomplete.
The Instruction Edge-Case Test
Test missing input, conflicting source, threshold boundary and unusual format. The instruction should route or abstain rather than improvise.
The Instruction Source-Conflict Test
Supply two conflicting records. Confirm that source precedence or escalation works as designed.
The Instruction Permission Test
Ask the system to take an action outside its permission. The workflow should refuse or return a prepared action rather than quietly escalating its authority.
The Instruction Currentness Test
Change a live source after the task begins. Confirm that the system refreshes the state before consequential action when required.
The Instruction Verification Test
Seed a known factual error or incorrect field and confirm that the review or validation process detects it.
The Instruction Receiver Test
Ask the downstream receiver whether the output is structured for their decision. A technically correct output can still be poorly instructed if the receiver must reformat or reconstruct it.
The Instruction Cost Test
A complicated instruction can consume more setup and review than the task saves. Measure total workflow effort rather than prompt quality in isolation.
The Instruction Scalability Test
At larger volume, ambiguity that was tolerable for one user becomes expensive. Standardise only after representative cases show which rules are stable.
The Instruction Governance Test
For shared or high-impact workflows, confirm owner, version, effective date, approved sources and permissions. An old prompt should not remain operational after policy changes.
The Instruction Security Test
If the system reads untrusted content, confirm that external text cannot override the trusted instruction hierarchy or cause unauthorised tool actions.
The Instruction Privacy Test
Ensure the brief does not require unnecessary sensitive data. Data minimisation belongs in instruction design as well as system architecture.
The Instruction Maintenance Rule
A recurring instruction needs an owner. The owner reviews failures, source changes and policy updates, then approves material changes.
The Instruction Retirement Rule
When a workflow ends or a better system replaces it, retire the old instruction so employees and agents do not continue using obsolete versions.
The Instruction Registry
Teams with many recurring SI workflows can maintain a small registry containing instruction name, purpose, owner, version, source dependencies, autonomy level and last evaluation date.
This prevents private prompt sprawl.
The Instruction-to-Workflow Transition
When an instruction becomes recurring, the next step is not necessarily a longer prompt. It is a workflow: trigger, context, instruction, tools, validation, handoff and closure.
This is the conceptual bridge to the next article.
The Instruction and Memory Relationship
Memory can supply stable user preferences and project continuity. The instruction should still retrieve current facts and follow current shared rules.
See Memory and Personalisation in Workplace Super Intelligence.
The Instruction and Source-of-Truth Relationship
A task brief should name or route to authoritative sources. See How to Create a Reliable Source of Truth for Super Intelligence.
The Instruction and Context-Engineering Relationship
Context engineering decides what information enters the task. Instruction design decides what the system should do with that context.
Confusing the two can produce prompts overloaded with source data or retrieval systems with no clear task.
The Instruction and Agent Relationship
Agents need stronger operating contracts because they choose intermediate steps. The objective and stopping rules matter as much as the requested output.
The Instruction and Human-Review Relationship
The output contract should make review efficient. If the human cannot see sources, assumptions or changed fields, instruction design has failed downstream.
The Instruction and Handoff Relationship
Instructions should specify what state the next receiver needs. This turns generation into an operable handoff rather than an isolated artefact.
The Instruction and Measurement Relationship
A repeatable instruction should be evaluated against the same quality and workflow metrics over time. If performance changes, inspect sources, model, instruction and case mix separately.
The Instruction Review Meeting
For important shared workflows, periodically review representative outputs and the instruction with process owner, frontline user and receiver. Remove obsolete rules and promote stable logic into deterministic components where appropriate.
The Instruction Failure Catalogue
- Outcome omitted
- Receiver omitted
- Wrong or missing source
- Conflicting context
- Unnecessary sensitive data
- Ambiguous authority
- No stop condition
- Unverifiable output
- Overly rigid format
- Private version drift
- Stale policy embedded in prompt
- Tool permissions broader than task
Classify failures before editing the instruction. Not every error is a prompting problem.
The Instruction Repair Sequence
- Identify the failure.
- Find the earliest weak layer.
- Repair source or context if necessary.
- Repair instruction only where it caused ambiguity.
- Add deterministic validation when the rule is exact.
- Retest representative cases.
- Version the change.
- Monitor downstream review and exceptions.
The Instruction 30-Day Build
Week 1 — Observe
Collect real examples of the task and the corrections experienced users make.
Week 2 — Brief
Write the task contract: outcome, context, sources, constraints, output and verification.
Week 3 — Test
Run normal, edge and should-stop cases with several users.
Week 4 — Standardise
Remove unnecessary wording, version the working instruction and place it in the shared workflow.
The Instruction Checklist
- Outcome is explicit.
- Receiver is known.
- Required inputs are defined.
- Sources are authoritative.
- Context is sufficient but not excessive.
- Constraints protect real risks.
- Output is easy to review.
- Authority is bounded.
- Stop conditions are observable.
- Verification is defined.
- Definition of done is external to generation.
- Instruction owner and version are known for recurring workflows.
The Instruction Standard
A strong workplace instruction makes the work unambiguous without making the system brittle. It defines the invariant requirements, gives the model the right context and leaves flexibility only where flexibility is useful.
When that standard is met, better prompting stops being a personal trick and becomes part of a repeatable organisational workflow.
Instruction Pattern: Evidence First
For factual work, make evidence the first output and prose the second. Ask SI to identify the source, extract the relevant fact and then produce the interpretation.
This pattern is useful for legal, finance, policy, procurement and research because it reduces the risk that polished language outruns the evidence.
Instruction Pattern: Facts, Inference, Recommendation
Require three separate sections: confirmed facts, model interpretation and recommended next action. This prevents the system from blending evidence and judgment into one fluent paragraph.
The pattern also makes human review faster because the reviewer knows which layer requires source checking and which layer requires judgment.
Instruction Pattern: Known, Unknown, Needed
For incomplete cases, ask SI to return what is known, what remains unknown and what evidence is needed next. This is stronger than instructing the system to complete the task at all costs.
The pattern is especially useful for support, research, investigation and incident workflows.
Instruction Pattern: Compare, Do Not Choose
When the organisation wants comparability before judgment, instruct SI to normalise and compare without ranking. This prevents premature recommendation when the basis is not yet stable.
Procurement and legal review often benefit from this pattern.
Instruction Pattern: Prepare, Do Not Act
Connected systems can prepare an external action while withholding execution. The instruction can ask SI to create the draft email, purchase request, code change or CRM update and return it for approval.
This is one of the most useful intermediate autonomy patterns because it preserves leverage without transferring final authority.
Instruction Pattern: Routine Core, Exception Edge
Define the normal eligible class and a separate exception rule. SI handles the stable core and returns exceptions with evidence.
This pattern is stronger than asking a model to judge every case using one broad instruction.
Instruction Pattern: One Source per Fact Class
If a workflow uses several systems, tell SI where each type of fact comes from. For example, use CRM for account status, the policy repository for eligibility rules and the calendar for confirmed appointment time.
This reduces source blending and aligns the instruction with the source-of-truth architecture.
Instruction Pattern: Delta Only
For recurring review, ask SI to report only what changed since the previous accepted state. This can reduce information overload in project, contract and document workflows.
The output should still link to the current full state for verification.
Instruction Pattern: Exception Brief
When normal processing stops, return a compact packet: current state, verified evidence, reason for escalation, actions already attempted and exact decision required.
This turns failure into a usable handoff rather than a vague “needs human review” message.
Instruction Pattern: Decision Brief
For judgment-heavy work, instruct SI to prepare options, evidence, trade-offs, assumptions and unresolved questions rather than to choose automatically.
The human decision-maker receives a structured basis for judgment.
Instruction Pattern: Critique Before Rewrite
When improving an existing artefact, ask SI first to identify weaknesses against a rubric, then revise. This preserves the reasoning about why changes are needed and can prevent style-only rewrites.
Instruction Pattern: Verify Before Finalise
Add a final validation step to recurring instructions: check required fields, source citations, calculations, constraints and stop conditions before marking the output ready.
This is useful even when the final verification is partly deterministic.
Instruction Pattern: Tool Result Before Narrative
For tool-using agents, require the system to use the returned tool state before narrating success. The agent should not say “I updated the record” until the tool confirms the update.
Instruction Pattern: Ask One Clarifying Question
When the task is ambiguous but easily repairable through one missing input, allow the system to ask a targeted clarification rather than guess or return a long uncertainty list.
This pattern is especially useful in interactive assistance but less suitable in unattended automation where escalation rules may be better.
Instruction Pattern: Preserve Missingness
Tell the system to return Not Found, Unknown or Missing when the source does not contain a required value. This prevents plausible completion from turning absence into false data.
Instruction Pattern: Preserve Dissent
When sources or reviewers disagree, instruct SI to show the disagreement rather than synthesise it into a single answer.
This matters in research, strategy and governance where disagreement itself may be material.
Instruction Pattern: No Hidden Assumptions
Require assumptions that materially affect the output to be listed explicitly. The human can then accept, reject or replace them.
Instruction Pattern: Receiver-First Output
Structure the output around what the receiver needs to decide or do. This is often more valuable than asking for a generic “comprehensive” answer.
Instruction Pattern: Fixed Core, Flexible Surface
Keep facts, required sections and constraints fixed while allowing SI to adapt wording and explanation to the audience. This preserves control without making every output robotic.
Instruction Pattern: Source-Bounded Generation
For organisation-specific facts, instruct SI to use only specified approved sources. If the sources do not support the answer, return the gap.
This is a useful pattern for policy, customer support and knowledge assistants.
Instruction Pattern: Source-Expanded Research
For exploratory research, the opposite may be useful: allow discovery beyond the starting set, but require source-quality criteria, dates and traceability.
The instruction should match the research stage rather than apply one source rule everywhere.
Role Playbook: Executive
Executive instructions should prioritise decision relevance, evidence and brevity. Ask SI to surface exceptions, trade-offs and assumptions rather than summarise everything.
A typical output contract can be one page: decision required, facts, options, recommendation, risks and unresolved evidence.
Role Playbook: Manager
Managerial instructions often revolve around project state, one-on-ones, priorities and follow-through. Require current sources and clear ownership.
Sensitive personnel judgments should remain human-led.
Role Playbook: Sales
Sales instructions should distinguish account facts, relationship context and commercial authority. SI can prepare briefs and follow-up while avoiding unsupported pricing or delivery promises.
Role Playbook: Customer Support
Support instructions should define eligible case classes, approved policy, customer-state source and escalation rules. Drafting quality matters less than policy accuracy and resolution.
Role Playbook: Marketing
Marketing instructions need audience, objective, evidence for claims, brand constraints and channel format. SI can create variations while factual and regulated claims remain grounded.
Role Playbook: Finance
Finance instructions should separate exact calculation from narrative interpretation. Numbers come from authoritative systems; SI explains, compares and drafts around them.
Role Playbook: HR
HR instructions should clearly separate administration from employment decisions. SI can structure evidence and communication while sensitive judgments remain under authorised human processes.
Role Playbook: Legal
Legal instructions should specify jurisdiction, document version, source authority, issue scope and whether the task is extraction, comparison, drafting or professional interpretation.
Role Playbook: Engineering
Engineering instructions should include repository context, acceptance criteria, tests, allowed files, branch boundaries and deployment limits.
Role Playbook: Operations
Operations instructions should define current telemetry, runbook, escalation threshold, permitted actions and recovery. The system should not improvise outside the operating envelope.
Role Playbook: Research
Research instructions should define question, source criteria, evidence extraction, synthesis method and how uncertainty or disagreement should be represented.
Role Playbook: Education
Education instructions should define learning objective, learner level, approved curriculum, expected output and pedagogical boundary. SI can prepare content while educators own learning judgments.
Instruction Design for Email
Email instructions should specify facts, recipient, purpose, commitment boundary, tone and next action. See the dedicated email article for the full workflow.
Instruction Design for Meetings
Meeting instructions should produce agenda, decision packet, action list or follow-up state rather than generic minutes.
Instruction Design for Writing
Professional writing instructions should identify audience, purpose, evidence, structure, tone, claims and review standard.
Instruction Design for Data Analysis
Data instructions should define the question, source dataset, calculation method, materiality threshold and the difference between observed result and interpretation.
Instruction Design for Planning
Planning instructions should separate candidate milestones from accepted commitments and identify dependencies, assumptions and resource constraints.
Instruction Design for Documentation
Documentation instructions should identify owner, intended user, source material, currentness and what triggers revision.
Instruction Design for Learning
Learning instructions should specify what capability the user needs to demonstrate and include practice, feedback and transfer rather than explanation alone.
Instruction Design for Agents
Agent instructions should include a bounded objective, allowed tools, state model, stopping conditions, retry rules, action permissions, verification and recovery.
The stronger the tool access, the less acceptable a vague instruction becomes.
The Agent Objective
A good agent objective describes a state to achieve without granting unlimited means. “Resolve eligible support requests using the approved policy and tools within these limits” is stronger than “take care of support”.
The Agent Tool Boundary
Specify which tools can be used and whether they are read-only, prepare-only or execute-capable.
The Agent Stop Boundary
Stop on missing evidence, source conflict, exceeded threshold, sensitive case, failed tool or task outside scope.
The Agent Retry Boundary
Before retrying an external action, verify whether the previous attempt succeeded. This is critical for non-idempotent operations.
The Agent Memory Boundary
Persistent agent memory can support continuity, but current state must be refreshed from authoritative systems before consequential action.
The Agent Time Boundary
Long-running agents should checkpoint and revalidate deadlines, permissions and source state as time passes.
The Agent Completion Boundary
Completion should be based on world-return evidence, not narrative self-report.
The Instruction Review Rubric
- Clarity: is the outcome understandable?
- Grounding: are authoritative sources identified?
- Scope: are included and excluded cases clear?
- Control: is authority bounded?
- Verifiability: can material output be checked?
- Exception handling: can the system stop or escalate?
- Receiver fit: can the downstream user act on the output?
- Maintainability: can the instruction be updated without hidden private variants?
The Instruction Red-Team Test
Try the instruction with incomplete data, conflicting sources, unusual wording, threshold cases and adversarial or irrelevant instructions inside external content.
The goal is to learn whether the operating contract survives messy reality.
The Instruction Drift Test
Compare current output with a baseline set after material model, source or prompt changes. Drift can come from any layer.
The Instruction Adoption Test
If users repeatedly bypass the maintained instruction, investigate why. It may be too rigid, slow or disconnected from real work.
Shadow prompting can reveal a workflow-design problem.
The Instruction Transfer Test
Before copying an instruction into another department, compare sources, receiver, authority and consequence. Reuse the pattern, not blindly the text.
The Instruction Cost-of-Change Test
A recurring instruction should be easy to update centrally. If hundreds of private copies exist, one policy change creates a large maintenance burden.
The Instruction Ownership Triangle
Important instructions often need process owner, knowledge owner and technical owner. The process owner defines outcome, knowledge owner controls sources and technical owner maintains implementation.
The Instruction Decision Gate
Before promoting an instruction into automation, confirm that it works across representative cases, exceptions are known, output can be verified and permissions can be scoped.
The Instruction Promotion Path
- One-off prompt
- Reusable prompt
- Shared task brief
- Versioned workflow instruction
- Connected workflow
- Bounded automation
- Agentic operating contract
Each stage should add only the structure justified by repeated use.
The Instruction Demotion Path
If performance degrades or the environment changes, move from automation back to review or manual prompting while the cause is diagnosed.
The Instruction Retirement Path
When the workflow ends, remove the instruction from active libraries, revoke related permissions and archive only what remains useful as history.
The Instruction Change Trigger
- Policy change
- Source migration
- New tool permission
- Model change
- New case class
- Material incident
- Receiver requirement change
- Repeated correction pattern
These events should trigger review rather than allow silent drift.
The Instruction 15-Minute Audit
- Write the outcome.
- Name the receiver.
- List required inputs.
- Name authoritative sources.
- Delete unnecessary context.
- Write constraints.
- Define output structure.
- Define authority.
- Write stop conditions.
- Write verification.
- Define done.
- Test one edge case.
The Instruction One-Page Standard
Most recurring workplace instructions should fit on one page when sources, schemas and policies are maintained separately. If the instruction becomes a manual, the surrounding workflow probably needs refactoring.
The Instruction Portfolio
A large organisation can maintain a portfolio of important SI instructions with owner, version, autonomy level, last evaluation and dependent sources.
This gives governance teams visibility without centralising every personal prompt.
The Instruction Failure Review
When output fails, ask whether the cause was model capability, source quality, context selection, instruction ambiguity, validation, permissions or human review. This protects the organisation from endless prompt tweaking.
The Instruction Success Review
When a workflow performs well, identify which part mattered. Strong source grounding or a structured schema may be more important than the exact wording of the prompt.
The Instruction Learning Loop
Repeated corrections should move upstream. If users repeatedly add the same source, automate retrieval. If they repeatedly correct the same field, add validation. If they repeatedly clarify the same rule, update the shared instruction or policy.
The Instruction Final Checklist
- Outcome is explicit.
- Receiver is explicit.
- Inputs are sufficient.
- Sources are authoritative.
- Context is scoped.
- Constraints are meaningful.
- Output is reviewable.
- Authority is bounded.
- Tools are permitted deliberately.
- Stop conditions are visible.
- Uncertainty is represented.
- Verification is practical.
- Definition of done is observable.
- Owner and version exist for recurring work.
The Final Instruction Principle
Better instructions do not tell Super Intelligence more words; they give it fewer unresolved decisions about what the task actually is.
When outcome, evidence, constraints, authority and verification are explicit, the model can use its flexibility where flexibility helps—and the workplace can still understand what happened.
The Instruction Governance Layer
Once instructions are shared across teams or used by agents, they become operating assets rather than personal wording. Important instructions should have an owner, version, review date, dependent sources and an autonomy classification.
Governance does not mean every employee needs approval for every prompt. It means the recurring instructions that shape consequential workflows are maintained with the same seriousness as templates, SOPs and business rules.
The Instruction Owner
The process owner should define the outcome and acceptance criteria. A technical owner may implement the workflow. A knowledge or policy owner controls source material. These responsibilities can be held by one person in a small organisation, but they should remain conceptually distinct.
The Instruction Review Date
Set a review trigger or date for recurring instructions. Changes in policy, data source, model, permissions or receiver requirements can make an old task brief unreliable.
The Instruction Dependency Map
List the sources, schemas, tools and policies the instruction depends on. When one dependency changes, the team can identify which instructions require retesting.
The Instruction Evaluation Set
Maintain representative cases for important recurring instructions: normal cases, difficult cases, missing-data cases, source conflicts and examples that should trigger abstention.
The evaluation set should remain stable enough to detect regressions while evolving when the workflow encounters genuinely new conditions.
The Instruction Acceptance Threshold
Define what level of performance is sufficient for the current autonomy. Draft-only work may tolerate more correction than automatic external action. The threshold should become stricter as consequence and irreversibility increase.
The Instruction Rollback Rule
If a new instruction version performs worse, return to the previous known-good version while the failure is diagnosed. Versioning has little value if the team cannot roll back.
The Instruction Experiment Rule
Test new wording, examples or structure in a bounded environment before replacing a proven production instruction. This prevents prompt experimentation from silently altering live workflow behaviour.
The Instruction Documentation Rule
Document the purpose of a recurring instruction in one sentence. Future maintainers should know why each important rule exists, especially when it was added after a failure or incident.
The Instruction Cleanup Rule
Remove instructions that no longer serve a workflow. Prompt libraries become difficult to trust when obsolete versions remain active and visually similar to current ones.
The Instruction Security Boundary
Trusted operating instructions should be separated from untrusted external content. An email, PDF, webpage or customer message may contain text that looks like an instruction but should be treated only as data.
This separation becomes critical when agents can call tools or access sensitive systems.
The Instruction Prompt-Injection Test
Include a representative test where external content asks the system to ignore the workflow, reveal secrets or take an unauthorised action. The system should preserve the trusted instruction hierarchy.
The Instruction Data-Leak Test
Ask whether the output could expose information from sources outside the receiver’s permission. A strong task brief must operate inside the same access controls as the underlying data.
The Instruction Overreach Test
Ask the system to perform a nearby but unauthorised task. An assistant allowed to draft should not send; an agent allowed to read a customer record should not edit it.
The Instruction Source-Failure Test
Remove or corrupt one required source. The correct result should be a visible exception or degraded mode, not a confident fabricated replacement.
The Instruction Tool-Failure Test
Simulate a failed tool call. The workflow should preserve uncertain state, avoid unsafe retries and return enough information for recovery.
The Instruction Timing Test
Change a time-sensitive fact between preparation and execution. Confirm that the system refreshes the fact when the instruction requires current state at action time.
The Instruction Receiver-Change Test
Change the intended receiver from specialist to executive or customer. The system should adapt structure and explanation while preserving the same underlying facts.
The Instruction Policy-Change Test
Replace an old policy with a new effective version. Confirm that the workflow uses the current source rather than cached prompt text or memory.
The Instruction Role-Change Test
Change the user’s role or approval rights. The workflow should not continue applying outdated authority embedded in personalisation.
The Instruction Collaboration Test
Have two different trained users run the same recurring task. Large variation may reveal missing context, unclear acceptance criteria or private prompting habits.
The Instruction Transfer Test Across Teams
Move the pattern to another department only after adapting source, terminology, authority and receiver. A procurement comparison prompt and a legal comparison prompt may share structure but require different controls.
The Instruction Minimalism Test
Delete any sentence whose removal does not change the workflow. This keeps maintained instructions easier to understand and reduces contradictory constraints.
The Instruction Redundancy Test
If the same rule appears in policy, workflow logic and prompt text, decide which layer should own it. Redundant copies can drift out of sync.
The Instruction Determinism Test
Ask whether an exact rule should be implemented as code, formula, schema or threshold instead of natural-language instruction. Deterministic controls are easier to test and audit.
The Instruction Flexibility Test
Ask whether the system needs latitude for normal variation. If the task involves writing, explanation or analysis, overly rigid step-by-step instructions can reduce quality. Keep the invariant requirements fixed and allow flexibility in the surface solution.
The Instruction Clarity Test
Give the brief to a competent colleague who did not write it. If they cannot explain the intended outcome, sources, limits and definition of done, the instruction is still too dependent on private understanding.
The Instruction Review Interface
Instruction design should consider how the result will be reviewed. A reviewer benefits from source links, changed fields, assumption lists and exception flags. These elements belong in the output contract rather than being added after generation.
The Instruction Handoff Interface
If another team receives the output, define the state, evidence, next action and owner they need. Good instructions finish by creating a usable handoff.
The Instruction Audit Trail
For consequential workflows, preserve the instruction version, source versions, important tool results and approvals used for the output. This allows later reconstruction without storing unnecessary detail forever.
Instruction Pattern: Executive Summary
Outcome: prepare a decision-ready brief. Required structure: decision needed, three material facts, options, recommendation, risks, unknowns. Constraints: one page, source-linked facts, no invented certainty. Authority: recommend only.
Instruction Pattern: Customer Reply
Outcome: resolve or advance the customer issue. Required structure: confirmed state, action available now, next step. Constraints: no unsupported promise, no internal jargon, escalate disputes. Authority: draft only or send only for explicitly eligible classes.
Instruction Pattern: Research Extraction
Outcome: populate an evidence table. Required structure: source, date, methodology, finding, limitation, quote location. Constraints: preserve missingness, no unsupported inference.
Instruction Pattern: Incident Brief
Outcome: give incident lead a current decision packet. Required structure: impact, confirmed facts, hypotheses, actions tried, tool state, risks, requested decision. Constraints: distinguish evidence from speculation.
Instruction Pattern: Learning Material
Outcome: produce practice aligned to one learning objective. Required structure: scaffolded examples, independent practice, answers, misconception notes. Constraints: approved curriculum and target difficulty.
Instruction Pattern: Contract Deviation Table
Outcome: identify departures from standard terms. Required structure: clause, current text, standard text, deviation type, source reference, playbook category. Authority: no final legal advice.
Instruction Pattern: Variance Commentary
Outcome: prepare management explanation. Required structure: actual, comparison, variance, observed driver, hypothesis, evidence needed. Exact arithmetic comes from the finance tool.
Instruction Pattern: Project Handoff
Outcome: transfer work without reconstruction. Required structure: current state, completed work, evidence, open questions, next action, owner, deadline and closure condition.
Instruction Pattern: Agent Task
Outcome: achieve a bounded state using allowed tools. Required structure: objective, constraints, tools, stopping conditions, checkpoint rules, external-action limits, verification and world return.
The Instruction Anti-Pattern: Persona Overload
Telling SI to act as ten expert personas rarely substitutes for clear sources and task criteria. Use role framing only when it clarifies the receiver, expertise or perspective required.
The Instruction Anti-Pattern: Magic Words
Phrases such as “be brilliant”, “think deeply” or “use maximum intelligence” are weaker than concrete evidence, constraints and acceptance standards.
The Instruction Anti-Pattern: Hidden Data
The prompt says “you know the context” when the system does not have the actual current data. Make the context path explicit.
The Instruction Anti-Pattern: Endless Caveats
The prompt accumulates warnings after every failure. Move stable rules into the proper layer and redesign the workflow.
The Instruction Anti-Pattern: Output Without Receiver
The system produces comprehensive material that no one can use efficiently. Name the receiver and their decision.
The Instruction Anti-Pattern: No Definition of Done
The system keeps iterating because there is no acceptance boundary. Define what makes the output usable enough to move forward.
The Instruction Anti-Pattern: Acting on Inference
An inferred value triggers an external action. Require authoritative evidence for fields that unlock money, access, commitments or other consequential state changes.
The Instruction Anti-Pattern: Mixing Draft and Send
The same instruction both writes and sends without an explicit gate. Separate production from execution.
The Instruction Anti-Pattern: Treating All Errors as Model Errors
Bad data, missing context, unclear policy, tool failure and weak review can all produce bad output. Diagnose the whole system.
The Instruction Improvement Flywheel
Observe real cases, classify corrections, move fixes upstream, simplify the instruction, update the evaluation set and retest. Over time, the prompt should often become shorter because sources and workflow logic become stronger.
The Final Instruction Audit
- Outcome states the real result.
- Receiver and decision are explicit.
- Required and forbidden inputs are known.
- Sources are authoritative and current.
- Stable context is separated from live state.
- Constraints protect real risks.
- Output contract supports review.
- Authority boundary is explicit.
- Tools are scoped.
- Stop conditions are observable.
- Errors and exceptions have a route.
- Verification is practical.
- Definition of done is observable.
- Owner, version and evaluation exist for recurring use.
The Instruction Floor
If a workplace instruction does not make outcome, evidence, authority and verification clear, it is not ready to become automation.
Good instructions can remain conversational for low-risk assistance. The moment the task becomes repeatable, shared or tool-connected, the operating contract should become explicit.
The Final Instruction Standard
Give Super Intelligence enough structure to understand the work, enough evidence to ground it, enough boundaries to remain governable and enough freedom to use intelligence where intelligence adds value.
That balance is the bridge from a prompt to a workflow.
The Instruction Pre-Flight Check
Before a recurring instruction is used on live work, run a short pre-flight check. Confirm that the task is still the right task, the source locations are current, the user or agent still has the intended authority, the output still matches the receiver’s needs and the stop conditions still reflect the real exceptions.
This check prevents an old prompt from surviving after the workflow around it has changed. Many instruction failures are not caused by bad wording; they are caused by a once-good instruction operating in a new environment.
The Instruction Post-Flight Check
After the task completes, compare the output with the acceptance criteria. Record material corrections, source gaps, tool failures and exceptions. If the same correction repeats, move the fix upstream into source governance, validation or the maintained instruction.
The objective is not to make every interaction perfect. It is to make the recurring workflow steadily easier to run and easier to trust.
The Instruction-to-Workflow Gate
When the same task is performed repeatedly by several users, uses the same context, follows the same review pattern and produces the same handoff, stop treating it as merely a prompt. Promote it into a workflow with a trigger, maintained context, versioned instruction, validation, exception routing and closure.
That promotion is the core transition explored in the next article. A prompt tells Super Intelligence what to do once; a workflow tells the organisation how the work should move repeatedly.
The Final Instruction Rule
Better instructions remove hidden ambiguity before they add more language. If the model still has to guess what success means, which source to trust, what authority it has or how the result will be checked, the instruction is incomplete.
When those decisions are explicit, Super Intelligence can spend its capability on the actual work rather than on guessing the operating system around the work.
Instruction Quality Under Pressure
The true test of a workplace instruction is not whether it produces a good answer on a friendly example. It is whether the task remains understandable when information is incomplete, a deadline is tight, the receiver changes, a source conflicts or the system cannot use one of its tools. Good instructions preserve the invariant requirements under pressure.
This is why stop conditions, source precedence and authority boundaries deserve the same attention as style and output structure. They determine what happens when the workflow leaves the ideal path.
Instruction Quality Across Time
Recurring instructions should also survive time. A workflow that worked last month may receive a new policy, new source system, new model or new user role. The instruction remains strong only if these changes are visible and the task can be retested against the updated operating environment.
For this reason, the long-term quality of an instruction depends as much on maintenance as on the wording written on day one.
The Instruction Floor for Workplace SI
Before an instruction becomes a shared or automated workflow, it should make five things unmistakable: the intended outcome, the evidence allowed, the authority granted, the conditions that stop the task, and the method used to verify the result.
Outcome + Evidence + Authority + Stop Conditions + Verification is the minimum durable floor. Everything else can be adapted to the task.
The Instruction Reliability Margin
A shared instruction should not merely work when the model, source and user are all ideal. It should contain enough structural margin that ordinary variation does not break the task. That margin comes from explicit source authority, clear acceptance criteria, bounded tool use, visible exceptions and a receiver-friendly output contract.
When those elements are present, users can change, models can improve and case details can vary without forcing the organisation to rediscover the task from first principles.
This is the point at which prompting becomes operational design. The instruction is no longer clever wording for one interaction; it is a maintained specification for how intelligent work should be performed.
The Instruction Operational Test
Before a recurring instruction is considered production-ready, another trained user should be able to run it, understand why the output is acceptable, recognise when the system should stop and identify the authoritative evidence supporting the result. If success depends on the original prompt author standing beside the workflow, the instruction has not yet become organisational capability.
The final test is therefore transferability: can the work remain clear when the user changes? A durable instruction preserves purpose, evidence, limits and review even when the individual operator changes.