Templates

D1Template families

This section covers the template families, which D1·dthe families lists with the genesis question each answers. A family document has no runtime, so it is walked by the reasoning model its type declares, on the axis its type names, and an adapter performs the effects, as shown in D1·etype to artifact. Every node states its layer, its axis, the shape its decision yields, the contract it transforms and one evidence-bearing gate, as shown in D1·bone node beneath D1·afamily header. The transitions are declared once in D1·cloop spine, and every node cites it. A template is used by walking its nodes as the spine declares, as described in execute the template, and D1·fwalk or read shows the difference that decides whether its guarantees hold.

D1.1Typed nodes, one gate each

A family document that does not say who walks it and on which axis leaves the reader to pick. A debugging document is walked as a plan, the ranking of candidate lines is skipped, and the first hypothesis is traced to the end. A node that reads only the prior node's output cannot skip a decision, and a gate that owes a shape cannot be satisfied by a different one.

For this reason a template family is a document type whose nodes are typed contracts, walked by the reasoning model its type declares. The family is selected by the genesis question the artifact answers, and the type declares who walks it and on which axis, rather than the reader picking. In practice, a family document opens by declaring its type, its trust anchor, its recursion limit and the slots every host fact resolves through. It states the four layers with the question each answers about this document, and the shape legend every decision is typed by. Each node has a purpose, an axis question, a cue and a contract, its decisions are typed, and it closes on a gate whose checks carry their evidence. The spine is declared once, and every handoff cites it.

To check this, name for each node the layer, the axis and the shape its header declares, and the gate that carries evidence. A node missing any of the four is prose written in the family's format. A template family fits only an artifact that will be walked, and an artifact that is read rather than walked is described in from intent to structure.

The trust anchor says which inputs are evidence and which are claims, so a hypothesis is untrusted until it is scored and prior knowledge is untrusted throughout.

A node is design by contract at the scale of one decision. The repair edge is the one a fixed pipeline lacks, and what it does is described in validation gates.

Families are selected by the genesis question, and each inlines its whole structure rather than importing a shared spine. Duplication is deliberate here and nowhere else, because independence is what makes each family walkable on its own. A family's loop, its typing and its gates are domain-neutral and transfer to any tree unchanged. Its catalogs, the taxonomies it cites and the thresholds it names, are slots the adapter resolves, as described in limits.

D1·afamily header
---
name: {task_name}
type: DEBUG
version: 1.0.0
---

THIS DEBUG RESOLVES a symptom to an evidence-scored root cause and one minimal fix by walking the ten-node loop across four reasoning layers

%% META %%:
    priority: EVIDENCE > ROOT_CAUSE > SPEED
    trust: procedural_trace = TRUSTED, test_result = TRUSTED, prior_knowledge = UNTRUSTED, a_hypothesis = UNTRUSTED_UNTIL_SCORED
    objective: {bug_report}
    recursion_limit: {limits.max_fix_attempts}
    parameters: every taxonomy, threshold and command resolves from {convention.*}, {limits.*} and {toolchain.*}, never typed

THE FOUR LAYERS · each answers one question about this document
    substrate    how does a fix come to be            grounds the path from differential to fix
    epistemic    how is the bug known                 orient · see · derive · project · act
    conative     which line is worth pursuing         intent · constrain          mandatory, always
    evaluative   is it fixed, and are we done         verify · commit · terminate mandatory, always

YIELDS-SHAPE LEGEND · every decision resolves to a typed shape
    set-theory → set or boolean   logic → boolean   graph → edge-list   optimization → boolean or ranking
    analysis → operation   computation → procedure   probability → a number in zero to one   dynamical-systems → boolean or counter

D1·bone node
# NODE 2 — INTENT   [conative · teleology · optimization · yields: ranking]
@purpose: "extract the differential and rank the candidate lines by worth, so one line is traced and the rest are not"
@axis_question: "which line is worth pursuing?"
@cue: "rank before you trace"
@mandatory

CONTRACT:
  input:        the session from NODE 1 · the symptom, what works, what breaks
  transform:    detect the works-versus-breaks differential; rank the candidate lines by probability times severity minus cost
  constraints:  a line is admissible only inside {limits.max_fix_attempts}
  output:       <ranked>, and the selected line
  handoff:      the selected line is the argmax of the admissible · yields a boolean over a ranking

DECLARE tel: object
SET tel = {
  objective: "find and fix the root cause",          # yields: a set
  utility:   FUNCTION(line) → probability(line) * severity(line),   # yields: a number
  cost:      FUNCTION(line) → what tracing it costs,                # yields: a number
  priority:  FUNCTION(ranked) → ranked[0] is admissible             # yields: a boolean over a ranking
}

# OUTPUT CONTRACT
SET <ranked> = RANK <candidate lines> BY tel.utility - tel.cost

HANDOFF GATE (evidence-bearing):
  rule_id: "INTENT"   yields: ranking
  [check] the selected line is the argmax of utility minus cost (evidence: the ranking)
  [check] <ranked> holds more than one admissible line (evidence: a count above one)
  [check] no line was traced before the ranking existed (evidence: the trace log starts after this gate)
  result: pass → NODE 3 | one admissible line → REPAIR (owner: NODE 1) | unknown → BLOCKED

D1·cloop spine
# THE LOOP SPINE · declared once, every node cites it
# node        layer       axis            yields                     transition out
# orient      epistemic   ontology        a set, with evidence       sequences → intent
# intent      conative    teleology       an objective, a ranking    GATE worth → see | redirect
# see         epistemic   analysis        lenses, edges              sequences → derive
# derive      epistemic   reasoning       claims                     sequences → project
# project     epistemic   reasoning       an ordered graph           sequences → act
# act         epistemic   formalization   procedures                 sequences → constrain
# constrain   conative    teleology       admissibility              GATE → verify | repair
# verify      evaluative  verification    a report                   GATE evidence · refutes back to the earliest owner
# commit      evaluative  representation  the artifact               sequences → terminate
# terminate   evaluative  termination     stop                       GATE stop → STOP | blocked → ask

# REPAIR EDGE · verify fails backward to the earliest node that can supply the missing evidence, bounded by {recursion_limit}
# a repair invalidates every dependent record forward · nothing downstream is restored

D1·dthe families
# the families · each a document type, each walked by the model and axis its type declares
CHECKLIST      pattern-cycle  formalization   a plan, produced by owned nodes
DEBUG          epistemology   analysis        a symptom to an evidence-scored cause and one fix
VERIFICATION   epistemology   verification    claims adjudicated against implementation evidence
AUDIT          epistemology   verification    an agent measured against its contract, then corrected
DISTILLATION   epistemology   reasoning       repeated behavior to one proven base
TRANSLATION    epistemology   representation  a rendering audited line by line against its source
COMPOSITION    pattern-cycle  formalization   a structure rendered from anchors and modifiers

# the genesis question each answers · one question, one family
"how does a plan come to be?"      → CHECKLIST
"how does a fix come to be?"       → DEBUG
"how does a verdict come to be?"   → VERIFICATION, AUDIT
"how does a base come to be?"      → DISTILLATION
"how does a rendering come to be?" → TRANSLATION, COMPOSITION

D1·etype to artifact

flowchart TB
    type["The document type · declares the model and the axis"]
    layers["Four layers · substrate, epistemic, conative, evaluative"]
    nodes["Nodes · each typed to the shape it yields, each reading the prior output"]
    gate["One evidence-bearing gate per node"]
    spine["The spine · transitions declared once"]
    artifact["The artifact the loop terminates on"]
    type --> layers --> nodes --> gate --> artifact
    spine --> nodes
    gate -. repairs back, bounded .-> nodes

D1·fwalk or read

flowchart LR
    read["Read a template for ideas"]
    shaped["Write something template-shaped"]
    none["None of its guarantees"]
    walk["Walk its nodes as the spine declares"]
    artifact["The artifact the loop terminates on"]
    read -. the tempting path .-> shaped --> none
    walk --> artifact