The Ilura Engine

One engine. Every app.
Nothing leaves the phone.

Every Ilura app is a thin, focused surface over a single core: an append-only, cryptographically hash-chained event ledger with rebuildable projections and integer-only money, driven by Apple's on-device Foundation Models — in-process, no network. Build an app in weeks. Make it impossible to copy privately.

0servers · zero network calls
In processFoundation Models, on device
Deterministicreplay from event zero

The core, four decisions deep

core/keel-core → UniFFI → SwiftUI

The engine is not a framework of conveniences. It is four load-bearing decisions that every app inherits for free — and that no competitor can reproduce without your device.

01
Foundation Models, in-process Apple's ~3B on-device model does the reading, classifying and drafting. Guided generation is grounded in the user's own data — their vendors, their chart of accounts — so the model fills fields it can see, never invents them. No prompt ever leaves the silicon.
02
Append-only, hash-chained ledger Every fact is an immutable event in a per-device BLAKE3 hash chain over canonical JSON (JCS / RFC 8785). Tamper with one event and every downstream hash breaks. History is auditable, ordered and provably intact — the same guarantee a bank ledger gives, on a phone.
03
Rebuildable projections The ledger is the truth; every view — balances, subtotals, a Schedule C, a report — is a projection folded from events and thrown away at will. Integer-only money means totals reconcile to the cent. Change the shape of a report; replay; it is simply correct.
04
Data-Not-Collected, by construction There is no server to leak because there is no server. Privacy isn't a policy we promise — it's an architecture that makes collection impossible. The App Store nutrition label reads "Data Not Collected" because the data has nowhere to go.

Events in. Truth out.

the agent/ledger loop

The agent proposes; the ledger records; the projection reports. One shape, reused by every app on the engine.

engine/core.swift
// 1. On-device model reads a receipt, grounded in the user's own data.
let draft = try await model.extract(image, grounding: userLedger)
// draft.vendor .amount .category  — fields the model could SEE, not invent

// 2. The fact becomes an immutable, hash-chained event. Nothing else can.
let event = Event(kind: .expenseRecorded, payload: draft, amountMinor: 4200)
ledger.append(event)      // prev_hash → blake3(JCS(event)) → next

// 3. Every view is a projection folded from events — rebuildable, exact.
let scheduleC = ledger.project(.taxReport(year: 2026))
assert(scheduleC.totalMinor == ledger.sum(where: .deductible))

// 0 network calls · 0 servers · replayable from event zero

Ship many. Keep the survivors.

go-to-market

The engine is the bet; each app is an experiment. Because the hard 90% — ledger, crypto, on-device model, replay, privacy posture — is already built and shared, a new task-app is a thin TaskSpec over the same core. That changes the economics of trying.

Cheap to build
~1 corereused across every app — Rust ledger, UniFFI bindings, Foundation Models loop, projection engine. A new app writes its screens and its TaskSpec, not its foundations.
TaskSpecshared coreweeks, not quarters
Impossible to copy
0 exportThe moat isn't the code — it's the private, accumulating on-device memory each user builds. It never leaves the device, so no competitor and no cloud can ever hold it. The survivor keeps compounding.
on-device memorynon-copyablecompounding

Not every task earns an app

the 3-gate filter

Before a task becomes a TaskSpec, it passes three gates. The filter is deliberately harsh — it exists to say no, so the engine only carries tasks it can win.

1
Feasibility Can the ~3B on-device model actually do the hard step, grounded in the user's data? Memory teaches preference and context — not capability. If the task needs frontier reasoning the phone can't ground, it fails here.
2
Edge Is there a durable advantage in doing this on-device — private, accumulating, autonomous admin Apple surfaces but won't complete-and-file for you? Offline and zero-cost are preconditions, not the edge itself.
3
Durability Does the moat deepen with use? The best tasks accumulate user-specific rules — vendors, projects, filing taxonomy — that make month twelve better than month one and impossible to replicate elsewhere.

The engine, running today

apps on the core

Keel is the first surface on the engine: an on-device financial brain for a company of one — invoices, expenses and mileage on a hash-chained ledger, one-tap tax report, nothing sent anywhere.

Keel Live
Company of oneReceipts and invoices in, a Schedule C / T2125-style report out — reconciled to the cent, on device, offline. The wedge app that proved the core on real Apple Intelligence silicon.
Explore Keel →
ILURA Live
Your wordsPrivate personal agents for the messages you write every day — your tone, your rules, invoked by name, on the same on-device engine. Never leaves the phone.
Explore ILURA →

The engine, in plain terms

questions, answered

What is the Ilura Engine?

The Ilura Engine is a single reusable core that every Ilura app is built on: an append-only, cryptographically hash-chained event ledger with rebuildable projections and integer-only money, driven by Apple’s on-device Foundation Models in-process. Each app is a thin, focused surface over that same core.

Does the engine send data to a server?

No. There is no server and no network round-trip. Apple’s on-device Foundation Models run in-process, and every fact is stored locally in a per-device hash-chained ledger. Because the data has nowhere to go, every app on the engine carries the App Store label Data Not Collected.

Why build many apps on one engine?

Because the hard 90% — the ledger, the cryptography, the on-device model loop, replay and the privacy posture — is built once and shared. A new app is a thin TaskSpec over the same core, so it ships in weeks. Ilura ships many focused apps, puts them in front of real work, and keeps the survivors.