# The drop-in > Setting up the method in a new project means applying a template to one file of project details, not rebuilding the rules in a conversation. Page: Methodology · Start Canonical: https://banes-lab.com/disciplined-methodology#onboarding This section is stop 11 of 102 in the learning route. Previous: [10 - The behaviour document](https://banes-lab.com/disciplined-methodology/start/the-behaviour-document.md). Next: [01 - What PAG is](https://banes-lab.com/pag/introduction/what-is-pag.md). It builds on [06 - Three encodings](https://banes-lab.com/disciplined-methodology/start/three-encodings.md). Setting up the method in a new project means applying a template to one file of project details, not rebuilding the rules in a conversation. The whole governance set is a folder that names no project, plus one file that does, as shown in [K1·a a drop-in](https://banes-lab.com/disciplined-methodology#onboarding-panel-a). Adopting it means copying the folder and writing that one file, the binding shown in [K1·c a binding](https://banes-lab.com/disciplined-methodology#onboarding-panel-c), in which every fact about the host project is a slot in one of the three states shown in [K1·b slot states](https://banes-lab.com/disciplined-methodology#onboarding-panel-b). The gate is then green on an empty tree before the first line of code exists. All of this rests on one separation: the thinking is kept apart from the tools, which applies [platform independence](https://banes-lab.com/records/arch/platform-independence.md) to a method and [configuration externalization](https://banes-lab.com/records/arch/configuration-externalization.md) to its facts. The folder is generated from the [template families](https://banes-lab.com/pag/templates/templates-families.md) the grammar page publishes. ### A template applied to a binding A method written in one project's vocabulary does not carry over to the next project. Every new project starts with a long conversation that rebuilds rules which already exist somewhere else, and rebuilds them slightly wrong. A core document that names a path is tied to the project that has that path, so the next project has to edit the core. For this reason the core documents name no project, a single adapter binds them to one, and every missing piece is declared rather than patched over. The method moves to a new project by rewriting one adapter, rather than by editing the core documents. In practice, the reasoning stays in core documents that name no project, and the bindings stay in one adapter that fills every slot the cores leave open. A slot that nothing can fill is declared absent in the adapter, rather than left for a core to assume, and the part of the method that depends on it does not run. The set is proven on an empty tree first: a gate that is red before any code exists is reporting a problem with the binding, and a gate that is green there becomes the baseline every later failure is measured against. To check this, apply the set to an empty project. A red gate there points to a binding the adapter did not make. A green gate proves the binding and nothing more, because a check over an empty tree measures nothing. A catalogue inside a core document, such as a list of principles, patterns or examples, may assume things this project does not have. The mechanism carries over unchanged, and the catalogue is worked out again against what exists here. Replacing the mechanism would be the mistake; working out the catalogue again is the work. ### Cores, one adapter, three slot states A core is a document that says what to do in terms of [semantic operations](https://banes-lab.com/pag/guide/tool-invocation.md) and slots, the same shape [the behaviour document](https://banes-lab.com/disciplined-methodology/start/the-behaviour-document.md) has. It never names the tool that searches or the folder that holds the tests, because as soon as it does, it is tied to one project and the next project has to edit it. The adapter is the one file where those names live, and it is the only file rewritten when the set moves to another project. A slot is always in one of three states, and the third is the one that matters most. Resolved means this project has the thing, and its value is in the adapter. Absent means this project has nothing that corresponds to it, so the part of the method that depends on it does not run, and that is declared rather than faked. Deferred means the thing will exist but does not yet, so the dependent part is blocked rather than skipped, which answers a different question in the right way. An adapter in which every slot is resolved is hiding something. The checks this project does not have, such as a computed measure of worth, a detector for work that stops making progress and a calibrated confidence, are declared absent in the adapter so that nothing assumes them; [the honest gaps](https://banes-lab.com/disciplined-methodology/ship/the-honest-gaps.md) lists them, and the architecture page arrives at [the same declared absences](https://banes-lab.com/software-architecture/coverage/the-honest-gaps.md) because an architecture is its predicate set. ### The generator removes itself The template that generates the set keeps the mechanism and rewrites the content. A fact that would be wrong in the next project is turned into a slot. A statement written for one domain that holds for the whole kind is generalised to the kind. A mechanism that must know nothing about what it governs is made project-neutral. The generator then fills in the one binding and checks it in both directions, that every slot the cores name is bound and that every binding names a slot. It installs the set, runs the gate, and removes itself before the gate approves the tree. A generated project is therefore green when it arrives, with no edits by hand, and that is why every manual step in setting up a project counts as a [manual runbook dependency](https://banes-lab.com/records/arch/manual-runbook-dependency.md) rather than a chore. The checks read their contracts from the same templates the surfaces are created from, so there is a [single source of truth](https://banes-lab.com/records/arch/single-source-of-truth.md) that the check reads while it runs. A check that copied a schema into itself would hold a second copy with nothing keeping the two the same, and the drift would only show when the developer or the model created a new surface and it failed on its first run, wrong from the start because it followed a template that looked authoritative. ### The binding as a module The binding is a typed module rather than a written page, and its readable version is generated from the module, so the two cannot disagree, which is what [self-describing architecture](https://banes-lab.com/records/arch/self-describing-architecture.md) means for a binding. A slot is one record with three fields: a state from a fixed set, a value that is empty unless the state is resolved, and a note explaining why. A reader therefore sees the reason next to the value, and a mechanism sees the state before the value. The three constructors are the only way to create a slot, which is what stops a resolved slot from having no value and an absent slot from carrying an old one. Slots are grouped by who supplies them: what the host project supplies, what the package owns, the conventions, the limits and the commands that run things. A count of slots in each state is worked out when the page is rendered, so it cannot disagree with the table above it, and a binding whose count shows every slot resolved is the one to distrust. K1·a a drop-in ```mermaid flowchart TB subgraph governance["The governance folder · copied whole, never edited for a feature"] policy["The behaviour policy · named rules given to the model first"] checks["The checks · one file per rule, each proven to fire"] cores["The cores · reasoning that names no project"] binding["The binding · the one file that names this tree"] end code["The code · shaped by the grammar the checks parse"] command["The one command · every check, fixer, generator and validator"] binding -. resolves every slot the cores name .-> cores checks -. parse .-> code command --> checks policy -. governs .-> code ``` K1·b slot states ```mermaid flowchart LR core["A core names a slot"] binding{"What does the binding say?"} resolved["Resolved · the branch runs against this tree's value"] absent["Absent · the branch does not run, and says so"] deferred["Deferred · the branch is blocked until the value exists"] faked["Nothing declared · the branch runs against a guess"] core --> binding binding -- a value --> resolved binding -- declared absent --> absent binding -- declared deferred --> deferred binding -. no declaration .-> faked ``` K1·c a binding ```typescript export type SlotState = "RESOLVED" | "ABSENT" | "DEFERRED"; export type SlotValue = string | number | readonly string[] | null; export interface Slot { readonly state: SlotState; readonly value: SlotValue; readonly note: string; } export const resolved = (value: Exclude, note: string): Slot => ({ state: "RESOLVED", value, note }); export const absent = (note: string): Slot => ({ state: "ABSENT", value: null, note }); export const deferred = (note: string): Slot => ({ state: "DEFERRED", value: null, note }); export interface Binding { readonly project: Readonly>; readonly surface: Readonly>; readonly convention: Readonly>; readonly limits: Readonly>; readonly execution: Readonly>; } export const binding: Binding = { project: { root: resolved("", "the host root relative to this package, the one value an adopter sets"), policy_projection: absent("the host has not adopted the package, so no projection is written into its document"), rollback_point: deferred("a reversible checkpoint will exist once the host is under version control"), }, surface: { board: resolved("", "the coordination board") }, convention: { nesting_cap: resolved("", "the placement depth cap from a governed root") }, limits: { file_cap: absent("no per-file cap; a host that wants one holds it in its own linter") }, execution: { compile: absent("nothing here compiles") }, }; ``` ## Links to - [Platform Independence](https://banes-lab.com/records/arch/platform-independence.md) - [Configuration Externalization](https://banes-lab.com/records/arch/configuration-externalization.md) - [Template families](https://banes-lab.com/pag/templates/templates-families.md) - [Semantic operations](https://banes-lab.com/pag/guide/tool-invocation.md) - [The behaviour document](https://banes-lab.com/disciplined-methodology/start/the-behaviour-document.md) - [The honest gaps](https://banes-lab.com/disciplined-methodology/ship/the-honest-gaps.md) - [The honest gaps](https://banes-lab.com/software-architecture/coverage/the-honest-gaps.md) - [Manual Runbook Dependency](https://banes-lab.com/records/arch/manual-runbook-dependency.md) - [Single Source of Truth](https://banes-lab.com/records/arch/single-source-of-truth.md) - [Self-Describing Architecture](https://banes-lab.com/records/arch/self-describing-architecture.md) ## Linked from - [Core templates](https://banes-lab.com/pag/templates/templates-core.md) - [Three encodings](https://banes-lab.com/disciplined-methodology/start/three-encodings.md) - [Execute the template](https://banes-lab.com/disciplined-methodology/plan/execute-the-template.md) - [Agents as executed contracts](https://banes-lab.com/disciplined-methodology/collaborate/agents-as-executed-contracts.md) - [The board and the venue](https://banes-lab.com/disciplined-methodology/collaborate/the-board-and-the-venue.md)