The OverLift WASM Kernel

02 · Product and marketing promise

People do not buy a kernel. They buy what the kernel lets the product promise.

Most users will never see a .wasm file. They should not have to. They experience the Kernel indirectly when a product behaves with unusual discipline.

A Vellucent reviewer asks AI to improve a sentence, and the system protects the number, date, citation, defined term, and original document. A logistics operator asks what should happen to a disrupted shipment, and the agent can investigate and propose without silently dispatching freight or issuing a credit. A Neon Drift player reveals an escape pattern, and VANTA-9 changes the hunt without gaining illegal knowledge or breaking collision rules. A semantic search system understands imperfect wording, but it can still abstain when the evidence is weak, stale, excluded, or unauthorized.

The Kernel is not the visible hero. It is the reason the visible hero can make a stronger claim:

• More useful intelligence because models and semantic systems have room to explore.
• Smaller authority because data, tools, actions, and state transitions remain explicit.
• Better privacy because meaningful first-pass work can remain in the browser, origin, device, or organization-controlled boundary.
• Better failure behavior because unavailable models, corrupted caches, rejected evidence, and divergent accelerators do not have to become catastrophic product failures.
• Better proof because the system can show what it knew, what it rejected, what it proposed, what authority admitted, and what actually changed.

The marketing advantage is not “we use WebAssembly.” The advantage is a product that can be ambitious without becoming vague about control.

03 · Business and executive case

Controlled ambition is a business capability.

Organizations want AI systems to search more deeply, personalize more effectively, accelerate decisions, reduce repetitive work, and operate closer to the user. They also need to prevent unauthorized disclosure, duplicate actions, unsupported decisions, stale evidence, runaway cost, brittle provider dependencies, and failures that cannot be reconstructed.

Those are not merely governance concerns to be documented after the product is built. They are product requirements that shape adoption, operating cost, incident response, customer trust, and the speed at which a promising prototype can become dependable software.

The Kernel therefore acts as a stable contract beneath changing models and providers. A team can replace an embedding model, add a planner, introduce WebGPU acceleration, or route a difficult request to an external provider without automatically changing who owns official state.

04 · Architecture

Possibility above. Authority below.

The central OverLift separation is simple enough to draw in one line:

human request
    -> typed plan
    -> admitted evidence
    -> candidate paths
    -> WASM Kernel validation
    -> approval when required
    -> exact action
    -> postcondition verification
    -> receipt and replay

The model does not disappear from this architecture. It is used where probability is valuable: interpreting language, proposing classifications, discovering relationships, drafting explanations, estimating likely outcomes, and comparing alternatives. The Kernel is used where ambiguity becomes dangerous: identity, permissions, canonical facts, numerical policy, legal actions, deterministic state transitions, idempotency, and proof.

That distinction creates four architectural layers:

1. Experience layer. The browser interface receives the user’s question, displays evidence, communicates uncertainty, collects approval, and explains the outcome.
2. Intelligence layer. Exact search, embeddings, graph traversal, classifiers, planners, or models generate candidate interpretations and actions.
3. Authority layer. Focused WebAssembly kernels validate the typed request against authoritative state, policy, capability, revision, and numerical rules.
4. Proof layer. The system records the decisive identities and hashes needed to inspect, compare, replay, recover, or dispute the result.

OverLift does not require every system to use the same model or the same kernel. It requires the boundary to remain explicit. A probabilistic component may make a brilliant proposal. It does not become authoritative merely because the proposal is convincing.

05 · Why WebAssembly belongs in the browser engine room

WebAssembly gives the browser a compact, validated execution format. OverLift gives that execution a job.

The WebAssembly core specification defines a portable low-level format with validation and execution semantics. The JavaScript interface defines how a host compiles, instantiates, imports, exports, and interacts with modules. That foundation is valuable because it lets small, purpose-built kernels run close to browser-local data and interactive state without turning the DOM, network, storage, or application services into ambient module powers.

WebAssembly itself does not know what a shipment, PDF sentence, game action, citation, or emulator register means. The surrounding application supplies that product meaning through a deliberately narrow ABI. OverLift uses the Wasm boundary for exact work such as:

• bounded state machines and legal transitions;
• integer or controlled numerical calculations;
• deterministic retrieval and ranking references;
• proposal admission and refusal;
• geospatial coordinate contracts;
• game and simulation action compilation;
• machine emulation and compatibility references;
• state hashing, receipt material, and replay witnesses.

Several current portfolio kernels are compiled from freestanding C17 with no standard library, no allocator dependency, and no imported network, filesystem, clock, locale, or random source. That is not because C is magically safe. It is because a small source surface, a fixed ABI, explicit memory, and an import-free module make the authority path easier to inspect and test.

06 · The OverLift Method

The Kernel is where the Method stops being a diagram.

The OverLift Method begins before execution. It clarifies the question, identifies the permitted evidence, exposes missing or conflicting facts, creates typed candidate paths, and separates interpretation from authority. The Kernel then gives the Method a precise place to decide what may proceed.

In practical terms, the Kernel asks questions that a model should not answer about itself:

• Is this the authenticated principal, or merely a name mentioned in prompt text?
• Is the evidence admitted, current, authorized, and bound to the expected source revision?
• Is the proposed action one of the host-declared legal operations?
• Are the parameters in range, internally consistent, and complete?
• Does policy require approval, and is that approval bound to this exact action and current state?
• Has the request already executed, or does an equivalent business object already exist?
• Can the postcondition be verified after execution?
• What receipt must survive so the result can be replayed or challenged?

This is deterministic authority: not the claim that the entire world is deterministic, but the design decision that consequential admission and state change follow explicit, testable rules outside probabilistic control.

07 · Browser-based agentic AI

An agent needs more than a loop. It needs a constitution.

Agent frameworks are good at coordinating work: plan, retrieve, call a tool, observe, revise, hand off, and continue. But a durable product also needs to know which identity is real, which evidence is admissible, which tools exist, which parameters are legal, which action requires approval, which state is current, and what must happen if the world changes while an agent is thinking.

The browser is increasingly capable of hosting much of that system locally: user interface, reviewed corpora, vector evidence, ONNX inference, Workers, WebAssembly kernels, WebGPU compute, IndexedDB or OPFS state, secure same-origin assets, and deterministic fallback paths. The result is not “a chatbot in a tab.” It is a complete application runtime in which private context can remain close to the user and external disclosure can be deliberate rather than automatic.

The Kernel matters because agentic intelligence is most useful when it can do substantial exploratory work without receiving ambient authority. An agent may:

• ask for admitted evidence handles, not unrestricted data access;
• choose from declared tools, not invent executable verbs;
• propose an operation, not directly mutate canonical state;
• wait, refuse, clarify, or abstain without being treated as broken;
• survive a model outage through exact fallback behavior;
• leave a receipt that distinguishes proposed, blocked, pending, duplicate, executed, and verified outcomes.

Prompt injection remains content. Similarity remains a proposal. Approval remains a revalidation point. The Kernel remains the authority boundary.

08 · Product proof

One constitution, several focused kernels

The packaged portfolio contains multiple small WebAssembly modules rather than a single monolith. Their exact byte sizes are useful because they make the architecture concrete.

The table reveals an important design principle: authority should be narrow enough to name. The Meaning Vault does not own official answers. The visual kernel does not own business facts. The globe renderer does not own geospatial truth. Each component has a declared job and a declared non-job.

The same pattern appears in the products:

• OverLift Logistics: agentic investigation and scenario comparison above exact policy, calculations, approvals, duplicate protection, commit, and outcome receipts.
• Vellucent: semantic document proposals above page-aware evidence, Meaning Lock, immutable originals, admitted operations, and verified derived revisions.
• Semantic Search: exact and learned retrieval above rights, freshness, source identity, deterministic fusion, citation, and abstention.
• Neon Drift and CITADEL: adaptive tactics and personality above typed legal actions, fairness, collision, score, timing, and authoritative world state.
• Saros: learned interpretation above point-in-time evidence, deterministic calculations, governed research transitions, and reproducible conclusions.
• OverLift emulators: optimized browser execution above exact machine state, compatibility evidence, shadow comparison, and replay.

09 · Technical treatise

Inside the contract

1. Module identity is part of the result

An authoritative module must be identifiable. The current kernels export ABI versions and build identifiers; companion manifests record source hashes, binary hashes, compiler commands, memory sizes, capacities, and authority notes. A replay that silently substitutes different code is not the same replay.

Module identity also matters for recovery. A service worker or browser cache may hold an old or corrupted asset. The host must know whether to load, reject, refetch, or fall back. “The file existed” is not a sufficient integrity check for an authority component.

2. The ABI is a constitutional border

The host and module communicate through an application binary interface: exported functions, imported capabilities, typed numeric values, and offsets into linear memory. The ABI should be versioned and deliberately small. Every pointer-like value is an offset, every length is checked, and every enum or bitmask has a defined range.

typedef struct {
    uint32_t abi_version;
    uint32_t request_kind;
    uint64_t request_id;
    uint64_t authoritative_revision;
    uint32_t evidence_offset;
    uint32_t evidence_length;
    uint32_t capability_mask;
    uint32_t deadline_ticks;
} overlift_request_v1;

typedef struct {
    uint32_t verdict;        /* refuse, review, approve, duplicate */
    uint32_t action_kind;
    uint64_t result_revision;
    uint32_t receipt_offset;
    uint32_t receipt_length;
} overlift_result_v1;

The structure is illustrative, but the rule is real: the module should not infer authority from the mere presence of bytes. Evidence identity, capability, state revision, and request kind must travel explicitly.

3. Linear memory is not host memory

Core WebAssembly modules operate over their own linear memory. The host may copy approved data into that memory or expose shared memory under a separate contract. The module does not automatically receive DOM access, network access, cookies, environment variables, files, or application objects. Those powers exist only through host APIs and imports.

This is useful, but it is not magic. A host can still hand the module a secret, expose an unsafe generic import, trust an unchecked output, or retain a stale view after memory growth. The security story therefore includes both sides of the ABI.

4. Determinism requires an envelope

“Wasm is deterministic” is too loose to be useful. A reproducible result depends on controlled inputs: module build, ABI version, initial state, event ordering, evidence identities, configuration, numerical policy, clock values, random seeds, locale-independent parsing, and the host operations that participate.

OverLift defines a determinism envelope for each authority path. Some kernels avoid wall clocks, randomness, locale, allocation, and imports entirely. Others accept time or seeds as explicit inputs so they can be recorded. Floating-point work is either bounded by a documented tolerance or compared with an exact reference where exact identity is required.

5. Tie-breaks are architecture

The 1,878-byte Meaning Vault contains a small rule with large consequences. It scans quantized vectors and inserts each candidate into a bounded top-k list. When two scores are equal, the lower stable record index wins:

if (score > omv_scores[position]
    || (score == omv_scores[position]
        && record_index < omv_indices[position])) {
    /* insert candidate into the bounded top-k list */
}

Without that tie-break, equal scores could appear in a different order after a refactor, runtime change, or alternate iteration strategy. The answer might look equally plausible while the receipt, cache key, or downstream action changes. Determinism often lives in rules this small.

6. Capabilities belong to the host contract

A browser module that has no imports has no direct route to network, storage, DOM, or privileged application services. A module with imports can do only what those imports make possible. That makes imports the capability surface.

OverLift favors purpose-built capabilities over ambient powers. “Read evidence handle 17” is safer than “fetch any URL.” “Return the current shipment revision” is safer than “run SQL.” “Emit a candidate receipt” is safer than “write arbitrary application state.” A capability can also carry budget, scope, deadline, principal, and revocation information.

WASI extends the broader Wasm ecosystem with standardized interfaces and capability-oriented security, but browser-hosted OverLift kernels do not need to pretend they are WASI applications. Core Wasm plus the JavaScript host API is sufficient for many focused in-browser authority paths. The distinction should remain explicit.

7. Workers separate responsibility as well as threads

A Worker can own a kernel, its memory, and its state machine while the main thread owns presentation and user interaction. That separation protects responsiveness and makes lifecycle rules clearer. The host can terminate a worker, recreate a module, verify a manifest, restore a checkpoint, and replay events without giving the module control of the page.

SharedArrayBuffer is useful for high-frequency, bounded data such as snapshots or audio/video rings when cross-origin isolation is available. It is not a universal communication strategy. Dialogue, policy decisions, approvals, and low-frequency directives are usually clearer through typed messages. The transport should match the authority and frequency of the data.

8. Speed must earn authority

OverLift treats optimization as a portfolio of execution paths. T0 is the exact reference. T1–T7 represent progressively faster or more specialized paths: SIMD loops, worker-owned caches, WebGPU compute, WebGL2 presentation fallbacks, precomputed islands, or product-specific approximations. A faster path is not promoted because a benchmark looked good. It is admitted under conditions where it has proven equivalence to the reference policy.

if admissible(candidate_path, state, configuration):
    candidate = candidate_path(state)

    if shadow_required(state):
        exact = T0(state)
        if not equivalent(candidate, exact, numerical_policy):
            quarantine(candidate_path, state.region)
            emit_divergence_receipt(candidate, exact)
            return exact

    return candidate

return T0(state)

Tier-S is the shadow-truth discipline around that promotion. It compares the accelerated candidate with the reference, records witnesses, quarantines mismatches, and returns to exact behavior. CATS supplies context-aware selection across operating goals such as balanced behavior, efficiency, latency pressure, or proof requirements. Performance is therefore a governed decision, not a permanent transfer of authority.

9. Idempotency and business deduplication are different

Request idempotency asks whether this exact request key has already executed. Business deduplication asks whether an equivalent business object or intent already exists. A caller can generate a new request key for the same business action, and a network retry can reuse the same key after the surrounding state has changed. Serious agentic execution needs both checks.

The Kernel or surrounding exact authority path binds the request to principal, target, revision, action, parameters, approval, and expected postcondition. If any decisive condition changes while approval waits, the operation is revalidated rather than blindly resumed.

10. A receipt is the smallest durable explanation

A chat transcript tells us what a system said. A decision receipt tells us what it was allowed to do, which evidence and policy mattered, whether approval was required, whether the operation was duplicate or blocked, what state changed, and whether the expected result was verified.

A useful receipt can bind:

• request, principal, tenant, and capability identity;
• module build, ABI, policy, corpus, and configuration versions;
• authoritative starting revision and admitted evidence hashes;
• candidate action, exclusions, assumptions, and uncertainty;
• approval identity and the exact operation approved;
• idempotency and business-deduplication verdicts;
• result revision, postcondition evidence, and rollback relationship;
• execution path, Tier-S witness, latency, energy, or cost evidence when relevant.

The receipt is not every log line. It is the durable proof necessary to reconstruct the consequential decision.

10 · Failure behavior

A trustworthy system is defined as much by what happens when intelligence fails.

Models time out. Semantic assets fail to load. Workers crash. Caches corrupt. Providers disappear. Accelerated paths diverge. Evidence becomes stale while approval waits. A strong product does not improvise authority in response.

11 · Honest limits

What WebAssembly and the Kernel do not magically solve

• WebAssembly does not make a wrong algorithm correct.
• A sandbox cannot protect a secret the host deliberately passes into it.
• Explicit imports are only as safe as the host implementations behind them.
• Wasm does not replace authentication, authorization, content security policy, dependency hygiene, secure deployment, or monitoring.
• Runtime defects, supply-chain compromise, memory exhaustion, denial of service, and side channels still require defense in depth.
• Floating-point reproducibility requires a documented numerical policy; it cannot be assumed from the file format.
• A receipt proves the recorded contract and evidence. It cannot prove that an omitted requirement never existed.
• Human approval is not a magic bypass. It should trigger exact revalidation against current state.

The point is not that the Kernel makes software invulnerable. The point is that it creates a smaller, clearer, testable place where consequential authority can be defended.

12 · Implementation guide

A practical checklist for building an authority kernel

1. Name the authoritative state. Write down which facts, identities, revisions, calculations, and transitions cannot be owned by generated text.
2. Define the proposal boundary. Specify what models, embeddings, agents, or rules may suggest and what they may never commit directly.
3. Design typed capabilities. Replace generic fetch, SQL, shell, filesystem, or arbitrary command tools with narrow operations.
4. Version the ABI. Bind exports, imports, memory layouts, enums, bitmasks, numerical rules, and error codes to an explicit version.
5. Bound memory and work. Cap record counts, query sizes, graph depth, top-k, instruction budgets, deadlines, retries, and output sizes.
6. Control nondeterminism. Pass clocks, seeds, locale, ordering, configuration, and external results as explicit recorded inputs.
7. Keep a T0 reference. Make the exact path clear enough to test, compare, and return to when faster paths fail.
8. Require promotion evidence. Admit SIMD, GPU, caches, approximations, and specialized paths only under measured conditions.
9. Separate idempotency from deduplication. Protect both request retries and equivalent business intent.
10. Revalidate at approval and commit. Never assume the world remained unchanged while a person reviewed a proposal.
11. Verify the postcondition. Prove the intended change occurred and that prohibited side effects did not.
12. Seal a useful receipt. Preserve the minimum evidence required for audit, replay, recovery, regression testing, and explanation.
13. Test refusal and failure. Missing evidence, stale state, corrupt modules, unavailable workers, provider outages, malformed inputs, duplicate actions, and divergence are first-class acceptance cases.

14 · Why it matters

Browser-based AI becomes more interesting when its consequences become more exact.

The industry often frames a choice between powerful AI and controlled software. OverLift rejects that tradeoff. Give intelligence room to interpret language, find patterns, compare possibilities, draft work, and surprise us. Give exact kernels the jobs that demand identity, permission, mathematics, legal state, and proof.

That separation does not make the product less agentic. It makes the agent useful in places where consequences matter.

Useful intelligence. Deliberately small power. Exact consequences.

The OverLift WASM Kernel is not a tiny prison for intelligence. It is the strong floor beneath it.

Explore the OverLift Method Read Deterministic Authority Read Browser-Based Agentic AI