Evaluate an Untrusted Rule

Choose the restricted or the complete current-profile Native engine that runs one rule under limits you declare, apply separate deterministic limits, and verify the portable core that holds the rule, its input, its limits, and its result together.

Choose the product that runs under declared limits

Ordinary lispex rule.lspx remains the built-in interpreter that reads your source directly and covers the full profile. Use lispex embed when the rule must run inside the smaller lispex/r7rs-rule-embedded-core/1 profile under deterministic work and logical-allocation limits.

The restricted Native product contains one exact WebAssembly engine that runs the rule and pulls in nothing from outside itself. You cannot supply a path, discover a replacement, download an engine, or ask for a fallback.

The Downloads page also exposes the exact lispex-embed-evaluator.wasm, its component manifest, golden vectors, and the matching SHA-256 checksum files, for applications that consume the provider bytes directly.

Choose the separate full-profile component explicitly

Use lispex embed full when the rule requires all of lispex-profile-1.5. Its prepared and result files use .lpxfull, and the same five operations sit under their own explicit command name.

SH
lispex embed full prepare --source policy.lspx --limits prepare-limits.json --out policy.lpxfull
lispex embed full evaluate --prepared policy.lpxfull --input input.lpxvalue --limits evaluation-limits.json --out result.lpxfull
lispex embed full inspect --artifact result.lpxfull
lispex embed full verify --artifact result.lpxfull
lispex embed full replay --artifact result.lpxfull

This is a second exact import-free component with lispex/r7rs-rule-current-profile-bounded/1 and lispex-full-vm-meter/1 identities. It covers the generated 205-row closed world and creates a fresh instance for every operation. It does not rename or widen the restricted component. Downloads expose its Wasm, manifest, provider vectors, redistribution archive, and checksums separately.

1. Prepare the rule

Create prepare-limits.json.

JSON
{
  "raw_source_bytes": 4096,
  "prepare_work": 1000000,
  "logical_allocation": 1000000,
  "syntax_depth": 64
}

Then prepare the source.

SH
lispex embed prepare \
  --source policy.lspx \
  --limits prepare-limits.json \
  --out policy.lpxembed

Preparation admits UTF-8, reads and normalizes the program, builds and verifies bytecode in its one accepted form, and checks the restricted profile. It records identities for the submitted source, the source in its one accepted form, the semantic rule, the feature set, the bytecode, the program that runs the rule, and the exact limits. It does not evaluate the rule.

2. Evaluate the prepared rule

The input is one lispex.embed-value/v1 value in its one accepted form. Create evaluation-limits.json.

JSON
{
  "canonical_input_bytes": 4096,
  "eval_work": 1000000,
  "logical_allocation": 1000000,
  "semantic_frames": 1000,
  "traversal_depth": 256,
  "output_bytes": 1000000,
  "diagnostic_bytes": 1000000,
  "transcript_bytes": 1000000,
  "transcript_events": 100,
  "result_bytes": 1000000
}

Evaluate exactly that prepared artifact.

SH
lispex embed evaluate \
  --prepared policy.lpxembed \
  --input input.lpxvalue \
  --limits evaluation-limits.json \
  --out result.lpxembed

Preparation usage never enters evaluation usage. Reusing a prepared artifact therefore cannot change what the evaluation is charged or the portable core. The portable core is the part that holds the rule, its input, its limits, and its result together.

3. Inspect and verify

SH
lispex embed inspect --artifact result.lpxembed
lispex embed verify --artifact result.lpxembed

inspect gives a stable JSON projection. verify recomputes the envelope, exact hashes, category, limits, and portable core without running the rule. Neither command authenticates an issuer or grants Vouch authority.

Read the category first

CategoryMeaningPortable core
deterministic semantic outcomevalues, a runtime diagnostic, a resource exhaustion, or a nonportable result was reached deterministicallyyes
deterministic request refusalthe exact request was rejected before an admitted evaluationyes
operational interruptionthe caller cancelled or the executor stopped before settlementno
engine faultthe program that runs the rule, the binary interface, the allocator, or the safety ceiling failedno

Consumed work is useful as local diagnostics, but it is not inside the portable core. The core binds the exact limits, profile, model, source, input, request, the artifact of the program that runs the rule, the transcript, and the result identities instead.

Boundaries

The first product uses one engine, not in-process agreement. Its bytes are qualified by release-level differential comparisons. The restricted profile is smaller than the full lispex-profile-1.5, and unsupported forms and primitives are refused instead of being delegated elsewhere.

Native and the standalone engine bundle provide this. npm, the public browser WebAssembly wrapper, the Playground, and browser embedding do not. Timing, cache, and microarchitectural side channels are outside the technical guarantee. Host-process survival is an operational goal of the first in-process release, not a security guarantee.

The artifact and core are inspection material. They are not a Vouch signature, authenticated evidence, a gate grant, rule correctness, or permission to perform an external action.

Keep going

Read the exact IDs, axes, categories, and bundle contract for the small engine that runs one rule under limits you declare in Bounded Evaluator Contract.