Office analogy: company policy
Think about how a serious practice works.
When a new engineer joins, you do not paste the quality manual at the foot of every email. Policy lives at company level: how files are named, which units you use, what must not be invented if a datum is missing, when to escalate to the senior, what can go out as a draft and what needs a signature. Those policies persist. They are there whether today’s request is a frame or tomorrow’s is a takeoff.
The system prompt — or the client’s instructions / rules — is exactly that: policy for how problems should be solved with that assistant. It defines the role, the limits, and the way of working. It is not the day’s work. It is the frame.
If every morning you have to rewrite the policy in the body of the email because “otherwise the junior forgets,” you do not have company policy: you have a fragile reminder. The same thing happens when you paste the rules next to the frame in every chat.
This note is part of the series on the AI harness for civil engineering. Here we are on H-01 Instructions and policies. It complements, it does not replace, prompt engineering or the LLM’s role.
What a system prompt actually is
The system prompt — or the client’s persistent instructions — is the highest-priority set of rules that steer the model’s behaviour during the session or the task: its role, scope, units, available tools, and the situations in which it must ask for help or stop.
It is not the request about the frame. It is not the file. It is not the tool — the action plugged into a program. It is not the signature.
In the industry people talk about product system prompts (for example what Anthropic documents about system instructions) and about the distinction between instructions and input (as in OpenAI’s guides): the persistent layer versus the concrete request. In Cursor they show up as rules. In Claude Desktop, as project instructions. The name changes; the office tension is the same.
Pasting rules in every message versus company-level policy
Office illustration — a desktop demo, not a client case.
Version A. You paste the rules next to the frame in every message. By the third question the history has grown, the model has compacted context, and your rules are mixed with numbers, assumptions, and jokes from the conversation. The chat “forgot” what was never fixed at policy level.
Version B. The same eight lines live as the client’s persistent instructions — as company policy. The request about the frame comes in clean. The rules are still there when you change the question. Not because the model became an engineer: because the harness re-injects them.
That is the difference that matters in AEC. It is not magic. It is where the contract lives.
What belongs there, and what does not
Goes in system / instructions (policy)
- A concrete role: “structural review assistant in the office; you do not issue a signed verification.”
- Units and conventions: kN, m, degrees, rounding rule.
- What is forbidden to invent: IDs, loads, engine results, code clauses.
- When it must stop and ask: missing file, ambiguous version, downed tool.
- Which tools exist and what they are for (if the harness exposes them).
Goes in the request (user)
- Today’s frame, the level, the file, the concrete question.
- Project data that change with every task.
- The deliverable you need now.
Goes in a tool / engine
- Open the model, read parameters, run OpenSees or CalculiX, validate schemas.
- Any number that claims to be an engineering result.
If you put the calculation in the system prompt, you are asking for poetry in uniform. If you put the rules only in the user message, you are betting that the conversation will not dilute them.
Harness piece H-01 — instructions and policies
In what an AI harness is, the harness is the frame the model works inside: tools, instructions, checks, and your signature. The system prompt is one piece of that frame — H-01: instructions / policies. It is not the whole workshop.
Three limits that stop self-deception:
- A system prompt does not execute. It can say “use the Revit tool,” but without a real plug (for example MCP or another hand) it opens nothing.
- A system prompt is not project memory. It does not remember last week’s RFI unless the harness loads it.
- A system prompt does not sign. “Act as a senior engineer” does not transfer a license or responsibility.
That is why the harness sentence remains the compass: the model reasons and proposes; the harness connects, executes, verifies, and constrains; the professional decides and signs. The system prompt helps the reasoning respect policy. It does not replace tools, engines, or a signature.
Conclusion
You pasted the rules and by the third turn you no longer had them. That scene is not a meme: it is the symptom of confusing a message with company policy.
The chat does not become an engineer because of a paragraph. The system prompt is the harness’s persistent instruction: role, limits, and way of working. Write it, audit it, and take it out of the request. The calculation and the signature remain something else.
For the full frame around the model, read what an AI harness is. For the day’s request, continue with prompt engineering. For why two runs can differ, the LLM’s role.
Sources
- Anthropic — documentation on system prompts (system instructions versus user input; see the official platform docs).
- OpenAI — Prompt engineering: the distinction between instructions and input (see the official prompt-engineering guide).
Evaluation and limitations
Treat the notes below as evaluation context, not as a verified calculation or code check.
Review the system prompt together with tools and approvals. The policy text is H-01; it is not the whole system.