Follow a task guide

A question gets one answer. A typical task — an import dossier, an insurance payout, a measurement uncertainty report — is many questions in the right order, facts from a person between them, and a document at the end. The canon’s author publishes that order next to the package as a task guide: which case to pin, which facts to collect, which question cards to ask, where to go on every answer status, and which answers fill which fields of the document. A guide carries no formula, rate or threshold; those stay in the canon, and walking the guide computes nothing by itself. The Guide page A typical task along a canon’s route covers discovery; this page covers the walk.

The reusable instruction set for an agent that applies a canon by task guides is the apply-canon skill, shipped in the examples bundle as examples/instructions/apply-canon/SKILL.md. It encodes the same contract as this page — no semantics in the agent, a human-named date of law, a stop is not an answer, every document value copied from an answer with its source — so an agent can load it instead of re-deriving the rules from prose.

The worked example is the uncertainty-report route, version 0.1.0, of jcgm.gum — the Guide to the Expression of Uncertainty in Measurement. It is a scientific methodology, not state law: it standardizes how a measurement result is reported, and nothing here is a legal duty. Route listing (ran locally, law guide):

Output

Task routes of jcgm.gum — corpus/laws/org/jcgm/gum/analysis/task-guides.json
(sha256:d6a5197969966402f585c76a97d7bb7610811d9d8b3da227729acbbeb1db774b)
  jcgm.gum/uncertainty-report v0.1.0 — Отчёт о неопределённости измерения
по GUM: бюджет, степени свободы, расширенная неопределённость и запись
результата (25 steps, 13 questions, 6 witness paths)

The mechanism in four moves

Every task guide repeats four moves. Real step names from the route:

1. Pin and collect. Fix the case and its date of law, then present the facts the case already holds (pin-case, collect-model).
2. Ask a question. Run the step’s question and attach the answer to the journal (ask-input-count returns 2: two inputs).
3. Follow the branch the answer chose. The route names the next step for every answer status. Here the combined uncertainty derives nothing (ask-combined returns an empty answer), so the route sends the agent to a diagnostic step instead of guessing a value (ask-contribution-count returns 1: only one input contributes).
4. Fill part of the document. An assembly step copies recorded answers into named fields with their sources; a field with no answer stays visibly open (assemble-budget shows the combined uncertainty as open, not as zero).

The route opens with pinning, continues through collection steps (model, input evaluations, coverage data), question steps (input count, variances, contributions, combined uncertainty, degrees of freedom, coverage factor, expanded uncertainty, report completeness) and closes with assembly steps (case, presented data, budget, coverage, result, boundaries, free fields).

Branches follow status, never invented values

Each step names its cards; the agent asks them in order and follows the handler of each outcome. The route’s witness paths pin the expected per-step outcomes for replay. Excerpt, shortened (ran locally, law guide … --witnesses):

Output

k-chosen:
  ask-combined single ← scenario "urn:query:gum-route-k-chosen"
  ask-dof empty ← scenario "urn:query:gum-route-k-chosen"
  ask-dof-infinite NEITHER ← scenario "urn:query:gum-route-k-chosen"
  ask-report-complete TRUE_ONLY ← scenario "urn:query:gum-route-k-chosen"

An outcome of empty or NEITHER on a witness path is part of the contract, not a failure: the route says what comes next. How to read each status is the single table in Read answers.

A complete pass on the incomplete-input branch

Status: ran locally (law 0.1.1, local CLI from a full checkout; see the Validation record).

The pass walks the route against the case VkhodBezOtsenki (“input without evaluation”) of the worked-example project otchet-neopredelennosti (package examples.jcgm_gum.otchet_neopredelennosti): two inputs, only the first evaluated, so the combined uncertainty stays silent and the route takes the diagnostic branch. The journal and the answers live in scratch; the project is only read. $GUM below is the directory of the jcgm.gum package, $PROJECT a scratch copy of the worked-example project.

Start the journal with a date of law named by a person:

Terminal

law guide journal new $GUM jcgm.gum/uncertainty-report \
  --legal-time 2026-09-06 --out $SCRATCH/journal.json
# journal $SCRATCH/journal.json started: route jcgm.gum/uncertainty-report
# v0.1.0 (sha256:d6a51979…), legal time 2026-09-06; first step — pin-case

Pin the case and present only what it holds:

Terminal

law guide journal add $SCRATCH/journal.json --step pin-case \
  --bind 'result=urn:example:gum:r'
# entry 1: step pin-case (case) — next step collect-model

law guide journal add $SCRATCH/journal.json --step collect-model \
  --bind 'input=urn:example:gum:x1' --bind 'input=urn:example:gum:x2' \
  --present jcgm.gum::input_of --present jcgm.gum::result_unit \
  --present jcgm.gum::result_estimate --present jcgm.gum::uncertainty_precision \
  --present jcgm.gum::input_unit --present jcgm.gum::unit_sensitivity \
  --present jcgm.gum::inputs_uncorrelated
# entry 2: step collect-model (collect) — next step collect-evaluations

law guide journal add $SCRATCH/journal.json --step collect-evaluations \
  --present jcgm.gum::quoted_uncertainty_as_multiple
# entry 3: step collect-evaluations (collect) — next step ask-input-count

No sensitivity coefficients, no correlated inputs, no Type B degrees of freedom are presented: the case does not hold them. Then each ask step gets one law ask --out answer attached to the journal. Observed outcomes (every answer COMPUTED, no issues):

Step	Saved query	Outcome
ask-input-count	chislo-vkhodov	single: 2
ask-input-variance	dispersiya-x1, dispersiya-x2	single: 144/1; empty
ask-input-contribution	vklad-x1, vklad-x2	single: 144/1; empty
ask-combined	summarnaya	empty
ask-contribution-count	chislo-vkladov	single: 1

Terminal

law ask $PROJECT --case VkhodBezOtsenki --query-json $PROJECT/queries/chislo-vkhodov.json \
  --out $SCRATCH/answers/chislo-vkhodov
law guide journal add $SCRATCH/journal.json --step ask-input-count \
  --answer $SCRATCH/answers/chislo-vkhodov
# entry 4: step ask-input-count (ask) — next step ask-input-variance
# … entries 5–8 attach the remaining answers; entry 8 ends at request-free-fields

Observed gap: route cards missing from the catalog

The next command prints ready commands with --card input-count, but that card does not exist: ask --card: card "input-count" not found. The route’s ask steps name cards (jcgm.gum/input-count, jcgm.gum/standard-variance-value, …) that are absent from the package’s question catalog (12 entries, none matching). The pass therefore attaches saved-query answers, which the journal accepts. Aligning the route with the catalog is package work for the route owner. Until then the card path is NOT RUN (reason: cards absent; reproduction: law guide journal next on the journal above, then the printed --card command), and the saved-query path is the repeatable one.

Human decision and assembly

The human fills the report’s free fields; the seven assembly steps close the walk:

Terminal

law guide journal add $SCRATCH/journal.json --step request-free-fields \
  --set 'free/compiled-by=Lab N-7, R. Jumagulov' \
  --set 'free/instrument=voltmeter V7-28'
# entry 9: step request-free-fields (decision) — next step assemble-case

law guide journal add $SCRATCH/journal.json --step assemble-case  # … through assemble-free
# entry 16: step assemble-free (section) — walkthrough complete; document open fields 15

Check, then check with replay — both return the same line:

Output

journal $SCRATCH/journal.json matches route jcgm.gum/uncertainty-report:
16 entries, walkthrough complete; document open fields 15

The rendered document builds every section from recorded entries. Budget section excerpt:

Output

## Бюджет: суммарная неопределённость
| Число входов | 2 | entry 4, step ask-input-count, resultHash sha256:5258… |
| Дисперсия u²(xi) каждого входа | urn:example:gum:x1: 144/1; urn:example:gum:x2:
open (empty collection — no value derived, this is not zero) | entry 5, … |
| Вклад ui²(y) каждого входа | urn:example:gum:x1: 144/1; urn:example:gum:x2:
open (empty collection — no value derived, this is not zero) | entry 6, … |
| Суммарная стандартная неопределённость uc(y) |
open: empty collection — no value derived, this is not zero | entry 7, … |
| Число входов с вкладом | 1 | entry 8, step ask-contribution-count, … |

Unasked branches render as open: question not asked on this path; the boundaries section lists the route’s six boundaries; the free fields carry the human’s values with their entry as source.

The full branch stopped on TYPE_ERROR

Status: ran locally (law ask with the saved combined-uncertainty query against the k-chosen case).

An attempt at the k-chosen branch stopped at the combined-uncertainty question: evaluationStatus TYPE_ERROR, because sqrt_bounds received a Number where the engine expects Integer, Decimal or Rational. That stop is a package/engine type mismatch to be resolved outside the route mechanism, not proof that the route is broken: the incomplete-input branch above walks from the first step to a checked, rendered document. A journal holding a type-error record cannot honestly check clean, so the k-chosen full pass stays untaken until the mismatch is fixed. The agent’s correct behavior at such a stop is the same as at any non-COMPUTED status: stop the branch, report the status and its message, and invent nothing.

Human decisions

Two steps belong to a person: naming the coverage factor with its conditions, and filling the report’s free fields. The journal also starts with a human act — the date of law is named by a person and never defaulted to today; that is a contract obligation of the agent, not advice. The agent stops at these steps, presents what is known, and resumes when the person answers. The route does not choose a disputed reading and does not judge for an authority; where those arise, the rules of Human decisions, interpretations and scenarios apply.

Document assembly and open fields

Each assembly step builds one section from earlier journal entries: values flow from recorded answers into named fields with their sources. A field with no source stays open; the document shows it as unfilled rather than inventing content. The boundaries section is assembled last, so the reader sees what the report does not claim.

What “completed” means

A completed walkthrough means the selected path was finished: every step on the taken branch visited, the decision recorded at each fork, every section assembled from recorded entries. It does not mean every branch was taken — the pass above completes 16 entries on a 25-step route — and it does not mean the grounds are sufficient: a completed report can still rest on sparse inputs, open fields and silent questions. Sufficiency is a human assessment of the assembled document, not a property of the walk.

Journal commands

The walkthrough journal is a file maintained by law guide journal:

• new starts a journal: pins the route, the catalog-bytes hash and the human-named date of law.
• add records the next step; an answer is a law ask … --out directory, and a document section assembles itself from earlier entries.
• check verifies the journal against the route, attached answers and sections; --replay replays each answer with law eval.
• next shows the coming step with case data and ready commands; run walks questions and sections in order and stops at case, collection or human-decision steps.
• render produces the walkthrough document: sections, values and their sources.

Over MCP the same routes are offered as the server’s prompts (prompts/list names them, prompts/get returns the frame with ready law_ask calls). Getting a prompt executes nothing and accepts no facts. Status: NOT RUN — the session’s MCP server was unreachable; confirm through the server’s own prompts listing before scripting against it.

How to verify

List the routes and their witnesses: law guide with the package directory, then with the route id and --witnesses; law guide journal --help for the subcommands. Reproduce the pass on a scratch journal: new with date of law 2026-09-06, the three pin/collect records, one law ask --out per saved query in the table with add --answer, the decision record with two --set fields, the seven assembly records, then check, check --replay and render. Reproduce the k-chosen stop with law ask and the saved combined-uncertainty query against the k-chosen case.

Inputs: a pinned copy of the worked-example project with its queries, cases and vendored dependencies, described in examples/task-guides/README.md. The pass needs the law CLI from a full checkout; the bundle alone is not enough.

Validation record

Show commands, versions and results

Checked	Result	Version
Route listing and route detail with witnesses	as quoted	law 0.1.1, law.core/0.2, 2026-10-04
Journal new/add/next/check/check --replay/render, 16-entry pass	check line as quoted	same
Seven saved-query asks with --out	outcomes in the table	same
k-chosen combined-uncertainty ask	TYPE_ERROR (sqrt_bounds)	same
--card input-count	card "input-count" not found	same
MCP prompts and route catalog	NOT RUN (server unreachable)	—

Previous: Human decisions, interpretations and scenarios Next: Cases and processes