Occipital

Occipital is how data reaches and renders in the CortexKit phone and desktop apps. It turns what agents and tools produce into what the apps show: a chart or a callout in a reply, a tool's own view of a command it ran.

It holds:

• The language library (crates/occipital-lang). One Rust library parses, checks and evaluates the closed, declarative interface language, so an interface is checked and drawn the same way in every app and in this module. It has no panic paths, because apps embed it. Parsing builds on cortexkit-rich-ui-syntax.
• The app binding (crates/occipital-ffi). A C interface to the library that turns any panic into an error code, packaged as a static xcframework for iOS. The Swift package in Package.swift wraps it as OccipitalKit.
• The tool template contract (crates/occipital-registry, published as cortexkit-occipital-registry). The occipital.template/1 document with its canonical JSON and digest, the checks a tool provider's view must pass, and the occipital-check command providers run in CI. The template guide explains how to write one.
• The ck-occipital binary (crates/occipital-module). It runs on the person's computer as the reserved occipital module under the CortexKit daemon. It serves the apps' chat operations (transcript pages, live text, sends, Stop and uploads) and the reply teaching, the part of a head's system prompt that teaches the interface tags, which Core adds for runners that stamp replies. See the module guide.
• The transcript engine (crates/occipital-app-reader). The pages, claims, live-text ring and watches behind the apps' chat reads, independent of the daemon.
• File placement helpers (crates/occipital-files). A no-replace move, a file's identity and free space, on Windows, Linux and macOS, for placing uploads.
• Templates (templates/). Example row and page templates for a tool provider's views.

Where it's going

Occipital is becoming the one module the apps use for a chat:

• Reading: it reads every llm-runner through the shared runner contract and composes the pages and live text the apps show.
• Writing: it forwards sends, uploads and stop to the runner hosting the session.
• Tool views: it keeps the display data tool providers write for each call, such as a command's exit code or an edit's diff. Runners keep only what the model reads and writes.

Reading and writing are served for Broca sessions and Thalamus's OpenCode sessions. Until the apps switch to Occipital, they read chats through Thalamus. Tool views are not built yet.

Build

Rust runs on the Linux build server, never with cargo on the Mac that builds the apps.

cargo build --release -p occipital-module --bin ck-occipital
cargo test --workspace
cargo test -p occipital-module --features show-ui