Writing Decision Rules

One decision, one checkable record

Run the refund rule. Keep what was checked.

The reviewed rule and strict JSON input produce one bounded local decision. The directory keeps the exact prepared rule, canonical input, result, and eligible portable core together.

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

1. Rule

LISPEX

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

2. Input

JSON

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

3. Run locally

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. Decision

The maintained day-14 unopened order returns allow.

5. Check the record

Inspect without execution, verify exact bytes, or replay once in a fresh evaluator instance.

What the core binds

The semantic rule, canonical input, exact limits, evaluator artifact, and deterministic outcome.

What it does not grant

Issuer identity, freshness, policy correctness, replay prevention, or permission for an external action.

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 remains a separate authenticated, request-bound workflow; neither decision authentication nor Vouch evidence promotes itself into external authority.

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.