OpenJevSwift
Open source by Algorythm · Apache-2.0An open-source Swift implementation of OpenJev. It brings probability-based yes/no, choice, and score answers into iPhone and Mac applications, with a compatible HTTP server for existing integrations.Typed decisions and native inference demonstrate our AI software engineering for local applications.
Many application decisions need a bounded answer: whether a message needs attention, which team should receive it, or where it falls on a scale. Bringing that behavior onto Apple devices requires more than translating an HTTP endpoint. The implementation must preserve the request contract, reproduce model readout behavior, manage local model files, and make numerical differences visible across runtimes.
We separated a Foundation-only decision core from the model backends, server, and command-line interface. Core ML serves the encoder models; MLX supports the larger Apple silicon backends. Golden fixtures, checkpoint comparisons, and device tests check compatibility at the appropriate level. A native triage demo puts the public library API into a real iPhone interaction.
How the experience connects to the application, data, and processing behind it.
The first boundary is between a decision contract and the inference implementation. OpenJevCore contains the request and answer types, schema validation, prompt and template construction, probability processing, and engine policies. It depends on Foundation and builds on macOS, iOS, and Linux. Applications can link the core and a backend without pulling the HTTP server into an iPhone build.
The model adapters serve different readout strategies. Verdict and Laya run through Core ML. DiffusionGemma and JevK5 use MLX on Apple silicon. Protocols isolate those model-specific paths from the public contract. Swift 6 strict concurrency and actor-isolated engines make ownership and concurrent work explicit, while server admission and runtime limits bound the work a deployment accepts.
Compatibility is tested in layers. Upstream Python produces golden fixtures for wire responses, validation errors, prompts, tokenization, seeded canvases, and decision policies. Model-free tests can check those contracts without downloading weights. Live checkpoint tests then compare inference behavior, using exact equality only where the reference conditions support it and measured bounds for native kernels.
The application experience is part of the engineering. TriageDemo uses the public library API, debounces input, cancels outdated reads, and presents each option’s probability. Its model store verifies downloads before keeping them. Tests cover request bytes, answers against a Mac reference, and accessible labels in the interface. Package documentation, dependency pins, and recorded compatibility decisions make those boundaries available to other developers.
From the implemented demo to ways a team can apply the same library boundary.
The implemented demo asks whether a message needs a reply within an hour, which team should handle it, and how upset the customer sounds. The person sees distributions over the permitted answers as they type. The demo is a concrete example of native interaction design around local inference.
A Mac can run openjev serve behind the Jev-compatible API, or answer a single request through openjev decide. This provides an integration path for tools that already speak the wire contract, while keeping inference in the local process and its configured model runtime.
The same embedding pattern can support a fixed routing decision or an ordered assessment in another product. Define the permitted answers, evaluate domain examples, and decide when a person should review a close or uncertain result before allowing it to affect the business process.
This request uses the public systemone contract. The caller defines the choice options; the backend returns a choice and its probability distribution. Applications can make the same request through the Swift library instead of HTTP.
JSON request · POST /v1/systemone
{
"model": "jev-latest",
"state": "I was charged twice this month.",
"questions": {
"team": {
"type": "choice",
"instructions": "Which team should handle it?",
"criteria": {
"outage": "service down",
"billing": "charges, refunds",
"feature": "requests, how-to"
}
}
}
}The application and the HTTP server are separate entry points to the same decision contracts. The diagram follows the inference path; model preparation, package downloads, and operations sit around it.
A native Swift caller or Jev-compatible request supplies state and typed questions.
Validation, question schemas, decision policies, and answer assembly.
The chosen backend performs its model-specific probability readout locally.
The caller receives defined answers, distributions, and usage information.
The core’s Foundation-only boundary keeps inference and transport dependencies separate. The server and CLI translate deployment settings into typed configuration; an embedding application owns its own setup and product behavior.
The iPhone demo asks about urgency, routing, and tone. It uses a local Verdict model after the initial verified download, with a cancellation-aware interface around the read.
A short pause after typing schedules a read; further input cancels pending work.
The view model supplies a yes/no, a team choice, and an ordered tone question.
The actor-based encoder engine runs the model and assembles the permitted answers.
The interface presents option bars, confidence, model identity, and model time.
A cancellation check prevents an obsolete read from publishing its result. If a question type is refused, the demo tests questions individually, retains supported questions, and explains the omitted ones.
Each connected system has a specific role. These boundaries explain where information moves and which part of the application owns the next step.
Link OpenJevCore and the required backend module through Swift Package Manager.
The app owns the interaction, permission model, business rules, and the meaning of a decision in its workflow.
The Hummingbird server and openjev CLI expose local decisions to existing clients.
Request shapes, headers, model listing, and error behavior are part of the compatibility work. An API-compatible response does not imply that every backend has the same task accuracy.
The encoder store obtains model packages, tokenizers, and calibrators, checking size and SHA-256 against its embedded manifest.
The initial setup needs network access. Checked local files support later offline use; model weights and their licenses remain separate from the Swift source license.
Reference fixtures, checkpoint comparisons, and benchmark harnesses provide evidence at different layers.
Wire compatibility, numerical parity, model accuracy, latency, and calibration are measured separately so one result is not used to stand in for another.
The typed decision API limits the answer to the supplied yes/no, choice, or score contract. This avoids making a prose response responsible for its own output schema.
Structural validity does not establish substantive correctness. Thresholds, ambiguity handling, and the consequences of an answer still need evaluation on the application’s workload.
Pure Swift contracts are checked against upstream fixtures. Model reads have their own exact-reference conditions and native-runtime comparisons, with the differences recorded publicly.
Floating-point precision, quantization, and kernels can change probabilities and close decisions. A useful port needs explicit bounds and difficult examples instead of a blanket equivalence claim.
The package keeps the core independent of the server and verifies model artifacts before retaining them. The iPhone demo uses the same public interfaces an embedding app would use.
First-run download, compilation, memory, model support, and device capability become part of the application’s setup experience. The four backends have different operating requirements.
The outcomes below describe the product capabilities established by this case study. The measured results retain their reference comparisons and test conditions.
Swift applications can embed typed decisions, while a Mac process exposes compatible HTTP endpoints and command-line operation. Transport, shared contracts, and model execution have separate responsibilities.
TriageDemo classifies customer messages with visible probabilities, input cancellation, and progress/error handling for model setup. Its documentation records later offline use on a physical iPhone.
The public repository includes conformance fixtures, model comparison results, benchmark methods, architecture decisions, DocC documentation, and tests. Contributors can inspect both the implementation and the limits of its reported results.
The repository reports these results under defined conditions. The desktop measurements use an Apple M3 Max with 128 GB on macOS 27.0.1. The quality comparison was run on October 1, 2026; the read benchmark on October 1; and the device comparison on October 6. Each result answers a different engineering question.
Verdict and Laya across 231 JevBench items and 102 TypeSafe evaluation rows per model. This is agreement between the Swift and upstream servers, with the Core ML and reference configurations described in the report; it is not a 100% accuracy result.
Read the method and resultsDiffusionGemma 26B-A4B, 4-bit, in-process on the M3 Max. Fifty timed reads followed five untimed requests, with a new input state for each request and one caller at a time. The 95th percentile was 327.7 ms.
Read the method and resultsThe iPhone 13 Pro Max on iOS 27.0 was compared with Mac answers for the demo’s three sample messages. All demo test groups passed. This absolute probability difference describes those samples and that comparison.
Read the method and resultsThe principal technologies in the reviewed source, grouped by their role in the product.
The demo asks about urgency, the responsible team, and tone. Each answer exposes the options and their probabilities; the full interface also presents the score and confidence. The recording shows the billing example being entered through the keyboard.
A 250 ms pause after typing schedules a read. A new keystroke cancels pending work, and the view model checks cancellation before publishing an answer. The model runs through the library’s actor-based engine, keeping the interface responsive.
Model setup shows download progress, verifies file sizes and SHA-256 digests, and retains checked files for later launches. The demo documentation records a physical iPhone run in Airplane Mode after the initial download.
Follow the design, implementation, and verification in the public repository. These references point to the reviewed source revision.
Bring us your challenge.