Application and operations

This section treats the deadline example as a program to run and to keep running. The chapters assume the application built along the main route: one form, one example API, one command line, one pinned canon.

The application lives at:

Output

docs/build/examples/deadline-app

All five chapters describe that program: the file names, function names, endpoints, and versions below are its own.

What the application does

A user enters an event date, a period length in days, an optional candidate end date, and a legal time. The application validates the form, turns the fields into canon facts, and asks two questions: it computes the end date (a collect query) and checks the candidate (a truth query). It then reads the answer into one of four shapes, renders it for display, and stores a capture that reproduces the answer later.

The modules that do this are:

Output

src/input-schema.ts   validateFormInput, FormInput{eventDate,durationDays,candidateEnd?,legalTime}
src/to-case.ts        ADAPTER_VERSION 1.0.0, toFacts, toCaseInput
src/query.ts          buildCollect, buildTruth
src/runtime.ts        openModel singleton, evaluateCollect/evaluateTruth/explainWhy
src/read-result.ts    AppResult value|claim|not-computed|unknown
src/to-view.ts        toViewModel
src/capture.ts        CAPTURE_FORMAT deadline-app.capture/1, documentBase64, sha256
src/replay.ts         replayCapture, verifyCaptureIntegrity
src/missing.ts        missingFacts
src/server.ts         node:http; GET / form; POST /api/deadline/evaluate; POST /api/deadline/replay
src/cli.ts            evaluate/replay
public/index.html     the form
python/deadline.py    the same flow in Python

The server keeps its example call to four fixed fields; the replay endpoint accepts a capture; stored captures land in captures/<id>.json. The suite is a node --test suite with the Python checks beside it.

Chapter map

Chapter	It covers
Architecture	layers, the data path from form to capture, the module table, the runtime singleton, and trust boundaries
Testing	what the suite checks, snapshot versus independent expectations, how to run it, and how to add a regression
Security and privacy	data inventory, the fixed-field API, validation before compute, storage, and logging
Deployment	the one supported way to run the server, plus resource limits, logs, restart, and diagnostics
Versioning	the four version axes, the upgrade checklist, and replay-old versus recompute-new

Pinned versions

Package	Version
@arxo/law	0.3.3
@arxo/canon-bgb-fristen	0.1.5
arxo (Python)	0.2.0
Node.js	20 or newer
Python	3.12 or newer

The model itself is pinned in code:

Output

open('de.bgb.fristen@0.1.0', { offline: true })

Running example

Every chapter uses the same case: an event on 6 March 2026 starts a period of 14 calendar days, and the candidate end date is 20 March 2026.

Output

eventDate:      2026-03-06
durationDays:   14
candidateEnd:   2026-03-20
legalTime:      2026-09-17
timezone:       Europe/Berlin
deadlinePolicy: urn:de:corpus:clir:bgb-fristen#BGB_FRISTEN_TAG

On this input the collect query computes 2026-03-20 with status COMPUTED, and the truth query answers TRUE_ONLY. A wrong candidate date answers NEITHER, as does a case with a fact removed. Execution is local (via is local); this canon build attaches no source anchors, so sources is empty and the rule identifier in the proof remains the address. Every answer carries the program, semantic, and result hashes plus the canonical document bytes.

Limits that shape every chapter

• A capture saved by one SDK is replayed by the same SDK only: the statuses and values match across SDKs, but the result hash and document bytes differ.
• Python has no questions, no unfold, and no focused_truth; where a step needs one of those, the Python path reads the TypeScript manifest.
• There is no native batch call: the application answers one case per engine call and loops for many.
• explain() needs an MCP host and therefore the network; plain local open and evaluate work offline after install.

How to read these pages

Each page names the files it touches, the commands it runs, and the output to expect. Fenced blocks carry paths, commands, and transcripts; the prose around them says what each step establishes. Read the architecture page first, then any other in any order.

Next

• Architecture: layers, data path, and trust boundaries