# The behaviour document > The behaviour policy is the system prompt of the collaboration, whatever file name the harness uses for it. Page: Methodology · Start Canonical: https://banes-lab.com/disciplined-methodology#the-behaviour-document This section is stop 10 of 102 in the learning route. Previous: [09 - A seat is a contract](https://banes-lab.com/disciplined-methodology/start/a-seat-is-a-contract.md). Next: [11 - The drop-in](https://banes-lab.com/disciplined-methodology/start/onboarding.md). It builds on [06 - Three encodings](https://banes-lab.com/disciplined-methodology/start/three-encodings.md), [08 - Rules with names](https://banes-lab.com/disciplined-methodology/start/rules-with-names.md). The behaviour policy is the system prompt of the collaboration, whatever file name the harness uses for it. It is the one document delivered to every session at startup, so it carries what has to be in force before the model knows what task it is on, and it points to everything else. The order of its parts is shown in [J1·a a behaviour document](https://banes-lab.com/disciplined-methodology#the-behaviour-document-panel-a) and [J1·b delivery order](https://banes-lab.com/disciplined-methodology#the-behaviour-document-panel-b). It is written the same way for any harness and any model, because nothing in it names a tool: it names operations and slots, and a single binding says which tool performs each one, which applies [platform independence](https://banes-lab.com/records/arch/platform-independence.md) to a prompt, as shown in [J1·c one binding per harness](https://banes-lab.com/disciplined-methodology#the-behaviour-document-panel-c). What each kind of reader receives is shown in [J1·d reader classes](https://banes-lab.com/disciplined-methodology#the-behaviour-document-panel-d). The document is the behavioural form among the [three encodings](https://banes-lab.com/disciplined-methodology/start/three-encodings.md), and [document structure](https://banes-lab.com/pag/guide/document-structure.md) on the grammar page applies the same rule to a single document: declare first, then instruct. ### A system prompt with a composition A prompt written as one long instruction document is delivered once at startup to a model that will lose track of most of it, and nothing in its shape says which parts matter most. The document grows by appending, every session opens on a wall of prose, the first rules get attention and the last ones barely any, and the same correction is added a fourth time at the bottom. A document delivered in one piece has no structure that marks what must be in force from the start and what can be looked up later, so every line competes for the same attention and the order is simply the order it was written in. For this reason I give the behaviour document a deliberate composition: what must be in force from the start comes first, the delivery order follows the order of precedence, and anything that only matters once the task is known is referred to rather than included. The document is arranged by precedence and kept free of anything specific to one harness, rather than grown in the order rules happened to arrive. In practice, it opens with [the stance](https://banes-lab.com/disciplined-methodology/start/the-stance.md) and the hard prohibitions, because those apply before the task is known. Next comes what to read first and in which order, then the rules that apply every turn, then the ones that apply to particular tasks, then the declared exceptions. How the work is verified, how the tree is inspected and what the tree contains come after the rules, because each of them assumes a task. Anything that needs more room is moved into a digest the document points to. No tool is named anywhere: the document names the operation, and the binding decides which tool performs it. To check this, rename the file to what another harness expects and give it to a different model. Where it breaks, a tool name or a path has leaked into a place that should hold a slot; where it holds, the composition has transferred. The document is delivered once to each reader, so a change to it does not reach a session that is already running. A rule edited mid-session reaches only the parties that start afterwards, which is why a governing change is also sent as a message to the parties already running, since messages reach them every round and the file does not. ### Resident, then referenced One question decides where a part of the document goes. If it tells the model how to find out what it is doing, it belongs at the top, in the order it applies. If it tells the model what to do once it knows, it goes further down or into a digest the top points to. How often a rule applies is a poor guide: a rule that applies every hour but assumes a known task can safely be referred to, while a rule that applies once a month but decides which document to open belongs at the top. ### The document is a claim The document is a claim like any other, and the stance applies to it: the model is asked to re-read it whenever it enters the context, because a version held in memory is only a memory, and it gives way to the tree in the order three encodings sets out. It states what is true now and never what used to be, as [derived state](https://banes-lab.com/disciplined-methodology/verify/derived-state.md) requires of every document. Copying a sentence from one document into another is how a dead reference spreads, so each fact has a [single source of truth](https://banes-lab.com/records/arch/single-source-of-truth.md) and the other documents point to it, which [documentation is code](https://banes-lab.com/disciplined-methodology/verify/documentation-is-code.md) turns into a check. The whole set of documents is validated, each kind against its declared shape, and a document that does not match its shape fails before it is delivered. ### Operations and slots [Portability](https://banes-lab.com/records/arch/portability.md) follows from what the document is allowed to say. It states what to do as [semantic operations](https://banes-lab.com/pag/guide/tool-invocation.md), such as discovering resources, reading a resource, searching content, analysing, running a tool, saving an artifact and reporting a result, the same rule stated under semantic operations on the grammar page. It states where things are as slots, such as the gate, the rule host, the test root and the depth cap. One binding per harness maps each operation to that harness's tool and each slot to that tree's value, which is [configuration externalization](https://banes-lab.com/records/arch/configuration-externalization.md) applied to a prompt. Moving the document to a harness that expects a different file name therefore takes a rename and one binding, and the rules do not change. The model is deliberately left as an empty slot, because choosing the model belongs to the harness, and a value written into that slot would have no source. A set of rules meant for use in other projects is written as a block that a host project copies into its own document, rather than merging it. Where the host's rule and the block's rule collide on the same thing, the host's rule wins, and the collision is treated as a finding rather than a negotiation. Every path in the block is relative to one value the adopting project sets, and the only literal path that remains is the import a runtime resolves, because a runtime reading a path has no binding to consult. ### Who receives it Who receives the document decides which of its rules apply, and the document states which kind of reader each rule applies to, rather than leaving the reader to decide; [coordination is software](https://banes-lab.com/disciplined-methodology/collaborate/coordination-is-software.md) explains where the two kinds of reader come from. The single line a bounded reader receives is updated in the same change as the fact it carries and kept under a size limit, because a summary that keeps growing under an update rule with no stated limit turns into the document's own clutter. ### How it grows The document grows only in the shape [rules with names](https://banes-lab.com/disciplined-methodology/start/rules-with-names.md) describes, and when a rule has had to be stated twice for the same kind of problem, it becomes a check that the line points to. The document repeats nothing the codebase contract owns, and the contract repeats nothing the document owns; a reader who finds the same fact in both has found a copy that neither the developer nor the model maintains. J1·a a behaviour document ```markdown # A claim about the tree is unverified until the tree is read. Review is adversarial by default. Every manual step is a failure of automation. A document states what is true now. # The behaviour policy governs the agent. The codebase contract governs the code. A digest expands one rule and declares nothing. The tree outranks all of them, and a document that disagrees with the tree is corrected the same turn. # A blocker outranks everything and is read first. Then the board, whole. Then the seat's own role. Then the document whose domain the task enters. # - `read_before_claim`: a claim about a file is a lie until the file is read in this session · gate: conduct # - `rename_by_hand`: a move is done by hand, every reference enumerated before and verified after · gate: reference # - `question_is_blocked`: a pending question is a blocked state, never a third verdict # One command runs every stage in order. It runs once per state, and its first output is read whole. # : what it holds and what authority it carries, one line each. ``` J1·b delivery order ```mermaid flowchart TB subgraph resident["Resident · in force before the task is known"] axiom["The axiom · the stance, the readings, the hard prohibitions"] set["The document set · what governs what, and the precedence"] startup["Startup · what is read first, and in which order"] always["Rules that bite every turn"] end subgraph referenced["Referenced · presupposes a known task"] situational["Rules that fire on a matching task"] exceptions["Declared exceptions"] verify["How the work is verified · one chain"] tooling["How the tree is looked at"] notes["What the tree is"] digests["Digests · one concern each, expanding a rule"] end test{"Does it tell you how to find out what you are doing?"} test -- yes --> resident test -- no --> referenced axiom --> set --> startup --> always situational --> exceptions --> verify --> tooling --> notes resident -- delivery order --> referenced situational -. needs room .-> digests ``` J1·c one binding per harness ```mermaid flowchart TB policy["The behaviour document"] operations["Semantic operations · discover, read, search, analyse, execute, persist, report"] slots["Slots · the gate, the rule host, the test root, the depth cap"] binding["One binding per harness"] toolsA["Harness A · its tools, its file name"] toolsB["Harness B · its tools, its file name"] model["The model · an absent slot by construction"] policy --> operations --> binding policy --> slots --> binding binding --> toolsA binding --> toolsB policy -. names nothing about .-> model ``` J1·d reader classes ```mermaid flowchart TB doc["The behaviour document · delivered once, at startup"] seat["A seat"] bounded["A bounded invocation"] board["The board · delivered whole every round"] line["One projection line · the only board it ever sees"] invert["Turn-owning rules invert · returning is its contract"] routed["A change to the document is routed to the running parties"] doc --> seat --> board doc --> bounded --> line bounded --> invert doc -. an edit mid-session does not reach running parties .-> routed ``` ## Links to - [Platform Independence](https://banes-lab.com/records/arch/platform-independence.md) - [Three encodings](https://banes-lab.com/disciplined-methodology/start/three-encodings.md) - [Document structure](https://banes-lab.com/pag/guide/document-structure.md) - [The stance](https://banes-lab.com/disciplined-methodology/start/the-stance.md) - [Derived state](https://banes-lab.com/disciplined-methodology/verify/derived-state.md) - [Single Source of Truth](https://banes-lab.com/records/arch/single-source-of-truth.md) - [Documentation is code](https://banes-lab.com/disciplined-methodology/verify/documentation-is-code.md) - [Portability](https://banes-lab.com/records/arch/portability.md) - [Semantic operations](https://banes-lab.com/pag/guide/tool-invocation.md) - [Configuration Externalization](https://banes-lab.com/records/arch/configuration-externalization.md) - [Coordination is software](https://banes-lab.com/disciplined-methodology/collaborate/coordination-is-software.md) - [Rules with names](https://banes-lab.com/disciplined-methodology/start/rules-with-names.md) ## Linked from - [The drop-in](https://banes-lab.com/disciplined-methodology/start/onboarding.md)