mirror of
https://github.com/hanzoai/papers.git
synced 2026-10-22 17:20:17 +00:00
zeekayandHanzo Dev
e57d01a884
Every measured constant in hanzo-dormant-agents came from bench lanes that have since been re-run, and two of them from a lane that was deleted. The paper is the last consumer to be corrected and the one where it matters most. The pooled row was the problem. Section 6 reported 37.54 ms for "a command dispatched into a container that is already up" and built a paragraph on it — "pooling collapses most of the gap, and is the only tier that matters at fleet scale" — which the conclusion then turned into policy: pool the expensive boundary so a fleet pays the pooled number in steady state. That row was docker exec, on a runtime this system does not use. The runtime it does use has no exec, no attach and no pool. Every call boots. So the table is hanzo-vm now: 309 ms cold, 335 p95, and 311 ms from a checkpoint — which is the same number, because a checkpoint carries the filesystem an earlier run left and the kernel boots either way. The pooling paragraph is replaced by what is true: there is no warm tier, the published resume figures elsewhere are memory snapshots and ours is not, and setting the two side by side would claim a mechanism by borrowing its name. The cost of not having it is stated instead — about 3x on a whole agent call. Section 6 also said our figure "compares favourably to the published cold-start figures". At 309 ms it does not: it is slower than the under-200 ms published for Firecracker sandboxes, faster than the container platforms, and all of those were taken by their authors on their own hardware. The paper says that now, including that quoting their hardware back at them is not a defence. The rest are re-measurements: a goroutine spawns in 125 ns (the 187 was a fresh binary's first run, which is 1.65x its own steady state), a million wake in 107 ms, a V8 context is 0.13 ms, an isolate 0.35 ms, wazero 7.8 us, goja 2.4 us, gpython 25.0 us. The isolation ratio is 2377x, not 1016x. Rebuilt: 12 pages, no stale figure survives in the PDF. Co-authored-by: Hanzo Dev <[email protected]>
Hanzo AI Research Papers
Technical papers covering Hanzo AI compute infrastructure, agent frameworks, ML inference, platform services, and defense applications. Includes the Zen model family co-developed with Zoo Labs Foundation.
About
Hanzo AI is an American-owned, Techstars-backed ('17) applied AI lab, founded 2014, building the Zen frontier model family alongside a vertically integrated, post-quantum AI and cryptography stack. The work spans frontier models, an agentic runtime, edge inference, and production post-quantum cryptography — engineered to run sovereign and disconnected in defense, regulated, and air-gapped environments rather than on centralized cloud. The platform these papers document is generally available at hanzo.ai.
2026 Highlights
Each claim below is developed in the catalogued papers (INDEX.md):
- Defense & Reindustrialization suite (16 papers + one-pager). Positioned for the
American industrial base — sovereign AI, robotics, post-quantum, and low-latency
on-chain coordination for factories, vehicles, drones, ships, and contested-edge
systems. Strategy & case studies: sovereign-vs-closed AI (
hanzo-vs-claude), the ~90% cloud-cost migration on real numbers (hanzo-cloud-economics), agentic engineering at regulated scale (hanzo-agentic-prowess), FHE-native confidential computing (hanzo-fhe-native), automated security auditing (hanzo-security), and audit-ready compliance (hanzo-compliance). Capability depth: autonomous agentic AI (hanzo-agentic-ai), DDIL/tactical assured networking (hanzo-assured-networking), FHE-mediated cross-domain MLS (hanzo-cross-domain), edge AI/ML (hanzo-edge-ai-ml), counter-exploitation (hanzo-countermeasures), full-spectrum cyber (hanzo-full-spectrum-cyber), quantum sensing/QKD (hanzo-quantum-sensing-qkd), verification & validation (hanzo-test-evaluation), and the ZAP protocol (hanzo-zap-protocol). Start with the one-pager (defense/hanzo-overview.pdf); the full suite is published at papers.hanzo.ai. - Engine / AI infrastructure (6 papers, measured on-device). A native Rust
train-and-serve engine benchmarked on real silicon: ROCm decode parity with llama.cpp
at 97% of the memory-bandwidth wall (
hanzo-rocm-inference), measured AMD/NVIDIA/Apple edge inference (hanzo-cross-backend-inference), native training inside the inference stack (hanzo-native-training), continuously-learning private AI (hanzo-continuous-learning-privacy), serving economics (hanzo-platform-infra-desktop), and the unifying thesis (hanzo-native-stack-thesis). Unusually honest — they name their own stubs and reverted kernels and claim no win over NVIDIA. - Unified sovereign-tenant cloud (measured). The whole multi-tenant cloud as one Go
binary — 56 in-process subsystems over shared-nothing storage, each tenant its own
post-quantum-encrypted SQLite file. Measured on the production open path: ≈0.25 MB RAM
per actively-served tenant, near-zero idle — memory scales with concurrency, not
registrations, so one billion registered tenants at 1% peak concurrency fits ≈20
commodity 128 GB nodes (
hanzo-unified-tenant-cloud; architecture companioncloud-unified-binary). - Production post-quantum cryptography. All three NIST PQC standards — FIPS 203
(ML-KEM), 204 (ML-DSA), 205 (SLH-DSA) — integrated into a live consensus system with
hybrid classical/post-quantum security (
hanzo-full-spectrum-cyber). - Formal verification. 50 machine-checked Lean 4 proofs, 18 cryptographic security
reductions (incl. ML-DSA EU-CMA, ML-KEM IND-CCA2), and NIST Known-Answer-Test
validation across FIPS 203/204/205 (
hanzo-formal-verification). - ZAP (Zero-copy Application Protocol). 2.2 ns parse latency, 11.5M transactions/s,
91% memory and 96% energy reduction vs JSON-RPC; native post-quantum transport
(ML-KEM-768 + ML-DSA-65) and W3C DID identity (
hanzo-zap-protocol). - Agentic runtime. 83 specialized agents and 15 orchestrators executing 200–300
sequential tool calls, fully offline on embedded ARM with quantized Zen models
(
hanzo-agentic-ai,hanzo-edge-ai-ml). - Zen frontier models. An 18-model family (0.8B–1T+ parameters), co-developed with Zoo Labs Foundation, with owned weights and full provenance.
Structure
Each paper lives in its own subdirectory:
papers/
├── shared/ # cover styles, lstlang.tex, paperkit
│ ├── hanzocover.sty
│ └── lstlang.tex
├── <paper-slug>/
│ ├── <paper-slug>.tex # main file (\input's sections)
│ ├── <paper-slug>.pdf # compiled output
│ └── sections/ # modular sections
│ ├── 01-intro.tex
│ ├── 02-architecture.tex
│ ├── 03-protocol.tex
│ ├── ...
│ └── 99-bibliography.tex
└── INDEX.md # auto-generated catalogue
Building
cd <paper-slug>
TEXINPUTS=".:..:" latexmk -pdf <paper-slug>.tex
Or build all — every paper, and a nonzero status naming any that did not compile:
make -k all
Index
See INDEX.md for full catalogue of papers.
Conventions
- One paper, one directory. No top-level .tex files.
- Modular sections. Main .tex \input's
sections/NN-name.texfiles for easy editing. - Shared cover. All papers use
\usepackage{shared/hanzocover}and\hanzocoverpage. - Shared lstlang. All papers use
\input{shared/lstlang}after\usepackage{listings}. - No AI slop. Technical, dense, citation-supported.
- One paper per concept. Updates over time via versioning, not duplication.