Writing Decision Rules

This page describes v1.14. Verify whether it is the current manual at /version.json

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.

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.

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

It does not establish who supplied the rule, whether the request is fresh, whether the business policy is fair, whether replay has been prevented, or whether an external action is allowed. Vouch is the separate authenticated, request-bound workflow; even Vouch evidence does not promote itself into external authority.

Where the command is available

The rule workflow is provided by the Native product. npm, public WASM, the browser, and the Playground teach or run other supported surfaces but do not expose these Native commands.

Keep going

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