The Spine: Stable Rules and Tool Schemas

The spine carries the work

A long-running prompt has three structural zones: spine (stable), body (selective), and tail (live). The spine is everything that should not change between turns: system rules, tool schemas, reusable examples, role definition. It belongs at the top, in the system prompt or the first user message, and it should be byte-identical across requests so caching can hit it.

Spine stability has compound benefits

Cache hit rate goes up. Attention sink behavior favors the rules. Diff review across requests becomes trivial. The model's behavior becomes predictable because its operating context is predictable. None of this happens if you regenerate the system prompt with timestamps or live state every turn.

Versioning the spine

Treat the spine like code: give it a version label, change-log it, and bump the version explicitly when rules change. Telemetry should record the spine version per request. When behavior shifts, you want to know whether it was the model, the input, or the rules.

Code

Spine layout·markdown

<!-- SPINE v3 -->
# Role
You are an AI assistant for project X.

# Rules (do not modify between turns)
- Always validate before commit.
- Never push without human confirmation.

# Tool schemas
- search(query: string) -> list[doc]
- read(path: string) -> string
- write(path: string, content: string) -> void

# Reusable examples
... (stable few-shots) ...

Per-request telemetry·json

{
  "spine_version": "rules-v3",
  "tool_schema_version": "tools-v2",
  "cached_input_tokens": 28401,
  "fresh_input_tokens": 1230
}

The Spine: Stable Rules and Tool Schemas

The spine carries the work

Spine stability has compound benefits

Versioning the spine

Code

External links

Exercise

Progress

Comments 0