System and Developer Instructions

What it is

The standing text a product places in front of the model on every call, written by the people who build the product rather than by the person using it. It establishes who the assistant is acting as, what it is for, what it must decline, how it should format what it returns, and which operating constraints it works under. Two authorship tiers are usually present: the platform that hosts the model contributes a layer the application cannot edit, and the application contributes its own on top. This capability is about composing and maintaining that text; what happens when two clauses disagree is a separate concern.

Why it matters

Almost every behavioural property a team cares about — refusal boundaries, house style, the unit a number is reported in, whether an answer may guess — is carried by a few hundred words that no compiler checks and no type system constrains. That text is simultaneously the cheapest thing in the system to change and the most dangerous, because a single added clause applies to every request from the moment it ships and its effect is distributed across every other clause already present. Teams that treat it as copy rather than as the behavioural specification it is discover this during an incident.

Key decisions

• What belongs in standing text at all. A rule that applies to every request belongs here; a fact that applies to this request belongs in the request. The temptation is to move per-request material into the standing block because the standing block is easier to edit.
• Whether behaviour is expressed as a described role the model inhabits or as an enumerated list of rules it checks. Role descriptions generalise to situations nobody anticipated and are impossible to audit; rule lists audit cleanly and go silent the moment reality steps outside them.
• Whether constraints are stated positively or as prohibitions. A prohibition names the undesired behaviour in the context, which leaves the desired behaviour unspecified; a positive statement leaves the prohibition implicit.
• How much of the instruction surface is exposed to configuration. Shipping one block and letting tenants override a tone field is tractable; letting them supply arbitrary text makes every tenant a separate behavioural variant nobody has evaluated.
• Whether critical constraints are restated close to the end of the assembled context as well as at the front, and whether anyone has measured that the restatement helps for the models actually in use.
• Who owns the block and what review a change requires. Every clause was added by someone solving a real problem, which is why nothing is ever deleted unless deletion has an owner.

Failure modes

• The block grows by accretion. Each incident adds a sentence, nothing is ever removed, and after a year the instructions are three times longer than the task description they sit in front of and nobody can say which clause is load-bearing.
• Two clauses added nine months apart contradict each other. Neither author saw the other, the model resolves it differently depending on the rest of the context, and the behaviour reads as randomness.
• The text describes tools, data sources, or workflows that have since been removed, so the model offers capabilities the product no longer has and apologises when it cannot deliver.
• The same instructions are pasted into six call sites. Five get the fix and the sixth keeps the old behaviour, and the only symptom is that one surface behaves differently.
• A clause that was essential for one model family is carried forward to a replacement that interprets it differently — a formatting directive that used to be followed loosely is now obeyed exactly, and every answer acquires a heading structure nobody asked for.
• Tenant-specific exceptions are appended to the shared block, so the standing text becomes a configuration file written in prose and every tenant pays the token cost of every other tenant's exceptions.
• An instruction phrased as a prohibition names the exact behaviour to avoid, and the behaviour appears in outputs more often than it did before the clause was added.

Related capabilities

• Instruction Hierarchy — what happens when two of these clauses conflict
• Prompt Templates — the parameterised form this text is usually authored in
• Prompt Registry and Versioning — where a released version of this block lives
• Dynamic Prompt Assembly — places this block into a context alongside everything else
• Prompt A/B Testing — how a proposed wording change earns its way in

Applies: Production readiness · Design questions