# Genesis stages > This section covers the genesis stage every node carries. Page: PAG · Patterns Canonical: https://banes-lab.com/pag/patterns#genesis-stages This section is stop 28 of 102 in the learning route. Previous: [02 - From intent to structure](https://banes-lab.com/pag/patterns/intent-to-structure.md). Next: [04 - Algorithm examples](https://banes-lab.com/pag/patterns/algorithm-examples.md). It builds on [02 - From intent to structure](https://banes-lab.com/pag/patterns/intent-to-structure.md). 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·d verb to stage](https://banes-lab.com/pag/patterns#genesis-stages-panel-d), because the verb names where in the substrate cycle the node's artifact comes to be; [C1·a genesis stages](https://banes-lab.com/pag/patterns#genesis-stages-panel-a) lists the stages, so one word decides the node's legal position. A protocol is a chain of such verbs, and [C1·b protocols](https://banes-lab.com/pag/patterns#genesis-stages-panel-b) shows four. A protocol is selected as described in [from intent to structure](https://banes-lab.com/pag/patterns/intent-to-structure.md) and shown in [C1·e request to nodes](https://banes-lab.com/pag/patterns#genesis-stages-panel-e), and a document instantiates its chain as tagged, gated nodes in genesis order, as shown in [C1·c chain expanded](https://banes-lab.com/pag/patterns#genesis-stages-panel-c). ### Derived from the verb A node labelled 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 catalogue 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](https://banes-lab.com/records/arch/verification.md) gate protocol closes the chain. Where a node's stage disagrees with its verb, the node is mislabelled, 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](https://banes-lab.com/disciplined-methodology/start/the-loop.md), and the same verb names the genesis stage used to order the nodes, as described in [node design](https://banes-lab.com/pag/guide/node-design.md). Every action verb grounds to a reasoning record and the stage follows from that record, so a verb grounded in observation realises existence, one grounded in construction realises structure, and one grounded in a verification node realises constraint, which makes the derivation a lookup rather than a judgement. A protocol is a chain with a use-when and the principles it serves. The use-when names the transition the chain is for, from one state of the tree to another, and the principles name what the chain 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·a genesis stages ```pag # 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 stabilise # the stage is a tag on the node, beneath the header's four slots · one dialect, one header shape # NODE — [ · · · yields: ] @genesis: ``` C1·b protocols ```pag # a protocol · a verb chain with the transition it is for and the principles it serves : use_when: "a unit mixes concerns or exceeds a bounded complexity" chain: ANALYZE → FIND → EXTRACT → CREATE → VERIFY principles: [] : use_when: "a new variant extends a stable system" chain: ANALYZE → FIND → CREATE → LINK → VERIFY principles: [] : use_when: "an existing production path is replaced" chain: FIND → ANALYZE → CREATE → EXECUTE → VERIFY principles: [] : use_when: "a new invariant needs automated protection" chain: ANALYZE → CREATE → LINK → EXECUTE → VERIFY principles: [] : # always appended · every plan ends in it use_when: "every plan requires a final reasoning and checklist validation" chain: ANALYZE → VERIFY → REPORT principles: [] ``` C1·c chain expanded ```pag # a chain expanded into nodes · each header carries its layer, axis, math type and yields, and each node its genesis stage # NODE 1 — ANALYZE THE UNIT [epistemic · analysis · logic · yields: set] @genesis: difference # NODE 2 — FIND THE SEAMS [epistemic · ontology · set-theory · yields: set] @genesis: existence # NODE 3 — EXTRACT THE CONCERN [epistemic · reasoning · graph · yields: edge-list] @genesis: relation # NODE 4 — CREATE THE NEW UNIT [epistemic · formalisation · computation · yields: procedure] @genesis: structure # NODE 5 — VERIFY THE SPLIT [evaluative · verification · logic · yields: boolean] @genesis: constraint # the stage is derived from the verb · a node whose stage disagrees with its verb is mislabelled # a node that depends on a later genesis than it produces is a genesis inversion ``` C1·d verb to stage ```mermaid 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·e request to nodes ```mermaid 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 ``` ## Links to - [From intent to structure](https://banes-lab.com/pag/patterns/intent-to-structure.md) - [Verification](https://banes-lab.com/records/arch/verification.md) - [The loop](https://banes-lab.com/disciplined-methodology/start/the-loop.md) - [Node design](https://banes-lab.com/pag/guide/node-design.md) ## Linked from - [Algorithm examples](https://banes-lab.com/pag/patterns/algorithm-examples.md) - [Planning templates](https://banes-lab.com/pag/templates/templates-planning.md)