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.
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.lpxfullThis 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.
{
"raw_source_bytes": 4096,
"prepare_work": 1000000,
"logical_allocation": 1000000,
"syntax_depth": 64
}Then prepare the source.
lispex embed prepare \
--source policy.lspx \
--limits prepare-limits.json \
--out policy.lpxembedPreparation 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.
{
"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.
lispex embed evaluate \
--prepared policy.lpxembed \
--input input.lpxvalue \
--limits evaluation-limits.json \
--out result.lpxembedPreparation 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
lispex embed inspect --artifact result.lpxembed
lispex embed verify --artifact result.lpxembedinspect 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
| Category | Meaning | Portable core |
|---|---|---|
| deterministic semantic outcome | values, a runtime diagnostic, a resource exhaustion, or a nonportable result was reached deterministically | yes |
| deterministic request refusal | the exact request was rejected before an admitted evaluation | yes |
| operational interruption | the caller cancelled or the executor stopped before settlement | no |
| engine fault | the program that runs the rule, the binary interface, the allocator, or the safety ceiling failed | no |
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.