Pattern Abstract Grammar

Pattern Abstract Grammar

Structured instructions for LLMs

Patterns

A1Instruction patterns

This section covers the verbs and prepositions a document is written with. Each verb carries a semantic contract, and a document relies on that contract rather than on what a particular tool happens to do; a read, for example, leaves its source unchanged whichever tool performs it. A1·ainput verbs lists what each input verb promises about its source, A1·boutput verbs what each output verb promises about its result, and A1·ccontrol verbs what each control verb promises about its effects. A1·dthree readers shows who a contract serves, and A1·ethe prepositions declares the relations the prepositions carry between the operands. A verb's contract together with its preposition is the whole meaning of a line.

A1.1Verbs and their contracts

A verb with no stated guarantee means whatever the model completes it as. A document says process the items, the model reads, filters, writes and deletes under that one word, and the reviewer cannot say which of those the author meant. A verb the model has seen carry one guarantee across many contexts is likely to carry it into the completion; a verb used loosely carries every meaning it has ever had.

For this reason every line relies on its verb's contract and its preposition's relation, and a line whose behavior breaks them is a defect in the line. The verb is chosen by the guarantee the line needs, rather than by the tool that will perform it. In practice, a read is used when the source must survive, an extract when its meaning must, a find when only existence matters, a filter when order must hold, and an execute when a side effect is the point. The operands are bound with the preposition that names their relation, and the guarantee is relied on downstream.

To check this, read a line and state what it promises about its source and its result. A line whose promise you cannot state uses its verb loosely, and the repair is the verb whose guarantee matches the intent. A contract is a promise the grammar makes about the intent; whether the model or the tool executing the line keeps it is what verification is for.

A contract promises one of three things: what happens to the source, what the result is, or what effects the line may have. Two contracts carry the most weight. An execute may have side effects, and saying so is what keeps each of them from being a hidden side effect. A report is a statement to a reader, never a state that anything later reads as the truth.

A line with the wrong preposition puts its operands in the wrong relation, and the model is asked to complete the relation it was given.

A1·ainput verbs
READ <file> FROM <path> INTO <content>        # non-destructive · the source is unchanged
LOAD <settings> FROM <file>                    # acquisition with parsing
EXTRACT <fields> FROM <record> INTO <values>   # isolation · the source keeps its meaning
FIND <pattern> IN <scope> INTO <found>          # existence · boolean, non-invasive
GLOB "<pattern>" INTO <files>                  # discovery by shape
GREP "<term>" IN <path> INTO <matches>          # discovery by content
A1·boutput verbs
WRITE <content> TO <file>                       # idempotent where it overwrites
CREATE <report> FROM <data> USING <template>     # a candidate set or an artifact
APPEND <item> TO <collection>                    # growth without retraction
REPORT <status>                                  # a statement to a reader, never a state

CONVERT <data> TO <format>
FILTER <items> TO <kept> WHERE <condition>       # removes, preserves order
MERGE <sources> INTO <target>
SPLIT <data> BY <delimiter> INTO <segments>
A1·ccontrol verbs
VALIDATE <data> AGAINST <schema>                 # conformance
VERIFY <condition>                               # a boolean, non-modifying
ANALYZE <state> FOR <errors> INTO <found>        # deep examination, may delegate
COMPARE <actual> AGAINST <expected> INTO <diff>
RANK <candidates> BY <score> INTO <ordered>       # score-driven ordering

EXECUTE <command> WITH <params>                  # side effects possible
TASK "<objective>" WITH agent: <role> → <result>
SEND <message> TO <recipient>
AWAIT <response> INTO <result>
SET <state> = <value>                            # assignment · idempotent
LINK <source> TO <target>                        # a bidirectional association
A1·dthree readers
flowchart TB
    verb["A verb"]
    guarantee["Its semantic contract · what it promises about the source and the result"]
    reader["A reader relies on the contract"]
    model["The model is asked to complete the pattern the contract names"]
    check["A scan can hold the contract · a READ that mutates is a defect"]
    verb --> guarantee
    guarantee --> reader
    guarantee --> model
    guarantee --> check
A1·ethe prepositions
flowchart LR
    from["FROM · the origin"]
    in["IN · the container searched"]
    into["INTO · the destination bound"]
    to["TO · the destination intended"]
    using["USING · the mechanism"]
    against["AGAINST · the reference"]
    for["FOR · the purpose"]
    with["WITH · the parameters"]
    from ~~~ in ~~~ into ~~~ to
    using ~~~ against ~~~ for ~~~ with

B1From intent to structure

This section covers how a request is turned into structure: by walking the loop rather than by matching a word, as shown in B1·efit, not word and written in B1·bselection by fit. Each of the loop's nodes yields a decision of a declared shape. Intent yields a ranking, never a yes; verify yields a boolean over evidence; and terminate yields a stop only when the work is saturated, complete and verified, which are the three gates written in B1·ctyped gates. A document that walks the loop writes each node with its contract, and with a gate wherever the node owes one, as shown in full in B1·aten nodes, and B1·dthe loop shows the edge a refutation takes back.

B1.1Walk the loop, select by fit

A structure chosen from a trigger word answers the word rather than the request. A request to analyze a plan is routed to the analysis protocol because it said analyze, but the plan needed a decision between two designs, and the output is a thorough analysis of the wrong question. A trigger word is the cheapest possible match and the least reliable one, because the same word appears in requests that have nothing else in common.

For this reason I treat the words of a request as evidence about it, never as its subject. The structure is derived from the transition the request asks for, rather than from the words it uses. In practice, a request is turned into nodes by walking the loop in order and closing each node on the gate it owes. The objective is stated before anything is examined, and the admissible ways of reaching it are ranked, so intent yields a ranking with more than one entry. A protocol is selected by comparing the transition the request asks for with what each protocol is for, and the reason is recorded. Every gate is typed to the shape its decision yields, and a refuted claim goes back to derive with its evidence, rather than forward with a caveat.

To check this, name for each node the stage it realizes and the shape its gate yields. A gate that owes a ranking and returns a yes has folded, and a protocol whose selection cites a word rather than a reason was matched, not chosen. A descriptive artifact, such as a reference, a note or a contract, is read rather than walked, and forcing the full loop onto it fits it to a shape it does not have. Only an artifact that will be walked takes every node.

The four gates the loop names never fold, whatever the size of the task, and a document writes each as a typed gate. Worth is a ranking with more than one entry, as described in worth before work. Admissibility is asked after the operations exist. Evidence is a non-empty set, and finding no contradiction is not evidence. Termination requires saturation, completion and verification together. Every other node runs when the subject calls for it.

The reason for a selection travels with it, so a reader can contest it.

B1·bselection by fit
# selection by semantic fit · never by a word in the request
ANALYZE <request> AGAINST <each protocol's use-when> INTO <fit>
FOR EACH <protocol> IN <protocols>:
    IF <fit>[<protocol>].<semantic-match>:
        APPEND <protocol> TO <selected> WITH reason: <fit>[<protocol>].<reason>

# what a trigger word would have done
# "analyze" in the request → the analysis protocol, whatever the request was for
B1·dthe loop
flowchart TB
    orient["Orient · what exists"]
    intent["Intent · worth, a ranking"]
    see["See · lenses"]
    derive["Derive · claims"]
    project["Project · an ordered plan"]
    act["Act · procedures"]
    constrain["Constrain · admissible?"]
    verify["Verify · evidence"]
    commit["Commit · an artifact"]
    terminate["Terminate · stop?"]
    orient --> intent -- gate --> see --> derive --> project --> act --> constrain -- gate --> verify -- gate --> commit --> terminate
    verify -. refuted, with the evidence .-> derive
    terminate -- gate --> orient
B1·efit, not word
flowchart LR
    request["A request"]
    word["A trigger word · analyze, choose, debug"]
    fit["Semantic fit · the transition requested against each protocol's use-when"]
    wrong["The protocol the word names"]
    right["The protocol the transition needs, with its reason"]
    request -. the cheap path .-> word --> wrong
    request --> fit --> right

C1Genesis stages

This section covers the genesis stage every node carries. The stage is derived from the node's verb rather than chosen, as shown in C1·dverb to stage, because the verb names where in the substrate cycle the node's artifact comes to be; C1·agenesis stages lists the stages, so one word decides the node's legal position. A protocol is a chain of such verbs, and C1·bprotocols shows four. A protocol is selected as described in from intent to structure and shown in C1·erequest to nodes, and a document instantiates its chain as tagged, gated nodes in genesis order, as shown in C1·cchain expanded.

C1.1Derived from the verb

A node labeled by hand carries a role its verb does not derive. A node's tag says structure while its only directive reads a file, and the reviewer approves a build step that builds nothing. A verb is a contract about what a node does, so a stage written beside it is a second declaration of the same fact, and a catalog of roles beside the verbs is a second vocabulary that the ontology does not carry.

For this reason the header carries one dialect, and nothing is written beside the verb that the verb already says. The stage is derived from the verb's grounding in the substrate cycle, rather than written as a role label beside the verb. In practice, every node is tagged with the stage its verb derives, and a chosen chain is expanded into nodes in genesis order, each with a contract that reads the previous output and a gate of its own, and the verification gate protocol closes the chain. Where a node's stage disagrees with its verb, the node is mislabeled, and where a node depends on a later genesis than it produces, the order is wrong.

To check this, read each node's verb and state the stage it implies. A stage that does not follow from the verb was written by hand, and a header whose bracket carries anything other than the layer, the axis, the math type and the yields is a second dialect. A one-step task has no chain to instantiate. A single read with a single gate is a directive, and tagging it adds a name to nothing.

The stage is a tag beneath the header, so a reader can see a document's construction order from its tags alone while the header keeps one shape. The header's four slots, the layer, the axis, the math type and the yields, come from the loop, and the same verb names the genesis stage used to order the nodes, as described in node design. Every action verb grounds to a reasoning record and the stage follows from that record, so a verb grounded in observation realizes existence, one grounded in construction realizes structure, and one grounded in a verification node realizes constraint, which makes the derivation a lookup rather than a judgment.

A protocol is a chain of steps with two declarations. Its use-when names the transition it is for, from one state of the tree to another, and its principles name what it must leave true, so a selected protocol carries its own acceptance criteria into the nodes it expands to. The verification gate protocol is appended to every plan, because every plan ends by checking its own reasoning against the tree.

C1·agenesis stages
# a genesis stage · where in the substrate cycle a node's artifact comes to be, derived from its verb
existence       FIND, READ, DISCOVER_RESOURCES, READ_RESOURCE     does the thing exist, is it scaffolded
difference      ANALYZE, FILTER, SPLIT, REMOVE                    what boundary makes it distinct
relation        EXTRACT, LINK, SEARCH_CONTENT, EXTRACT_FACTS      what it depends on and connects to
structure       CREATE, INSERT, COMPOSE_ARTIFACT                  how its parts are arranged under its laws
transformation  EXECUTE, CONVERT, ITERATE, EXECUTE_TOOL           what operation it performs
constraint      VERIFY, VALIDATE, ENFORCE, VALIDATE_ARTIFACT      what invariants and gates bound it
emergence       FINALIZE, REPORT, PERSIST_ARTIFACT, REPORT_RESULT does it integrate and stabilize

# the stage is a tag on the node, beneath the header's four slots · one dialect, one header shape
# NODE <n> — <NAME>   [<layer> · <axis> · <math type> · yields: <shape>]
@genesis: <existence | difference | relation | structure | transformation | constraint | emergence>
C1·dverb to stage
flowchart TB
    verb["A node's verb"]
    ground["The reasoning record the verb grounds to"]
    genesis["Its genesis stage · the position in how the artifact comes to be"]
    order["The order of the nodes · no node depends on a later stage than it produces"]
    verb --> ground
    verb --> genesis --> order
C1·erequest to nodes
flowchart LR
    request["A request"]
    transition["The transition it asks for · from one state of the tree to another"]
    fit["Semantic fit against each protocol's use-when"]
    chain["The chosen chain, with its reason"]
    nodes["Nodes · each with its stage, each closed by a gate"]
    gate["The verification gate protocol · always last"]
    request --> transition --> fit --> chain --> nodes --> gate

D1Algorithm examples

This section shows three algorithms, each a protocol instantiated: D1·aseparate a unit, D1·bauthor an enforcement and D1·cverification gate. In each, the chain is expanded into nodes, every node is headed by its layer, axis, math type and yields and tagged with its genesis stage, every contract reads the previous node's output and ends on a gate that carries evidence, and every placeholder is bound to the task's own nouns. D1·dbeyond the chain shows what every instance carries beyond its chain, and D1·etransfers or bound shows what transfers between instances and what is bound per task.

D1.1Three instances

An algorithm copied from an example keeps the example's nouns and loses the task's. A seam search returns nothing, the node is skipped without an entry, the extraction runs over an empty set, and the count that would have exposed the gap is taken over the wrong population. The chain is the protocol's contract and the gates are how the contract is checked, so the two transfer together and the nouns do not.

For this reason an algorithm is treated as an instance of a protocol, never as a copy of another algorithm. The task's nouns are bound into the protocol's shape, rather than an example being edited until it fits. In practice, the chain is written above the nodes with the reason it was chosen, so a reader sees the protocol before the instance. The chain is expanded into one node per verb, each node is tagged with the stage its verb derives, and each placeholder is bound to a noun from the task, so no placeholder survives into the document. Each node has a contract whose input names the previous output, and it closes on three to five checks that name its output, the evidence that settles each check and the set that at least one check ranged over. A failure is routed to the earliest node that can supply the missing evidence and an unknown to blocked, every write is preceded by a refusal, an empty result is a finding rather than a silent skip, and every command and location is named as a slot the adapter resolves.

To check this, look for a placeholder that survived into the document, a node whose stage disagrees with its verb, a contract whose input names nothing from its predecessor, or a gate whose count is taken over a set smaller than the one it claims. Any of the four marks a pattern cargo cult, an instance that was copied rather than bound. A node with two decisions is two nodes, and the examples are not a license to collapse them.

In the first instance, the seam gate reports an empty set of seams as a unit that does not split, because a pass over an empty population measures nothing, and the population shown beside the verdict is what makes that visible. The repair owner on the extraction gate is the seam node, because a bad extraction usually comes from a bad seam.

The second instance is the shape every rule held by attention takes before it can be trusted. The analysis names a shape rather than an instance, because a check that names an instance fails on the next case. The check is proven to fire as described in the check comes first, and a failure there routes back to the node that composed the check, not to the probe; the probe's own write is refused wherever it would land on a real file.

The third instance is appended to every plan rather than chosen. Its gate is the evidence gate described in from intent to structure, applied to the plan's own reasoning, and its standing line names what moved beneath the plan while it was being checked.

D1·dbeyond the chain
flowchart TB
    chain["A verb chain"]
    nodes["Nodes · one per verb, tagged with the stage its verb derives"]
    contract["A contract · reads the prior output, yields one record"]
    gate["A gate · three to five checks over the node's output, each with its evidence and its set"]
    empty["An empty result is a finding · never a skip"]
    slot["A command or a location is a slot · the adapter resolves it"]
    chain --> nodes --> contract --> gate
    gate --> empty
    nodes --> slot
D1·etransfers or bound
flowchart LR
    transfers["Transfers to any task of the shape · the chain, the tags, the contract and gate shape"]
    bound["Bound per task · the nouns, the sources, the thresholds"]
    instance["An instance"]
    example["An example · another task's nouns still inside"]
    transfers --> instance
    bound --> instance
    transfers -. nouns not rebound .-> example

E1Integrating algorithms

This section covers the two ways protocols connect to work. Instantiation takes a request to a chain of nodes, in the order shown in E1·dinstantiation order and written in E1·ainstantiation. The model is asked to name the transition the request asks for, choose the protocol by fit, bind its placeholders to the task's nouns and expand its chain into tagged nodes, each with a contract and a gate. Distillation takes repeated behavior to one shared base, and it is a document type of its own. It is an epistemology walked on the reasoning axis, gated on evidence that the base is universal, invariant, foundational, enforceable and load-reducing, the five properties named in E1·cboundary principles. A distillation is incomplete until the old pattern is proven gone, as shown in E1·edistillation order, and E1·bdistillation is the grammar's own template for it.

E1.1Instantiate and distil

A base promoted from one instance, or from a resemblance, carries that instance's accidents into everything that extends it. A base is raised from two classes whose names rhyme, three later classes are forced to extend it, and each one overrides most of what it inherited because the shared half was the name. A base is a promise that every future instance shares one behavior, and a promise made from one instance or from a naming resemblance has nothing to be checked against.

For this reason a shared base has to be earned by behavior shown in more than one place, and a resemblance between names earns nothing. The classes are signed from their behavior and the five principles decide, rather than a base being raised from what the names have in common. In practice, instantiation names the transition first, chooses the protocol whose use-when fits it and records the reason, binds each placeholder to a noun the task owns, and expands the chain into nodes whose contracts read the previous output and whose gates carry three to five checks with evidence. Distillation starts only after what exists has been measured and the candidates ranked by worth. Every class is signed from its behavior, each of the five boundary principles is proven with the evidence that shows it, the base is composed within its size limit, each target is migrated reversibly starting from the simplest, and the whole scope is scanned for the old pattern before anything is declared complete.

To check this, name for a base the second instance that justified it, the behavioral signature each class was signed with, and the evidence behind each of the five principles. A base with one instance, a signature based on names, or an unproven principle is a base its next class overrides more than it inherits. Distillation decides whether a shared base is justified, while whether a shape earns a template at all is decided as described in Core templates.

The transition comes first because the protocol is selected by it, as described in from intent to structure, and instantiation ends when no placeholder survives.

Distillation measures before it proposes, because a missing adoption of an existing base looks like a missing abstraction until the registry has been read. A class's signature covers initialization, lifecycle, error handling, state and dependencies. The base consists of concrete responsibilities plus abstract hooks, which is the template method pattern, and a single stray occurrence outside the approved locations is a refutation whose result line routes back to composition. The last gate measures the reduction rather than asserting it, so the single source of truth for which bases exist is the registry, never the memory of the model or the developer that did the distilling.

E1·cboundary principles
# the boundary principles · a base is justified only when every one holds, with the evidence that shows it
universal       every instance in the family is an instance of the shared behavior
invariant       the shared half does not vary across them
foundational    other behavior composes from it
enforceable     a check can hold it
load-reducing   it removes work rather than adding a layer

# otherwise the verdict is compose, a utility, or a local refactor · never a base
E1·dinstantiation order
flowchart LR
    request["A request"]
    transition["The transition it asks for"]
    protocol["The protocol that fits, with its reason"]
    nouns["Placeholders bound to the task's nouns"]
    nodes["Nodes · tagged, contracted, gated"]
    request --> transition --> protocol --> nouns --> nodes
E1·edistillation order
flowchart TB
    measure["Measure what exists"]
    worth["Rank candidates by worth"]
    sign["Sign each class from behavior"]
    boundary{"Universal, invariant, foundational, enforceable, load-reducing?"}
    base["Compose the base · migrate reversibly"]
    gone{"Old pattern gone from the whole scope?"}
    registry["Regenerate the registry · measure the reduction"]
    other["Compose, a utility, or a local refactor"]
    measure --> worth --> sign --> boundary
    boundary -- all five --> base --> gone
    boundary -- any fails --> other
    gone -- no --> base
    gone -- yes --> registry
A1Instruction patternsA1.1Verbs and their contractsB1From intent to structureB1.1Walk the loop, select by fitC1Genesis stagesC1.1Derived from the verbD1Algorithm examplesD1.1Three instancesE1Integrating algorithmsE1.1Instantiate and distil