Running and Checking Decision Records

One run under limits, one record kept

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 a separate engine that pulls in nothing from outside itself and must account for every unit of work and allocation inside limits you declare. What remains is a decision directory with five members. They are the prepared rule artifact, the input written down in a fixed form so the same request can be recognized later, the deterministic result with its exact request binding, the part of the record you can hand to someone else, and a derived summary. The raw rule source is deliberately not among them.

01Reviewed rule
02Strict JSON input
03A decision of allow
04A record you can check

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 run under limits

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 day-14 unopened case kept with this page, the 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 engine instance, and requires the same result. None of the three confers authority.

What the part you hand on ties together

It ties together the meaning of the rule, the input in its fixed written-down form, the exact limits, the exact program that ran the rule, and the outcome that comes out the same every time. That is 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. It asks 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 instance of the program that runs the rule, and requires the same result

The directory contains the prepared artifact, the input in its byte-exact form, the deterministic result with its exact request binding, an eligible portable core, and a derived summary that carries no authority. The portable core is the part that holds the rule, its input, its limits, and its result together, which is enough to check what was evaluated. The directory 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

Native can put the exact decision material and issuer envelope into one size-limited .lpxdecision file whose layout is fixed down to the byte, 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 exactly seven members. They are the byte-exact input, the manifest, the issuer envelope, the prepared artifact, the portable core, the result artifact, and the derived summary. It has no rule source, raw input JSON, private key, timestamp, engine choice, 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, so 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, the byte-exact input, the limits, the exact artifact of the program that runs the rule, and the 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, and neither ever turns into permission to act.

Where the command is available

The rule workflow, decision issuance, and decision replay are provided by the Native product. npm additionally provides decision inspect and decision authenticate, which only check and never execute. The public browser WebAssembly build 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 read the frozen contract for the small engine that runs one rule under limits you declare in Bounded Evaluator Contract.