# Hanzo Kai — Decision intelligence > Kai is a multimodal decision model that turns heterogeneous evidence into calibrated, typed, mutually consistent decisions, resolved in parallel. Kai is an active research program; the model is in training. Kai # Decision intelligence.Not another language model. Kai is a multimodal decision foundation model. It turns heterogeneous evidence into calibrated, typed, mutually consistent decisions, and resolves them in parallel. [Explore the research](#research)[View benchmarks](#benchmarks) kai · multimodal · typed · calibrated · parallel · self-hostable vehicle.readiness@3example · scripted evidencecamera CAN audio SysML simulation replay Example: a scripted scenario, not model output. Switch a source off and only the decisions that read it run again. Bounded answers ## Language models reason. Kai decides. Generative models are good at open-ended work. Most decisions inside a real system are not open-ended. - Which tool should run? - Which component failed? - Is the evidence sufficient? - How severe is the risk? - Which option satisfies the constraints? - Should execution continue? - Does a human need to approve this? Each has a bounded answer space. Kai is built for them. hanzo decision zenopen-ended reasoning and generationkaibounded judgment and decision stateembedretrievaltsforecastingvisionperceptionaudiospeech and acoustic perceptiongraphstructural evidencesolvermathematical correctnesspolicyauthority hanzo decision composes all of them Evidence ## Everything is evidence. Text. Code. Images. Video. Audio. Sensors. Telemetry. Time series. Graphs. SysML. Simulation. One decision plane over all of it. evidence plane - text - code - image - video - audio - radar - lidar - thermal - sensors - telemetry - time series - graph - sysml - simulation - documents ↓ modality encodersshared evidence↓kai A decision should not care whether its evidence started as prose, a thermal image or a CAN frame. Specialized encoders produce the evidence, and Kai reasons over one shared representation of it. New sensor tomorrow? Add an adapter. The Decision Program does not change. Sensors ## Sensors are first-class. Kai does not treat telemetry as text. A measurement carries its meaning with it. - CAN / J1939 - IMU - accelerometer - gyroscope - temperature - pressure - voltage - current - vibration - GNSS - radar - LiDAR - thermal - RF - acoustics - network telemetry - industrial buses - custom sensors A number without provenance is just a number. Kai keeps the evidence attached. measurementexample value104.2unit°Cchannelcoolant.temperaturesample_rate100 Hztimestamp11:42:13.428uncertainty±0.4 °Ccalibrationvalidsourcevehicle-17provenancesigned stream Change ## Decide on what changed. A sensor stream can hold millions of samples. A decision should not have to reread all of them. Specialized temporal models turn raw streams into evidence. Kai decides what that evidence means for the system. coolant.temperature · summaryexample current104 °Ctrendrisingderivative+1.8 °C/minbaseline+4.2σforecastlimit crossed in 6 minqualityvalid Parallel ## Entire decisions, in parallel. Agent loops serialize control: a question, a model, an answer, and again. Kai is designed around a different primitive. agent loop question → model → answer ↓ question → model → answer ↓ question → model → answer one call per decision, in series decision programexample faultbearing.91 severitycritical.86 readinessno-go.96 actioninspect-bearing.83 next_testspectrum.88 evidence_sufficienttrue.81 human_reviewyes.99 A Decision Program holds many typed variables, and Kai predicts their distributions together. One state. One shared encoding. Many decisions. Refinement ## Resolve certainty first. Kai borrows from masked diffusion without pretending decisions are text tokens. It starts from an incomplete decision state and predicts every unresolved variable in parallel. Confident nodes freeze. Only the uncertain or mutually dependent are refined. Compute follows uncertainty, rather than revisiting everything. refinementexample start [mask] [mask] [mask] … every node 100 decision nodes pass 187 resolved pass 211 resolved constraint pass2 conflicts resolved Dependencies ## Dependencies are explicit. Fully parallel does not mean independently wrong. A Decision Program is a graph. Independent branches resolve together. Dependent branches resolve when the evidence they need is available. The depth of inference follows the dependency graph, not the number of decisions. A ten-thousand-node program does not mean ten thousand serial model calls. program graph fault ─────┬──▶ action └──▶ readiness severity ─────▶ human_review Types ## Decisions are typed. Kai does not write a paragraph and leave software to work out what it meant. choiceexample Which subsystem is responsible? bearing.91gearbox.05unknown.04 scoreexample Operational risk 0.011.022.063.184.515.22 predicateexample Is human approval required? yes.97no.03 deferexample When evidence does not support a safe decision, not deciding is an answer. decision_readyfalsereasoninsufficient evidencerequired_evidencevibration-spectrum Scale ## A million choices should still be a choice. Flat classifiers degrade when every option has to fit inside one prompt. Kai separates discovery from judgment. Candidate representations compile once with a Decision Program and are reused. That makes large tool catalogs, repositories, knowledge graphs and acquisition alternatives tractable, without showing every option to a frontier language model. large choiceexample 1,000,000 candidates ↓ semantic retrieval top 64 ↓ kai reranking top 8 ↓ joint refinement 1 Specialists ## One model should not pretend to be every model. Kai is the decision layer. Specialists remain specialists. A forecasting model forecasts. A vision model perceives. A solver satisfies hard constraints. A policy engine determines what is permitted. Kai decides across their evidence. hanzo decision hanzo decision └─ kai decision state ├─ zen reasoning ├─ ts forecasting ├─ graph structure ├─ vision perception ├─ audio speech · signal └─ solver math policy authority Package ## From perception to a Decision Package. Consider a vehicle under evaluation. vehicle-17 · evaluationexample - camera inspection - thermal video - radar - CAN telemetry - vibration - operator audio - maintenance history - SysML architecture - simulation results - requirements ↓decision program↓kai↓policy + solver↓human approval↓decision package The result is not just an answer. It is a reproducible record of how the answer was reached. Programs ## Decision-as-a-program. A Decision Program makes the structure explicit. A program can combine deterministic calculations, Kai judgments, Zen reasoning, graph queries, simulations, forecasts, formal solvers and human approvals. The model is part of the program. It is not the program. power-system-selection.yamlexample decision: power-system-selection version: 7 objectives: - mission_range - reliability - maintainability options: - architecture_a - architecture_b - architecture_c constraints: max_mass: 480kg delivery: <= 18 months assumptions: supplier_lead_time: 22 weeks risks: - battery_availability - thermal_margin approvals: - engineering - acquisition Sensitivity ## Ask what flips the decision. A useful decision system tells you more than what it prefers. It tells you where that preference stops being true. Kai and Hanzo Decision run sensitivity and counterfactual evaluation against the same versioned program. No new prompt. No hand-rewritten trade study. power-system-selection · sensitivityexample baselineArchitecture Abattery cost +11%A remains preferredbattery cost +17%A → Bmass limit −4%A remains preferredmass limit −8%A → C Versions ## Decisions that live longer than a meeting. Evidence changes. Requirements change. Suppliers change. Models change. The Decision Program remains. Hanzo records what evidence changed, which assumptions changed, which nodes recomputed, which boundary was crossed, why the result changed and who approved the new one. A trade study becomes a decision system you can refresh. power-system-selection · historyexample version 14 Architecture A ↓ new reliability evidence version 15 Architecture A ↓ mass requirement changed version 16 Architecture B Replay ## Replay it. Every Decision Package can preserve: - program version - input snapshots - evidence hashes - provenance - model revisions - Kai checkpoint - calibration revision - solver state - policy result - probability distributions - human overrides - approval state - execution trace The question is not “What did the AI say?” It is “Can we reproduce the decision?” Business ## Autopilot for business. Most of a business’s work is bounded decisions, followed by generation and execution. Kai decides who, what, when and through which channel: enrichment, lead fit and intent, next action, offer, cadence, human handoff, and when to stop. It personalizes recommendations over the product graph. Zen writes the message. Enso runs the workflow and routes each step to Kai, or to Zen when generation is the work or Kai defers. Policy decides whether contact is permitted: consent, opt-outs, caps, quiet hours and jurisdiction. Configured natively in Hanzo Cloud, with signals from Hanzo Analytics, Insights and Commerce. Each program (marketing.*, sales.*, commerce.*) is measured by its own outcomes and tested in shadow before it acts. [Analytics](https://hanzo.ai/analytics)[Insights](https://hanzo.ai/insights)[Commerce](https://hanzo.ai/commerce) sales.lead@4example sales.lead@4 → intent4fit5timingnownext_actiondemo Agents ## Built for agents. The same primitive controls Hanzo’s own agent runtime. Generative reasoning is reserved for the work that actually requires generation. Control becomes a typed system. agent runtime · kai decides which model? which tool? which file? which skill? how much context? does this touch secrets? should execution continue? did the agent make progress? does a human need to approve? Physical systems ## Built for physical systems. ### Vehicles Readiness, diagnostics, trade studies and maintenance. ### Robotics Perception-conditioned actions and safety escalation. ### Manufacturing Process state, anomalies, inspection and intervention. ### Aerospace Telemetry, digital engineering and configuration decisions. ### Energy Forecasting, equipment state and operational decisions. ### Infrastructure Sensors, simulations, risk and long-horizon planning. One decision abstraction. Different evidence. Deployment ## Built to run where the evidence lives. Decision evidence does not need to leave the infrastructure that owns it. Kai extends Hanzo’s operating plane with decision intelligence. - Hanzo Cloud - Your cloud - Your Kubernetes - Your GPU - On-prem - Disconnected environments Research ## Research, not magic. Kai is an active research program. We benchmark it against the systems it descends from and the ones it competes with, and we publish the losses. benchmarks · how results are reported reported separately: training-set performance held-out generalization multilingual generalization choice cardinality calibration runtime performance deployment properties no results are published yet. they publish as they clear reproducible release gates, with the harness that produced them. research tracks - 01Extreme-cardinality decisionsFrom tens of candidates to hundreds of thousands. - 02Multilingual decision intelligenceConsistent decisions across languages, rather than translation-first inference. - 03Shared-state decodingEncode the evidence once and resolve many questions against it. - 04Decision diffusionParallel structured inference with selective refinement. - 05Multimodal evidenceSensors, video, audio, time series, graphs and engineering models. - 06Calibration and abstentionKnowing when the evidence is insufficient. - 07Decision graph consistencyMaking many locally plausible decisions globally coherent. [Read the specification, HIP-1332](https://github.com/hanzoai/hips/blob/main/HIPs/hip-1332-kai-the-decision-model.md) Kai + Zen ## They solve different problems. generation · decision zenkaiWhat should the implementation look like?Which implementation satisfies these constraints? Explain the evidence.Is the evidence sufficient? Generate a test plan.Which test should execute next? Reason about the alternatives.Which decision state follows? Generation and decision are complementary computational primitives. They should not be forced into the same model call. Three families ## Zen generates. Enso orchestrates. Kai decides. Three model families, one stack, and policy over all three. - generatesZenOpen weights · run anywhereOpen-weight generative models for reasoning, code and generation. Free to self-host, or managed on Hanzo Cloud.next · zen7, upcomingExplore Zen → - orchestratesEnsoProprietary · Hanzo CloudHanzo’s router and adaptive family, in Flash, Pro and Ultra. It reads each request and puts the right models on it; Ultra probes one arm and escalates only when unsure.also · enso diffusion (research) · enso browserExplore Enso → - decidesKaiResearch · in trainingDecision intelligence: the typed decision layer. Inside Enso it is the controller, deciding the model, the context, the tools, the reasoning budget and when to stop.api · POST /v1/decisions · previewThis page Policy governs. Deterministic authority over every call: a model’s verdict can tighten it and never loosen it. Kai doesn’t make Zen generate faster. It makes Zen generate less. Design intent, not a measured result. API ## Kai is exposed through Hanzo Decision. One endpoint, POST /v1/decisions: a program, the evidence it reads, and typed answers back. kai is a preview. The model is in training, and the response shown is an example. POST /v1/decisionsexample POST /v1/decisions { "model": "kai", "program": "vehicle.readiness@3", "evidence": [ "sensor://vehicle-17/can", "video://inspection-382", "sysml://vehicle-17", "graph://maintenance-kg" ] } → { "decision": "dec_01…", "answers": { "readiness": { "value": "no-go", "probability": 0.96 }, "human_review": { "value": true, "probability": 0.99 } } } Open ## Open research. Open runtime. Kai builds on open research in typed decision models and evolves it into Hanzo’s native multimodal Decision runtime. Weights, benchmarks and runtime components are published as they reach reproducible release gates. Run Kai through Hanzo Cloud. Run it on your own infrastructure. Study the benchmark. Fork the runtime. ## Stop asking one model to do everything. Reason with Zen. Perceive with specialist models. Forecast with temporal models. Verify with solvers. Govern with policy. Decide with Kai. One decision plane over every kind of evidence. [Start building](https://platform.hanzo.ai)[Explore Hanzo Decision](#api)