# What PAG is

> Pattern Abstract Grammar (PAG) is a structured format for writing the instructions a model is asked to follow.

Page: PAG · Introduction
Canonical: https://banes-lab.com/pag#what-is-pag

This section is stop 12 of 102 in the learning route. Previous: [11 - The drop-in](https://banes-lab.com/disciplined-methodology/start/onboarding.md). Next: [02 - Why it works](https://banes-lab.com/pag/introduction/why-pag-works.md). It builds on [01 - The loop](https://banes-lab.com/disciplined-methodology/start/the-loop.md).

Pattern Abstract Grammar (PAG) is a structured format for writing the instructions a model is asked to follow. A PAG document declares what kind of instruction it is and what it may touch, and it draws every operative word from a [closed vocabulary](https://banes-lab.com/records/arch/closed-vocabulary.md) of uppercase tokens grounded in a reasoning ontology. The work is grouped into nodes; each node reads the previous node's output and closes on a gate of checkable conditions, each with its evidence and the population it covers. The document states its boundaries as invariant records and ends with a report, and [A1·a minimal document](https://banes-lab.com/pag#what-is-pag-panel-a) shows all of these parts together. Each part is one stage of a reasoning loop written down, as listed in [A1·b construct to stage](https://banes-lab.com/pag#what-is-pag-panel-b), so the document makes [the loop](https://banes-lab.com/disciplined-methodology/start/the-loop.md) legible. [A1·c prose or directive](https://banes-lab.com/pag#what-is-pag-panel-c) shows where variance enters without the grammar, and [A1·d scan, loop, binding](https://banes-lab.com/pag#what-is-pag-panel-d) shows what walks a document. What the tokens gain is described in [why it works](https://banes-lab.com/pag/introduction/why-pag-works.md), and what the grammar never reaches is described under [limits](https://banes-lab.com/pag/validation/limitations.md).

### A contract, not a request

An instruction written as prose leaves its terms to the model that reads it. The same request run twice produces two plausible results, and neither you nor the model can say which sentence was read differently. An [implicit contract](https://banes-lab.com/records/arch/implicit-contract.md) leaves the model to supply the terms, and it supplies them from the completion, so they vary with it.

For this reason I write an instruction as an [explicit contract](https://banes-lab.com/records/arch/explicit-contracts.md) rather than as a request in prose. The instruction gets a type rather than sharper prose: a declared type, tokens from a closed set and gates with checkable exits, rather than a longer or more careful sentence. In practice, an instruction is written as a PAG document when a reasoning loop will walk it. The document declares its type, states a checkable objective, divides the work into nodes with contracts, closes each node on three to five checks that can be settled with evidence, and bounds the whole with invariants.

To check this, hand the same document to the model twice and compare both outputs against the gates. Where both runs pass every gate, the structure held; where one fails, the failing gate points to the sentence that was still prose. A prompt that asks one question in passing gains nothing from a node structure. The grammar earns its cost where the document will be walked more than once, read by more than one party, or trusted to have done what it says.

A document has no runtime. What walks it is a reasoning loop, the one the methodology page teaches, and every construct of the grammar makes one of that loop's stages explicit. The document type names which reasoning model walks the document and on which axis of the loop it sits, and an adapter outside the document maps each [semantic operation](https://banes-lab.com/pag/guide/tool-invocation.md) to the tool that performs it.

Two kinds of check apply to a document. A scan checks its shape; that is [static analysis](https://banes-lab.com/records/arch/static-analysis.md), deterministic and cheap, and it is what makes the grammar parsable. The loop checks its meaning, and that check is not deterministic, because the loop is walked by a model.

A1·a minimal document

```pag
---
name: <document-name>
type: TASK
version: 1.0.0
---

THIS TASK EXECUTES <what the document is for, in one sentence>

%% META %%:
objective: "<what finished looks like, checkable against the tree>"
jurisdiction: <source> | external: everything else
recursion_limit: <a bound on repair>

# NODE 1 — <the first bounded decision>   [epistemic · analysis · logic · yields: boolean]
@genesis: existence
CONTRACT:
input:     <source>
transform: READ_RESOURCE <source> INTO <held>; VALIDATE_ARTIFACT <held> AGAINST <schema>
output:    <held>, validated
HANDOFF GATE:
[check] <held> read from <source> (evidence: the read returned content)
[check] <held> conforms to <schema> (evidence: the validator's report) over: <held> records measured: <conforming> / <records>
[check] every <held>.<record> carries the fields NODE 2 reads (evidence: no record with a missing field)
result: pass → NODE 2 | unread or nonconforming → REPAIR (owner: NODE 1) | unknown → BLOCKED

# NODE 2 — <the decision that consumes the first>   [epistemic · reasoning · set-theory · yields: set]
@genesis: difference
CONTRACT:
input:     <held> from NODE 1
transform: FOR EACH <item> IN <held>.<collection>: ANALYZE_CONTENT <item> AGAINST <criterion> INTO <finding>; IF <finding>.<met>: APPEND <item> TO <result>
output:    <result>
HANDOFF GATE:
[check] every <item> analyzed (evidence: one finding per item) over: <held>.<collection> measured: <analyzed> / <items>
[check] <result> holds every <item> that met <criterion> (evidence: the two counts match)
[check] no <item> outside <held> appears in <result> (evidence: every result item present in <held>)
result: pass → TERMINATE | count mismatch → REPAIR (owner: NODE 1) | unknown → BLOCKED

# CROSS-NODE INVARIANTS
INVARIANT validate-before-persist: <held> is validated before anything is persisted over: every node binds: the reader objector: [check] <held> conforms to <schema> at NODE 1
INVARIANT source-untouched: <source> is never modified in place over: <source> binds: the reader objector: none

REPORT:
subject: NODE 2
verdict: pass | fail | unknown
domain: declared <items> measured <analyzed>
completion: saturated <bool> complete <bool> verified <bool>
```

A1·b construct to stage

```pag
# each construct of a document is one stage of the reasoning loop, written down
declaration          orient      what kind of instruction exists, and what it may touch   yields: a set
keyword directive    see         the lens the intent is read through                    yields: a structured line
node                 project     what follows what, as a contract                       yields: an edge-list
control flow         act         which branch, which iteration                          yields: a procedure
semantic operation   act         which effect, bound to a result                        yields: a procedure
invariant record     constrain   what is admissible, and what would object               yields: a boolean
handoff gate         verify      what evidence closes the node, over what set           yields: pass, fail or unknown
report               commit      the verdict as a representation a checker can challenge yields: an artifact
well-formedness      terminate   whether the document may be trusted                    yields: a boolean
```

A1·c prose or directive

```mermaid
flowchart TB
prose["Prose · 'get the data and check it'"]
interpret["The model interprets · what is get, what is check, what counts as valid"]
variance["A different completion each run"]
pag["A directive · READ data FROM source, VALIDATE data AGAINST schema"]
pattern["The model completes a pattern it has seen"]
narrow["A narrower set of completions · still probabilistic"]
prose --> interpret --> variance
pag --> pattern --> narrow
```

A1·d scan, loop, binding

```mermaid
flowchart TB
doc["A document · typed, contracted, gated, bounded"]
scan["A scan · checks the shape, deterministic"]
loop["A reasoning loop · orient, intent, see, derive, project, act, constrain, verify, commit, terminate"]
binding["A binding · maps each operation to a tool, each slot to a value"]
output["Output · a sample, unverified until read"]
doc --> scan
doc --> loop --> output
loop -- an effect --> binding
doc -. has no runtime of its own .-> output
```

## Links to

- [Closed Vocabulary](https://banes-lab.com/records/arch/closed-vocabulary.md)
- [The loop](https://banes-lab.com/disciplined-methodology/start/the-loop.md)
- [Why it works](https://banes-lab.com/pag/introduction/why-pag-works.md)
- [Limits](https://banes-lab.com/pag/validation/limitations.md)
- [Implicit Contract](https://banes-lab.com/records/arch/implicit-contract.md)
- [Explicit Contracts](https://banes-lab.com/records/arch/explicit-contracts.md)
- [Semantic operations](https://banes-lab.com/pag/guide/tool-invocation.md)
- [Static Analysis](https://banes-lab.com/records/arch/static-analysis.md)
