Bane's Lab

Bane's Lab

Structured collaboration with LLMs

Bane's Lab documents the method I use to build software with LLMs, together with the instruction format, the software architecture and the ontology that the method relies on. I have used it since 2024, on every project I build, this site included. The method does not make a model's output correct. What it does is make incorrect output visible and refuse it, through checks that run on every change rather than through instructions the model is asked to remember.

Start with the methodRead the grammarEvery page as JSON and Markdown

How the site teaches

The site is organized around the methodology, which is one page of six tabs read in order, from Start to Ship. The grammar, architecture and ontology pages supply material that particular sections of the methodology rely on, and the visualization shows where each of their sections enters that order. The anatomy page works in the other direction: it shows the source of this site, and its sections link back to the chapters that describe it.

Start01 - The loop02 - Who does what03 - The stance04 - Adversarial bydefault05 - Resolving a message06 - Three encodings07 - Where a rule lives08 - Rules with names09 - A seat is a contract10 - The behavior document11 - The drop-inIntroduction12 - What PAG is13 - Why it works14 - PAG and the methodGuide15 - Writing a firstdocument16 - Document structure17 - Semantic operations18 - Node design19 - Writing constraints20 - Well-formednessPlan21 - Worth before work22 - The plan is a graph23 - Execute the template24 - Ask where it appears25 - When rules collidePatterns26 - Instruction patterns27 - From intent tostructure28 - Genesis stages29 - Algorithm examples30 - IntegratingalgorithmsBuild31 - Detect, log, fix32 - The gate holds theline33 - The check comes first34 - A check matches ashape35 - Tools live in thetree36 - One home37 - The filesystem is thearchitecture38 - Fail at the boundary39 - Placement is agrammarVerify40 - It looked right41 - Verify the verifier42 - A report, not acheckbox43 - Unknown is not pass44 - One correct answer45 - Derived state46 - Counting copies47 - Documentation is code48 - Moves and renames49 - Coverage is derivedValidation50 - Validation gates51 - LimitsModel52 - A system is a graph53 - Definitions own what,code owns how54 - The layer spine55 - The direction axisPrinciples56 - Principles are typed57 - Every record has akind58 - The canon is groupedtwice59 - Computation andresource60 - Execution joins thehalves61 - The structural domain62 - A tension has amechanism63 - Separate, trade, ormitigateDecay64 - An anti-pattern is adecay path65 - Seven controls, sevenclasses66 - Never and always67 - Debt and leverageCoverage68 - From intent topredicate69 - What can drift, seenthrough how it drifts70 - A cell that resistsan invariant71 - The honest gapsGlossary72 - The principlearchitecture73 - Architectural rulesand principlesCollaborate74 - The developer and themodel75 - Agents as executedcontracts76 - Coordination issoftware77 - The board and thevenue78 - Posting and waitingare one operation79 - A turn never ends towait80 - Stating an invariantOrchestration81 - Orchestration asdeclared structure82 - Composing acollaboration83 - Shared surfaces84 - Phase binding85 - Handoff signals86 - OrchestrationinvariantsTemplates87 - Core templates88 - Coordinationtemplates89 - Planning templates90 - Template families91 - Agent templatesShip92 - One chain93 - Scale follows fromstructure94 - The deploy is a fileoperation95 - Proxies give way96 - The honest gapsScale97 - A concern is acomponent98 - The ceiling moves bycost99 - Above one tier,reduction100 - The author isprobabilistic101 - Scale followsdeterminism102 - Systems built arounda model
0rules enforced on every change
0steps in one verification run
0architecture principles
0defined terms

MethodologyDisciplined Methodology

The method itself comes in six parts that follow the order of the work, from starting a project to shipping it. Each section describes one practice, how it fails when it is missing, and a test you can run against your own work to check it.

Read the method

PAGPattern Abstract Grammar

Pattern Abstract Grammar is a structured format for writing instructions to a model. A document declares what type of instruction it is, draws its verbs from a closed vocabulary and ends every step on a gate with checkable evidence. The page covers the grammar, its validation rules and a set of templates.

Read the grammar

ArchitecturePrinciples, decay and coverage

The page covers software architecture for systems in which a model writes much of the code. It models a system as a graph, holds each principle as a typed record, traces each anti-pattern back to the control whose absence caused it, and derives coverage from a grid rather than from a count.

Read the architecture

OntologyPrinciples, lexicon and algorithms

The ontology is the data behind the architecture page, and the site's own checks read it too. It holds every principle with its relations and repairs, every defined term, every algorithm contract, and how each tension between two principles is resolved.

Open the ontology

AnatomySource trees, walks and definitions

The anatomy page shows the source of every part of this site, from the client to the gate that checks it, parsed on every build. Each file is shown with its syntax walk, its definitions and the calls between them, together with the diagnoses the parser ran over every tree.

Open the anatomy

FAQOrigin, practice and limits

Here I answer the questions I am asked most often about the methodology, including where it came from and where it stops being useful.

Read the FAQ