# Write a standing instruction that works

An instruction that works names a situation, an action and a boundary, and is written at the narrowest tier that covers the situation. Instructions that fail are usually one of three kinds: a prohibition with no alternative, a request for care that really needs a gate, and a fact dressed up as a direction when it belongs in Knowledge.

- **Status:** Available
- **Audience:** both
- **In the app:** #/maya-rules, #/memory, #/knowledge
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/how-to/write-a-standing-instruction/

## The shape of one that works

A standing instruction is a durable direction, not a note to self. It is read every time work is done at the tier it lives on, so it competes for attention with everything else in force. Three properties make one carry.

**It names the situation** — "When somebody asks for a delivery date" is actionable in a way that "with delivery enquiries" is not, because the first one can be recognised.
**It names the action** — Say what to do, not what to avoid. "Give the despatch lead time and offer to confirm the date once the order is placed" beats "do not promise dates".
**It names the boundary** — "If they ask for a firm date, escalate rather than estimate" tells the model where the instruction stops, which is where most instructions quietly go wrong.

Length is not free. Everything given as instruction competes for room with everything else, and on a live phone call it competes for time as well: instructions of around 7,500 characters produced a first token in 1.2 to 1.8 seconds on measured calls, and around 9,600 characters pushed that to 2.3 to 3.4 seconds. A person's whole voice persona is kept under roughly 2,500 characters for the same reason. Written channels are less punishing, but the competition for attention is the same.

## Writing one

1. Find a real example of the behaviour you want changed — an actual reply, an actual call — rather than writing from memory of an impression.
   - Result: You have the situation in concrete terms, which is the hard part of the sentence.
2. Choose the tier. Workspace for a rule about the business, channel for one about a medium, endpoint for one mailbox or one number, contact for one person. The narrowest applicable tier wins.
   - Result: The instruction is in scope for exactly the work it should affect and invisible to the rest.
3. Write it in one or two sentences: situation, action, boundary. Cut the preamble — nothing is improved by explaining to the model why you care.
   - Result: It is short enough to survive alongside the others and specific enough to recognise its own situation.
4. Read what is already at that tier before saving, and remove anything the new instruction contradicts.
   - Result: You have one rule instead of two arguing. The memory viewer shows every tier for a person or channel, and shows an empty tier as empty rather than hiding it.
5. Make the situation happen and read the result — a regenerated draft, a test call and its review, a message from an outside account.
   - Result: That is the verification. The settings screen accepting your text proves that it was stored, which is not the same as it working.

## The three that usually do not work

| What people write | Why it fails | What to do instead |
|---|---|---|
| "Never mention competitors" | A prohibition with no alternative leaves nothing to do when the situation arrives, so the model improvises anyway | "If a competitor is raised, acknowledge it in one line and return to what we can do — do not compare features" |
| "Always check with me before sending anything important" | Importance is not a gate the model can enforce on itself; this is an autonomy decision written as a wish | Set `ask_before_send` at the scope that matches, and use the instruction only for what to say |
| "Our lead time is ten working days" | A fact stored as an instruction applies only where the instruction is in scope, and goes stale invisibly | Put it in Knowledge, where answers are grounded in it and it can be corrected in one place |

> **Careful** A fourth pattern deserves its own warning because it looks like it worked. Writing "never contact this person again" as the body of a note blocks nobody: the directive reader looks only at the tag list, never at the text. Use the block action, which stores a tagged directive against the contact and therefore holds across every channel and every future conversation.

## Keeping the set healthy

Instructions accumulate. The failure mode is not one bad rule; it is thirty adequate ones written over a year by different people, several of which contradict each other and none of which anyone will delete. Two habits prevent it: read the tier before adding to it, and delete rather than qualify — an instruction that needs an exception written beside it is usually the wrong instruction.

When behaviour surprises you, the decision log is faster than re-reading the set. It records what was decided, by what, under which rule, and what happened, including refusals — so the question "which instruction caused this" has an answer rather than a theory.

## Questions

### Where do standing instructions live?

Behaviour text belongs on the Connect Rules screen for workspace-wide direction; narrower directions live as memory rows at the channel, endpoint or contact tier. The tier is the part that decides reach, and it is the part most often chosen by accident.

### Can an instruction override a compliance rule?

No, and this is deliberate. Suppression and do-not-contact are checked before any outreach regardless of instruction, and Connect will not improvise a price, an SLA or a warranty that Knowledge does not support however the instruction is phrased.

### How many instructions are too many?

There is no published limit, but there is a real cost: everything in force competes for room, and on the phone it competes for time before the first word. Prefer a small set that is read and maintained to a large set nobody audits.

### Do instructions apply retroactively?

No. A draft written before the instruction is not rewritten by it — regenerate rather than re-reading, or you are judging the old rule.

## Related

- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)
- [Knowledge in Connect](https://connectbyjbrh.com/docs/knowledge/)
- [Correct something Connect got wrong](https://connectbyjbrh.com/docs/how-to/correct-a-mistake/)
- [Change how Connect writes](https://connectbyjbrh.com/docs/how-to/change-what-connect-says/)
- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [What every character of a prompt costs on a live call](https://connectbyjbrh.com/research/prompt-size-and-first-token/)

## What this page is based on

- docs-source/sources/GENERAL.md §6 — memory tiers, directives and the viewer
- docs-source/facts.py `MEASURED` — instruction size against first-token time
- docs-source/sources/PHONE.md §6 — behaviour and style blocks on the voice path
- docs-source/sources/CHANNELS.md §6 — commercial terms are refused, not improvised