Evidence
What the repository proves, and what it does not.
Limen now has stronger existence evidence than the old site showed: this website itself runs its application logic in F# WebAssembly behind the real kernel. That is useful. It is still not a controlled benchmark, and this page does not turn it into one.
Evidence discipline
Four categories, kept separate.
A structural property is not automatically a measured outcome.
| Class | Meaning | Example |
|---|---|---|
| Mechanically verified | A build/test/check fails if the property is false. | The Pages artifact must contain the F# WASM runtime and must not contain the old TypeScript site engine. |
| Existence proof | A real implementation demonstrates feasibility once, without proving superiority. | The Limen site and the time-entry consumer both run F# engines behind EngineTransport. |
| Structural consequence | Follows from the architecture when its rules hold. | The DOM cannot be authoritative application state if all application decisions are owned by the engine. |
| Measured outcome | Requires a controlled or otherwise attributable observation. | Development time, defects, rework, context, tokens, cost, performance. |
L-1 · self-hosting
This site is now a real F# WebAssembly Limen application.
Mechanically verified existence proof.
site/fsharp/Limen.Site.Engine/site/fsharp/Limen.Site.Wasm/BrowserKernel + explicit effectssite/app/engine.jsThe F# engine drives release gating, evidence obligations, stale-result rejection, ambiguous deployment outcomes, reconciliation, the placement challenge, and the visible transition trace. TypeScript on the site side loads the runtime and transports serialized protocol messages; it does not contain those application concepts.
CI compiles and executes the F# engine tests, publishes the WebAssembly
runtime into dist-site/wasm/, requires a real .wasm artifact,
and fails if the legacy TypeScript application engine returns.
What this establishes: Limen's protocol and transport seam can host a real F# WebAssembly application with nontrivial state inside the Limen repository itself. What it does not establish: that this is faster, cheaper, smaller, easier, or less defective than another architecture — or that the boundary is language-neutral in practice. No C# or Rust engine has crossed it yet; that multi-guest proof is accepted future work, listed below.
L-2 · federated F# WebAssembly
Two independent F# WASM state systems now compose through Limen.
Mechanically verified real-browser existence proof.
runtimeId valuesModuleFederation validates and routes without interpreting payload meaningThe federation proof publishes a source module and a target module as separate .NET WebAssembly applications. The source requests a transition with an expected target state version. The target owns the legality check, advances its own state, and emits a versioned accepted result. Limen routes that result back to the source, which updates only its own state.
CI verifies the module behavior outside the browser and then runs the assembled artifact in real Chrome. The browser gate requires two distinct runtime identities and fails unless the request/result exchange reaches a completed source snapshot and an advanced target state version.
What this establishes: independently loaded F# WebAssembly state systems can compose through Limen without shared mutable domain state. What it does not establish: that splitting every application into multiple modules is desirable, or that federation improves startup time or runtime performance.
L-3 · external consumer
The boundary also works outside its own showcase.
Observed existence proof in time-entry-state-machine.
The separate time-entry application loads a .NET WebAssembly runtime,
forwards Limen messages through a tiny transport, and executes an F#
engine behind a single [JSExport] marshalling method. That consumer
existed before the site conversion and required no application-specific
change to BrowserKernel.
One browser boundary, multiple application engines. The seam is real; superiority is still an open empirical question.
L-4 · a defect that changed the kernel
Real use found a silent binding failure.
Observed once, then converted into a regression check.
The time-entry consumer once put data-if directly on a
<p>. Limen only interprets conditional rendering on
<template>, so the attribute was silently ignored. The live page
exposed the defect when tests did not.
That incident did not justify a defect-rate claim. It justified a product
change: misplaced data-if/data-each now surface a binding
error and have regression coverage.
Structural evidence
What follows from the current implementation.
Useful, but not presented as measured improvement.
Application decisions are out of the DOM layer
The site's browser-side files contain no release, stale-evidence, reconciliation, or quiz decision vocabulary. Those concepts live in F#.
Effects cross explicitly
The F# engine requests effects as protocol data. Limen performs them and returns classified evidence with correlation IDs.
Unsupported authority is visible
The challenge includes clipboard read and programmatic focus specifically because Limen does not expose them. The correct answer is a protocol change, not a hidden browser call.
Unknown outcomes remain representable
OutcomeUnknown is distinct from failure and is projected as unresolved reconciliation work rather than an automatic retry.
Not measured
Claims this site still refuses to make.
The conversion to F# WebAssembly does not change this list.
“Limen reduces development time.”
Not measured. No controlled construction comparison isolates Limen.
“Limen reduces defects.”
Not measured. Existing defects and fixes are observations, not a comparative rate.
“Limen saves tokens or context.”
Not measured. The relevant agent telemetry has not been available consistently enough to support this claim.
“F# WASM is faster than TypeScript.”
Not measured. This work establishes an architectural boundary, not a runtime-performance result.
“Agents understand Limen better.”
Not measured. Documentation usability and architecture checks are not an agent-accuracy experiment.
“This produces better UIs.”
Not measured. Visual quality requires its own evaluation; Limen governs authority and mechanics, not taste.
Comparative claims
An architectural comparison is not measured superiority.
The Why Limen page compares design constraints. This table records what that comparison does not show.
The comparison with React and Angular identifies different design constraints and their structural consequences. It has not been tested experimentally. Every outcome below needs controlled evidence before this site will claim it.
| Claim | Status | What would be needed |
|---|---|---|
| Lower defect rate | Not established | Defects by discovery stage under matched requirements |
| Faster development | Not established | A controlled construction comparison with effort held constant |
| Lower token usage | Not established | Consistently exposed agent telemetry on both arms |
| Better agent accuracy | Not established | Preregistered agent tasks scored by an independent pass |
| Faster runtime | Not established | Benchmarks on equivalent applications and hardware |
| Smaller bundle | Not established | Size measurement of equivalent applications, including the WASM runtime |
| Lower cost | Not established | Attributable cost data across the full lifecycle |
Accepted evidence work
Planned work. None of it is a result yet, and none of it promises an outcome.
#17
Multi-language WASM conformance
Minimal F#, C#, and Rust engines negotiating the same contract.
#17, #32
Cross-language golden vectors
One set of positive and negative wire cases every guest must pass.
#19
Minimal-Core footprint
Recorded size and runtime of the smallest Limen application, so growth is visible.
#51
Guarded Focus reference capability
One small capability built end to end under the full guardrail workflow.
Proposed
Controlled framework comparison
Only when preregistered and designed to isolate the architecture — see below.
Adjacent evidence
Ordo/SDE results are still not Limen results.
The distinction remains important even when the architectures complement each other.
Echelon Foundry's engineering experiments include useful results about heterogeneous verification, explicit state, and construction method. Those experiments did not isolate Limen. The strongest direct result in that corpus remains the fresh-agent verification pass that found five findings with zero overlap with the builder's own 90-test suite, four of them real defects. That supports heterogeneous verification on that run; it does not support a Limen effectiveness percentage.
The experiment worth running
Compare the boundary, not the marketing.
A useful next Limen experiment would hold requirements, model, effort, and verification constant while changing the browser architecture. Preregister the predictions and let an independent pass inspect both.
- 01Same requirement set and starting constraints.
- 02Limen WASM-engine arm versus a conventional browser-state architecture such as React or Angular.
- 03Measure time, files inspected/changed, build cycles, rework, defects by discovery stage, and escapes.
- 04Record model identity and token/cost data only when actually exposed.
- 05Freeze predictions before either arm begins.
- 06Run heterogeneous verification on both.
Repository-level provenance and the longer evidence accounting remain in docs/19-evidence.md.