This curated history follows the meaningful Lispex v1 implementation line through the v1.7.0 Request-Bound Vouch release, using release tags, version transitions, and implementation commits.
Current guarantees
- The initial v1 line established the deterministic reader, hygienic normalizer, trampoline evaluator, numeric profile, control model, standard-library floor, WASM build, and Playground before the first consolidated v1.2 tag.
- v1.2 grew a second checked execution line around canonical Core, Meaning Graph, decision galleries, differential receipts, offline verification, replay, and mutation-tested evidence boundaries.
- v1.3 turned that foundation into Lispex Vouch and Bridge workflows; v1.4 refreshed the shared native, npm, WASM, Playground, and download surface.
- v1.5 publishes the bounded Lispex-in-Lispex and Lispex-in-Topaz execution lines plus their joint N-way receipt.
- v1.5.2 adds namespaced Vouch commands, the maintained refund-window flow, the current LIL 85/205 boundary, and Native verifier re-execution with authentication and current execution agreement reported separately.
- v1.5.3 adds
lispex vouch gate --require-decision: only a live authenticated current-Native agreement whose observed decision exactly matches the required decision produces a local grant and exit 0. - v1.5.4 adds authenticated flag-free
lispex vouch verifyto npm through a verification-only build of the same Rust core. Native/npm reports and C-VN-06 outcomes are byte-identical for the same bytes; npm still cannot issue, re-execute, gate, or promote a report. - Language, package, and artifact-contract versions are related but do not advance in lockstep.
- The runtime profile owns evaluation behavior, while the named CSK and Vouch contracts own their artifact schemas. A matching package number alone does not establish artifact compatibility.
Meaningful v1 milestones
| Version | Main change | Boundary |
|---|---|---|
| v1.7.0 | publishes Request-Bound Vouch as one consumer-owned journey: derive exact identities, create and check policy, issue a bundle, authenticate it against an optional external source/input request on Native or npm, then re-execute and gate only that live request on Native | unpinned bundle verification remains authentication-only; request equality is not freshness, replay prevention, identity, provenance, policy correctness, or external-action authority |
| v1.6.4 | makes the verification-only npm Vouch WASM regenerate to the same tracked bytes from clean, dirty, or relocated source checkouts and keeps the standalone export-surface audit runnable from a clean checkout | the fixed non-attesting build placeholder and virtual source path are not Git provenance or a reproducible-build claim for Native, browser WASM, or other platforms |
| v1.6.3 | Native bundle re-execution and gate require matching external source/input and pass only live request-bound evidence through re-execution to the grant; the localized documentation refresh adds the /v1.6 public-minor route namespace, Downloads, numbered current/Classic navigation, aligned document surfaces, concise browser titles, balanced responsive hero copy, a Korean 리스펙스 wordmark, and one readable locale-aware display-label system for landing eyebrows, form/data folios, results, pagers, and menu categories | unpinned bundle verify remains authentication-only; request equality is not freshness, intent, or external-action authority |
| v1.6.2 | Native/npm pinned bundle verify authenticates first and then compares separately supplied exact source/input bytes | exact request equality is not freshness, replay prevention, human intent, or external-action authority |
| v1.6.1 | Native/npm vouch key-id, engine-id, and input-id close public identity derivation beside source-id through shared Rust | identity is not provenance, trust, input validation, authentication, evidence, or execution authority |
| v1.6.0 | aggregates portable bundle v0, key-local exact-source policy v1, shared-Rust source-id and policy tooling, and raw/bundle authentication into one consumer-owned Vouch workflow | semantic profile and artifact schemas stay frozen; only Native issues, re-executes, or gates |
| v1.5.8 | Native/npm vouch policy create/check composes and validates canonical consumer trust policy v1 through shared Rust | valid configuration is not trust selection, authentication, evidence, re-execution, a decision grant, or external authority |
| v1.5.7 | Native/npm vouch source-id --source derives the exact bounded-byte source identity through the shared Rust core | derivation is not source approval, policy generation, artifact trust, authentication, or evidence |
| v1.5.6 | trust policy v1 rejects a fully valid signed rule unless its exact source identity is allowed by the selected key | v0 remains source-unconstrained; no input/request approval, freshness, replay prevention, or transferable authority |
| v1.5.5 | bounded canonical envelope/source/input bundle with Native emission/consumption and npm authentication-only consumption | trust/profile/decision remain external; WASM and Playground do not expose Vouch authentication |
| v1.5.4 | npm vouch verify authenticates signed Native envelopes and exact source/input/profile through a verification-only build of the shared Rust core, matching Native v0 report bytes and C-VN-06 outcomes | same-core packaging parity, not an independent witness; npm cannot issue, re-execute, gate, expose live evidence, or promote a serialized report; public WASM and Playground do not export authentication |
| v1.5.3 | Native vouch gate --require-decision requires authentication, current complete-transcript agreement, and an exact decision match before returning a local grant | Native-only local process result; serialized reports, Bridge, and authentication-only evidence cannot grant; no freshness, replay-prevention, identity, policy-correctness, deployment, or external-action authorization claim |
| v1.5.2 | namespaced Vouch workflow, maintained refund-window flow, LIL 85/205 capability boundary, and native vouch verify --reexecute with separate authentication and current-execution agreement | re-execution is native-only and same-Rust-lineage; no historical-execution, freshness, independent-witness, authorization, policy-correctness, or whole-language-equivalence claim |
| v1.5.1 | native Vouch issuance: qualifying checked decisions can be constructed and signed as DSSE envelopes, then authenticated against a consumer-supplied trust policy | native release binaries only; a valid signature authorizes a key for exact checked bytes but does not prove human identity, time, honest deployment, policy correctness, or broader semantic equivalence |
| v1.5.0 | bounded LIL and LIT execution lines, 84-of-205 capability ledgers, a three-family joint receipt, and coordinated native/npm/WASM/Playground distribution | 59 of 144 cases agree across all three families; 179 pair divergences remain disclosed; no whole-language or LIT source-independence claim |
| v1.4.0 | runtime and distribution refresh: apply and multiple-value paths in the checked evaluator, bounded receipt fuel, native/npm/WASM/Playground alignment, and pinned native downloads | previous public release; native and WASM remain the same Rust lineage |
| v1.3.11 | canonical Bridge read-side acceptance, closed-world nested checks, linked artifact and optional context checks | native canonical-reader hardening remained deferred |
| v1.3.10 | adversarial artifact-class checks and explicit authenticity non-goals | no signing, issuer binding, timestamping, or non-repudiation |
| v1.3.9 | twelve-case welfare-style replay evaluation corpus | worked evaluation artifact, not a legal or policy model |
| v1.3.8 | Vouch Bridge report shape, offline checker, and external-engine example | checker does not run or prove the external engine |
| v1.3.1-v1.3.7 | closed the usable Vouch loop: native receipt generation, release-build engine identity, offline verify, versioned replay corpus, and an explicit authenticity boundary | Vouch records declared execution and byte bindings; it does not add signing or issuer trust |
| v1.3.0 | checked-profile decision receipts, offline verify, replay, and release gates | bounded checked profile, not a whole-language correctness claim |
| v1.2.15-v1.2.19 | external Scheme-oracle ledger, authored semantic vectors, strict artifact readers, tamper fixtures, and mutation drills | hardening and measured evidence; not proof of complete Scheme compatibility |
| v1.2.14 | expanded the checked decision profile and gallery with search, rounding, any/all traversal, strict faults, and clearer replay ergonomics | profile execution, not the whole Lispex language surface |
| v1.2.9-v1.2.13 | checked-profile boundary, intrinsic binding, control/arithmetic gallery, closures and traversals, host-input binding, npm offline verify, and replay UX | landed as one consolidated baseline; intermediate numbers were contract milestones rather than separate tags |
| v1.2.2-v1.2.8 | versioned canonical Core, execution receipt, conformance manifest, Meaning Graph and lowering, separate Meaning Environment evaluator, and differential receipt contract | a checked subset and artifact line alongside the reference interpreter, not a replacement for it |
| v1.2.0 | first consolidated v1 tag; added recoverable raise, guard, and with-exception-handler semantics while shipping native, Node/WASM, Playground, and download paths | recoverable handlers use the pinned Lispex control model, not host exceptions |
| Initial v1 implementation line (2026-06-28/29) | deterministic reader, hygienic normalizer, trampoline evaluator, exact integer/rational plus finite-real profile, pinned rendering, one-shot upward call/cc, dynamic-wind, multiple values, proper-tail apply, broad R7RS-shaped procedures, WASM, and Playground | not a v1.0 or v1.1 release; these are dated implementation commits later consolidated into v1.2 |
Boundaries
- The repository has no v1.0 or v1.1 release tags. “Initial v1 implementation line” is therefore a dated implementation milestone, not an invented release.
- The v1.5 integration remains bounded to its named capability rows, host routes, corpora, and receipts.
- The chronology omits prose-only edits, CI churn, hash refreshes, review mechanics, and release rehearsals unless they changed a user-facing capability or a substantive verification boundary.
- Historical receipt and Bridge changes do not imply new language semantics unless a release explicitly says so.