Locara

00 — Overview

Thesis

Open-source models have crossed a threshold where narrow, opinionated, fully-local applications can deliver real user value. The bottleneck is no longer the models — it’s the missing infrastructure for building, distributing, and trusting them.

Locara fills that gap. It is a framework + runtime + distribution layer for fully-local LLM applications on macOS, with safety as a verifiable property (capability-declared, runtime-enforced) rather than a marketing claim.

What Locara is

Three products, designed together:

  1. Framework — TypeScript SDK + Rust core providing primitives (chat, embed, transcribe, OCR, vision, sqlite + vector search, sandboxed tool exec) and a manifest-driven app spec.
  2. Runtime — Tauri-based shell that hosts apps. Enforces declared capabilities via macOS App Sandbox + Locara-specific layer. Manages model loading, resource arbitration, lifecycle.
  3. Registry — Curated, signed, automatically reviewed catalog where developers publish and users discover apps. Surfaces verifiable properties (privacy badges, device-fit, capability declarations).

These are not loose-coupled. The manifest schema is what makes the registry’s automated review possible. The runtime’s enforcement is what makes the registry’s “fully local” badge meaningful. Designed in lockstep, shipped in sequence.

What Locara is not

  • Not a model registry. (Use Hugging Face. See models.)
  • Not an inference engine. (Wraps llama.cpp + MLX. See models.)
  • Not an agent framework. (SDK provides primitives; agents are user code.)
  • Not a payments platform. (Apps charge through Mac App Store / Stripe / etc.)
  • Not a “build any app” platform. (Narrow, opinionated, fully-local apps. General-purpose desktop apps belong elsewhere.)
  • Not a competitor to Ollama. (Locara is the layer above Ollama-class runtimes.)

The wedge

Safety as a property of the runtime, not a promise.

  • Apps declare capabilities in a structured manifest.
  • Locara CI builds and signs binaries (devs never upload binaries).
  • Static analysis verifies code respects declared capabilities.
  • macOS kernel enforces: no network if not declared, no filesystem outside scope.
  • Locara runtime enforces additional constraints (model access, tool execution).
  • Capability changes on update require user re-consent + cool-down period.

This is engineerable, defensible, and not what any other distribution channel offers. It is the moat.

Audience

Prosumers first. Technically literate, privacy-minded Mac users. Examples: developers off-hours, researchers, lawyers, doctors, journalists, indie creators.

Not:

  • Mass consumers — too early; polish bar will not be met.
  • Developers-as-developers — too narrow framing; Locara is for building products, not just experimenting with LLMs.
  • Enterprises — possible Phase 4+ once core is solid.

The two reference apps (v1)

These are the apps you (the project lead) will write. They:

  1. Validate the framework’s primitive set in two complementary modalities.
  2. Demonstrate the privacy/local pitch viscerally.
  3. Become the launch demos.
AppModalityPrimitives exercised
Transcribeaudio → textSTT (Whisper), chunking, sqlite, search via FTS5 + embedding
DocVaultimage/PDF → structured textOCR, VLM extraction, sqlite + sqlite-vec, chat over corpus

Together they cover ~80% of what future ingestion-style local apps need. See phasing.

Success criteria

For the framework: A developer with prior TS experience can go from locara init to a published, signed, registry-listed app in under one hour for a simple app.

For the runtime: A user installing a Locara app can verify, before clicking install, that the app cannot access the network / filesystem / hardware beyond what its manifest declares — and the OS will deny anything outside that scope.

For the registry: By end of phase 3, the catalog has 10+ apps where each is something a user genuinely uses (not toys). Catalog-quality bar is non-negotiable.

For the project: OSS, low-opex (<$50/mo through phase 3), build-in-public, indie-led. Sustainable as a small team / solo project for years before any revenue question arises.

Stack (committed)

  • Language: Rust (core, runtime, CLI) + TypeScript (SDK, components, app authoring).
  • Desktop framework: Tauri 2.0.
  • Inference: llama.cpp via Rust binding for cross-platform; MLX as primary on Apple Silicon (open: which is v1 default — see models).
  • Storage: SQLite + sqlite-vec by default; zvec as opt-in scale-up.
  • Sandbox: macOS App Sandbox (kernel) + Wasmtime/WASI (tool exec).
  • License: Apache 2.0 throughout.
  • Initial platform: macOS (Apple Silicon-first).

Operating principles

  • Default-deny. Apps start with zero capabilities. Manifest declarations grant; runtime enforces.
  • Agent-friendly by design. The framework is designed assuming the developer is paired with an LLM coding assistant (Cursor, Codex, Claude Code, etc.). Authoring an app should be as easy for an LLM as for a human. See “Agent-friendliness” below.
  • OSS framework + open registry. Closed source breaks the trust pitch. Open spec lets others run alternative registries.
  • No telemetry. Zero phone-home from CLI, runtime, or shipped apps. Privacy is the pitch; compromise is fatal.
  • Stable contracts. Manifest schema and SDK surface are versioned. Breaking changes happen rarely, with months of lead time.
  • Editorial quality > catalog volume. Curated 10 apps that are loved beats 1000 of varying quality.
  • Build-in-public. Public repo, ADRs, weekly devlogs from end of phase 0.

Agent-friendliness (first-class principle)

Locara assumes the developer authoring an app is paired with an LLM coding assistant. The entire framework is designed so this pairing is highly effective — i.e., “build me a fully-local app that does X” should produce a working, signed, publishable Locara app from a natural-language prompt.

Concrete design choices that follow from this:

  1. Closed catalogs over open vocabularies for modality and tooling declarations. An LLM picks from a small, named list (speech-to-text, ocr, filesystem.search) instead of inventing capability strings. Hallucination is structurally impossible. See 04-modalities.md.
  2. Strongly-typed SDK with JSDoc-saturated examples. Every function has examples in its docstring. LLMs see them via Cursor / Claude tab-completion and produce correct first-try code. See 05-sdk.md.
  3. JSON-schema-validated manifest that fits in an LLM context window comfortably. The schema is small enough to attach to a prompt; LLMs can fill it in without reference docs. See 02-manifest.md.
  4. Components shipped as readable source (shadcn pattern), not opaque packages. LLMs read src/components/ui/chat.tsx, propose modifications, write back. See 11-components.md.
  5. locara init --from-prompt "..." uses an LLM to scaffold a starter app from a natural-language description — picks a template, drafts the manifest, writes the initial App.tsx. See 06-cli.md.
  6. Single-purpose primitives, no hidden architecture. No “Chains” or “Agents” framework that obscures behavior. LLMs reason better about explicit code (while loops calling llm.chat) than opaque abstractions. The LangChain over-abstraction failure is the cautionary tale.
  7. Deterministic expansions. When modalities: ["speech-to-text"] expands to capabilities + models, the expansion is shown by locara verify --explain so an LLM can verify its work.
  8. Errors are mechanical, not vibey. Capability mismatches produce specific, actionable error messages (✗ src/lib/transcribe.ts:47 uses fetch() but net=false. Add 'net: { allowed_hosts: [...] }' or remove the call.) so an LLM can self-correct in a tight loop.

This is the supply-side payoff of the framework: a developer + Cursor (or Claude Code, or Codex) can ship a real Locara app in an evening. The framework is designed for that pairing to be the default, not the exception.

Cross-references