The system that exists today can be built and run on Apple Silicon from the repository. The path is the source path: checkout, build, run, call.

# 1. Clone the repository
git clone https://github.com/Tribunus-dev/prism-engine.git
cd prism-engine

# 2. Install the pinned toolchain (rust-toolchain.toml)
rustup show

# 3. Build the engine
cargo build --release

# 4. Pull a model identity and compile to a ComputeImage
cargo run --release -p prism --features full-apple -- pull --model <id>

# 5. Run the OpenAI-compatible local server
cargo run --release -p prism --features full-apple -- run

# 6. Call the server
curl localhost:8080/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"<id>","messages":[{"role":"user","content":"hello"}]}'

The commands above are the canonical developer path. The build features, target triple, and runtime flags are named in the engine's own manifests; the Run page does not duplicate them. The Run page names what to type, and where to read the details.

The v1 corpus has no recorded terminal session for this path. A recorded session is bound to a specific commit, a specific machine, a specific model identity, and a specific feature set. The follow-on ADR (closing ADR-034) will emit one. Until then, the Run page renders the commands without fabricated output.

A packaged release is a versioned, signed, distributable artifact with a declared support boundary. Prism does not currently publish a packaged release. The Run page names its absence rather than showing screenshots of a product that does not exist.

When a release record exists in releases.json, the Packaged Path section appears with: the version, the signature verification path, the support boundary, the qualified targets, and the installation instructions.

Known failure modes are named in the engine's documentation. The Receipt component of the evidence page names the failure classes. The Run page links to both. The visitor who hits a failure finds the class in the receipt, the cause in the engine's documentation, and the recovery path in the architecture.

A reviewer who hits a failure that is not named: file a report. The Diagnostics component captures the route, the selection, the build identity, and the failure. The report is not a bug tracker entry; it is a piece of evidence for the next freeze.