APPLIED OVERLIFT A09 · LOCAL-FIRST + EDGE AI

Local-First AI Is a Product Strategy, Not a Privacy Checkbox

Local-first AI is often reduced to one promise: the data stays on the device. That promise matters, but it is not enough. A useful product must decide which state belongs locally, which intelligence the actual device can sustain, which remote capability is worth invoking, what fields may leave, how updates reconcile, what happens offline, how storage or GPU loss is recovered, and which authority never moves into a model at all.

Local models + WasmPrivate stateDevice tiersOffline continuityVeluris · Learning Center · Saros · Veil

Local-first does not mean local-only

Local-first is not local-only. A local-first product treats the user’s device as the preferred home for private context, immediate interaction, durable personal state, and qualified intelligence. It does not pretend every workload belongs there. Public source acquisition, large media generation, enterprise systems of record, shared collaboration, and expensive specialized models may still require remote services. The difference is that remote use becomes explicit, minimized, purpose-bound, observable, and recoverable instead of being the invisible default behind every click. This is data minimization as architecture, not merely a privacy label.

This distinction matters because “runs locally” is not the same as “is trustworthy.” A private embedding can still retrieve the wrong concept. A local language model can still invent facts. A browser database can still hold stale doctrine. A device-side recommender can still mistake preference for consent. Execution residency improves privacy, latency, resilience, and cost, but it does not replace source authority, policy, evaluation, or human control.

Keep private context and useful intelligence close to the person. Use remote capability deliberately. Never let location of execution erase authority.

In OverLift, a local model may propose, rank, personalize, clarify, explain, or abstain. Source-reviewed doctrine, accepted product state, current consent, exact calculations, document permissions, typed actions, and real-world postconditions retain their declared owners whether the candidate ran on a phone, a browser worker, an edge service, or a cloud model.

Why local-first is a product strategy

Privacy is one reason to move intelligence toward the device, but the product case is broader. Local execution can shorten the interaction loop, preserve useful behavior during network loss, avoid mandatory per-request provider cost, reduce exposure of intimate context, and make the system feel like a durable personal tool rather than a temporary remote session. It can also make failure easier to understand: the product knows which pack, model, database, and capability profile were available at the moment of the decision.

Local-first also changes what can become a moat. A hosted model is available to every competitor. A governed local corpus, versioned doctrine, private longitudinal state, device-qualified inference path, deterministic fallback, exact receipts, and a product-specific evaluation set are harder to copy. They accumulate through use without requiring the product to centralize every private interaction.

The strategy should remain honest. Local assets increase download size, storage pressure, upgrade complexity, memory use, energy consumption, and support burden. Browser storage can be evicted. Workers can restart. GPU devices can be lost. Model compatibility varies. A local-first product earns trust only when it measures those realities, publishes its device tiers, detects capability loss, and degrades without silently changing truth.

One architecture for local state, local intelligence, remote capability, and exact authority

The architecture begins by separating four things that many products collapse together.

  • Local state is the user or product context stored on the device: a learner’s progress, a private social profile, a document object graph, a birth chart, a research notebook, a cached evidence pack, or an accepted receipt.
  • Local intelligence is the qualified computation that can run against that state: exact and lexical search, C17/WebAssembly kernels, embeddings, compact classifiers, deterministic fusion, Q-Lens path comparison, and authored compilers.
  • Remote capability is a deliberately invoked service: public source refresh, enterprise API, large model, image generator, shared system of record, or provider-specific action.
  • Authority is the rule that decides what becomes real: current consent, canonical doctrine, source identity, accepted revision, exact world state, approved tool, or verified postcondition.

The product probes the actual device before planning. It learns whether WebAssembly, Workers, durable storage, local model assets, SharedArrayBuffer isolation, WebGPU, and required memory are available. It then chooses among qualified paths instead of assuming the most ambitious path will work everywhere.

Data egress is field-level and purpose-specific. A venue refresh may need a public venue ID, coarse region, and requested fields; it does not need a person’s full dating history. A selected paragraph rewrite may need a redacted excerpt; it does not need the entire confidential document. A source update may need a public manifest request; it does not need a learner’s wrong-answer history. The receipt records what left, why, which service received it, and what authority remained local.

Device tiers turn graceful degradation into a product contract

I use device tiers because “works in the browser” is too vague. A low tier should still provide exact access and honest failure behavior. A middle tier can add compact semantics and durable personal state. A high tier can add richer models and GPU acceleration after qualification.

TierExpected capabilityPermanent boundary
Tier LExact and lexical retrieval, graph traversal, C17/WebAssembly, authored deterministic compiler, inspectable fallbackNo feature may pretend a missing model ran; canonical access and authority remain available.
Tier MTier L plus local embeddings, compact classifiers, private progress/history, durable local database, bounded semantic rerankingLocal learned signals remain proposals and must preserve fallback parity.
Tier HTier M plus larger local packs, qualified WebGPU inference or compute, richer offline behavior, faster multi-path comparisonAcceleration may change latency and capacity, not evidence, consent, doctrine, or accepted state.

Tiering avoids two bad products. One ships a large neural path and quietly fails on half the devices. The other reduces every browser to the lowest common denominator and leaves capable hardware unused. A qualified tier system supports progressive capability while preserving one authority contract.

Fallback is explicit. If WebGPU initialization, compilation, device use, or presentation fails, the product may use a qualified WebAssembly CPU path. It should not choose a fallback merely because it is easier during development, and it should not repeatedly retry a broken GPU path while blocking the user. The fallback receipt records the capability probe, failed path, admitted replacement, evidence-set parity, and recovery state.

Veluris: private social intelligence without exporting the person

Veluris makes the local-first argument concrete because dating and social discovery involve highly sensitive context. A useful system may learn that someone prefers small public events, needs an accessible venue, dislikes loud bars, or is open to meeting people through a shared activity. That context can improve recommendations. It should not become a centralized dossier by default, and it should never become permission to disclose, introduce, message, or judge another person.

The preferred Veluris architecture keeps explicit preferences, rejection history, private notes, message drafts, safety context, and Q-Lens plan state in a local profile vault. Public event and venue packs can also be cached locally for fast discovery and offline continuity. Local retrieval and plan comparison can answer a bounded request such as “show me a respectful public plan for tonight” without uploading the private social profile.

When freshness is needed, the remote request is minimized. The adapter may receive a public venue ID, a coarse region, and the fields the user asked to refresh. Preference scoring and final plan comparison happen locally after the public response returns. The system preserves which facts came from the public source, which preferences were explicit, what was inferred, what remained unknown, and which consent would be required for a later action.

Discovery, matching, drafting, introduction, disclosure, contact, and sending remain separate capabilities. A local system may privately draft an opening. It may not send it. It may notice shared interests. It may not declare compatibility as fact. It may recommend a public event. It may not reveal why another person was suggested if that explanation would disclose private context. Local-first strengthens the privacy boundary; human authority completes it.

The Agentic AI Glossary & Learning Center: private adaptive learning without mutable doctrine

The Learning Center already has a natural local-first shape. Canonical terms, source identities, lifecycle status, typed relationships, prerequisite graphs, comparisons, and authored lessons can live in versioned same-origin packs. Exact, lexical, graph, MiniLM, C17/WebAssembly, CATS, Tier-S, and Q-Lens paths can run in the browser. Learner goals, saved routes, wrong answers, misconception evidence, notes, and verified progress can remain private to the device.

That local state makes the system more useful. It can notice that a learner understands retrieval but confuses tool connectivity with permission. It can recommend Capability, Authorization, and Deterministic Authority before returning to MCP. It can avoid repeating a lesson the learner has already completed. It can explain why one path was selected and why another was deferred.

But the authority boundary is strict. The learner-state model cannot redefine MCP. It cannot rename a canonical term. It cannot hide that a standard changed lifecycle status. It cannot silently mark a prerequisite mastered. Source-reviewed doctrine and verified learner evidence remain authoritative.

Updates are reconciled rather than overwritten. A new signed doctrine pack enters quarantine, passes hash and graph checks, and migrates local progress by canonical concept ID. An earlier explanation receipt remains an exact record of what the old pack supported at that time. The current product can say both “this was the explanation then” and “the source status changed later” without corrupting either.

Synchronization must preserve identity and temporal truth

Sync is one of the most dangerous words in local-first architecture because it sounds like a transport problem. It is usually an authority problem. Two states may disagree because one is newer, one is more authoritative, one has user edits, one contains a correction, or one belongs to a different identity. Blind last-write-wins behavior can erase the exact state the product was supposed to protect.

An OverLift synchronization plan binds canonical IDs, source versions, effective and received times, rights, user-authored changes, conflicts, migrations, and postconditions. Incoming data is a candidate state. The system compares it with local state, materializes the delta, asks for human resolution when required, and activates only after the new state passes integrity and authority checks.

Saros illustrates the temporal case. While offline, it can answer from the last admitted evidence state and say exactly when that state was current. When new filings arrive, they create a new evidence state and a typed conclusion delta. The earlier receipt is not rewritten to make the system look prescient.

The same rule applies to Veluris event freshness, Learning Center doctrine, Veil readings, Vellucent document revisions, and local model packs. Updates change current capability. They do not change what was actually known or accepted earlier.

Offline continuity, storage eviction, and recovery are normal product states

Local-first products must assume that workers restart, storage quotas change, cached assets disappear, tabs contend for a database, a model shard fails integrity, and a GPU device is lost. Those are not exotic incidents. They are part of the operating environment.

Service workers can support offline application delivery, but their lifecycle is event-driven and restartable. Durable browser databases need bounded transactions, explicit migration, and recovery. SQLite’s WebAssembly persistence options expose real concurrency and worker constraints. A product that ignores those constraints can deadlock, lose updates, or mislabel a transient cache as durable personal state.

Recovery begins with detection. The product compares the local asset manifest, pack hashes, database schema, accepted state, and capability profile. Missing optional assets may be rehydrated when connectivity returns. Corrupt assets are quarantined. Canonical data and user state are never silently replaced by an unverified download. If the high-tier model is unavailable, the qualified lower-tier path continues and the receipt shows the downgrade.

Offline continuity also requires editorial discipline. The UI should explain the as-of time, missing refresh, unavailable remote action, or reduced model tier without presenting the product as broken. It should preserve meaningful work locally and make the next recovery step clear.

Local-first changes the cost and business model

A product with useful browser-local intelligence can provide recurring value without attaching a provider invoice to every question. That can improve gross margin, reduce exposure to provider outages or pricing changes, and make free or lower-priced tiers more capable. It also allows metered remote services to become optional premium actions rather than mandatory infrastructure.

The cost does not disappear. It moves. Larger downloads, storage, device support, compatibility testing, model preparation, content packs, migrations, battery use, and customer support all matter. A truthful economic model includes asset delivery, local energy, engineering and review, optional cloud calls, and recovery—not merely hosted token cost.

For Veluris, local planning and private preference understanding can create daily value while remote event refresh remains bounded. For the Learning Center, the canonical corpus, semantic model, and private progress can deliver ongoing learning with little mandatory cloud cost. For Vellucent and Veil, local-first becomes a product differentiator because the most sensitive material can remain on device while explicitly chosen provider actions create metered upside.

A local capability must still earn admission

Local assets are not promoted because they feel private or technologically impressive. Each model, classifier, database, doctrine pack, fallback, and device tier is measured for quality, authority preservation, privacy, latency, memory, storage, energy, offline behavior, integrity, upgrade, accessibility, recovery, and unused payload.

A larger local model is worthwhile only when it improves the fixed evaluation set on qualified devices without changing the admitted evidence set or weakening fallback. A new pack is worthwhile only when its content is reachable, source-backed, versioned, and used. A GPU path is worthwhile only when it materially improves work and can fail cleanly. Local-first becomes defensible when the product can prove not only that the intelligence ran nearby, but that it produced a better bounded result and recovered honestly.

The local-first rulePrefer the device for private context, immediate interaction, qualified intelligence, and offline continuity. Use remote services for explicit, minimized work. Reconcile updates by identity and time. Preserve exact authority, rollback, and recovery everywhere.

Primary technical references