Writing Decision Rules

One bounded run, one retained record

Run the refund rule under exact limits. Keep what was checked.

Native lispex rule run prepares the reviewed rule, admits one strict JSON input, and evaluates it once on the bounded evaluator — a separate, import-free engine that must account for every unit of work and allocation inside limits you declare. What remains is a five-member decision directory: the prepared rule artifact, the canonical input, the deterministic result with its exact request binding, the eligible portable core, and a derived summary. The raw rule source is deliberately not among them.

01Reviewed rule
02Strict JSON input
03Decision: allow
04Checkable portable core

1. The rule

LISPEX

(let ((days (cdr (car input)))
      (opened (cdr (car (cdr input)))))
  (if (< days 15)
      (if opened "deny" "allow")
      "deny"))

2. The input

JSON

{
  "days": 14,
  "opened": false
}

3. One bounded run

SHELL

lispex rule run \
  --source refund-window.lspx \
  --input day-14-unopened.json \
  --prepare-limits prepare-limits.json \
  --eval-limits evaluation-limits.json \
  --out decision

lispex rule inspect --dir decision
lispex rule verify --dir decision
lispex rule replay --dir decision

4. The decision

For the maintained day-14 unopened case, the bounded run returns allow.

5. The record, checked three ways

rule inspect summarizes the directory without executing it; rule verify checks the exact member set, identities, hashes, and bindings, still without executing; rule replay evaluates the recorded request once, in a fresh evaluator instance, and requires the same result. None of the three confers authority.

What the portable core binds

The semantic rule, the canonical input, the exact limits, the exact evaluator artifact, and the deterministic outcome — enough to know precisely which question was answered, and under which ceilings. Consumed or remaining usage is never part of it.

What the record does not establish

Who ran it, whether it is fresh, whether the policy the rule encodes is fair or correct, whether the same decision was used twice, or any permission to act outside the process.

Read the decision before the machinery

The rule asks only two questions: how many days have passed, and whether the item was opened. It performs no file lookup, network request, clock read, or hidden host call.

Input	Decision	Why
day 14, unopened	`allow`	the order is still inside the window
day 15, unopened	`deny`	the order is outside the window
day 14, opened	`deny`	an opened item is not admitted

The application remains responsible for what allow or deny means. Lispex returns data; it does not issue the refund.

Keep the five identities separate

The development product, latest published product, documentation family, semantic profile, and immutable download are separate identities. A develop checkpoint can advance without pretending that new public bytes exist. /version.json names all current axes, while download links remain bound to the exact published release.

Why the workflow has four separate commands

Command	What it does
`rule run`	prepares the rule, evaluates strict JSON under exact limits, and atomically writes one five-member decision directory
`rule inspect`	reads and summarizes the directory without executing it
`rule verify`	verifies the exact member set, identities, hashes, and bindings without executing it
`rule replay`	evaluates the recorded request once in a fresh evaluator instance and requires the same result

The directory contains the prepared artifact, canonical input, deterministic result with its exact request binding, eligible portable core, and a derived nonauthoritative summary. It does not contain the raw rule source. Existing output is never overwritten, and malformed input, tampered members, extra files, or symlinks are refused.

Authenticate one allowed issuer key

The v1.14.5 Native checkpoint can put the exact decision material and issuer envelope into one bounded canonical .lpxdecision file after the directory passes deep verification. The recipient creates the trust policy; the bundle and envelope cannot choose their own trusted key or rule.

lispex rule issue --dir decision \
  --private-key issuer.pkcs8.der \
  --issuer-label "Refund desk A" \
  --out issuer-envelope.json

lispex rule policy create --dir decision \
  --public-key issuer.spki.der \
  --consumer-label "Refund receiver" \
  --out recipient-policy.json

lispex rule authenticate --dir decision \
  --envelope issuer-envelope.json \
  --policy recipient-policy.json

lispex decision issue --dir decision \
  --private-key issuer.pkcs8.der \
  --issuer-label "Refund desk A" \
  --out refund.lpxdecision

lispex decision inspect --bundle refund.lpxdecision
lispex decision authenticate --bundle refund.lpxdecision \
  --policy recipient-policy.json
lispex decision replay --bundle refund.lpxdecision \
  --policy recipient-policy.json

The bundle has seven exact members: canonical input, manifest, issuer envelope, prepared artifact, portable core, result artifact, and derived summary. It has no rule source, raw input JSON, private key, timestamp, route, or action token. Native can issue, inspect, authenticate, and replay it. npm can inspect and authenticate it offline, but cannot issue or replay it. The browser and Playground do not expose this verification module.

The authentication report keeps package integrity, signature and policy admission, exact request binding, fresh replay, replay prevention, and external-action authority separate. rule authenticate does not execute the rule: fresh replay is not-performed, replay prevention is not-provided, and external-action authority is absent. The issuer label is descriptive, unsigned metadata.

Decision authentication and Vouch are different workflows

The portable core binds the semantic rule, canonical input, limits, exact evaluator artifact, and deterministic outcome. That is enough to check what was evaluated.

The optional decision envelope authenticates one exact key admitted by the recipient policy. It does not establish an organization, freshness, fairness, replay prevention, or permission to act. Vouch is a separate workflow with its own authentication and request binding. Evidence from either workflow stays evidence; neither ever turns into permission to act.

Where the command is available

The rule workflow and decision issuance/replay are provided by the Native product. npm additionally provides verification-only decision inspect and decision authenticate. Public browser WASM and the Playground do not expose these decision commands.

The Playground's first-decision mode can download an exact source-bearing authoring handoff for the selected input. Extract it into a fresh directory and run the included explicit command to enter this Native workflow. That ZIP is preparation material, not a decision directory, portable core, signature, or authority.

Keep going

Build a rule step by step in First decision rule, or inspect the frozen contract in Bounded Evaluator Contract.