enso/ now lives in hanzo-inc/enso under papers/enso/, and kai/ in
hanzo-inc/kai under papers/kai/, each with its history. The index,
the site's paper list and its built kai.pdf drop them.
The parity report lists its checkpoints as objects now, so the generator counts
them instead of printing the list.
Co-authored-by: Hanzo Dev <[email protected]>
results-data.tex regenerated from hanzoai/benchmarks de99c3e: cardinality,
invariance, joint programs, sensors and the original rows for Laya and Jev
(729 keys). The training guard reads the current manifest: 2,383,278 training
rows, 4,099 excluded. runs.json now names $BENCH/enso/results, where the Enso
harness writes. 494 cells still print XXX: Kai's trained checkpoint, speed at
1 to 1,000 questions, and the Enso studies.
Co-authored-by: Hanzo Dev <[email protected]>
The Laya-identical checkpoints are the Laya baseline, run in its Python
reference and natively in Rust; Kai is a multilingual encoder, evidence
adapters and a typed-variable decoder on one checkpoint line, initialized from
Laya. A new section tests the claim that Kai makes Zen generate less: Enso
conditions B0 to K5, routing regret, context, skills, early stop, reasoning
budget, KV retention and concurrency, keyed enso/<study>/<condition>/<metric>
and printing XXX until runs land. Capability tables use the keys
decision/capability writes.
Co-authored-by: Hanzo Dev <[email protected]>
Evidence records, factorized choice and typed-variable diffusion; programs,
packages and policy as they land in hanzoai/decision. Capability, speed and
accuracy tables read results-data.tex, which scripts/results.py writes from
data/runs.json; a cell no kept run has filled prints XXX.
Co-authored-by: Hanzo Dev <[email protected]>
Every author block and the authorship standard said Los Angeles; Hanzo has
been in San Francisco since at least 2016. The five catalogue PDFs whose
sources changed are rebuilt so papers.hanzo.ai says so too.
Co-authored-by: Hanzo Dev <[email protected]>
A paper on Hanzo Decision and the Kai checkpoints (hanzoai/kai-1 b50502c2,
kai-1-multilingual, kai-1-agent). Typed questions and the three things called
confidence; the Kai architecture as the Rust port implements it; policy as a
join on allow < ask < deny, with the proof that enforcing a model only adds
friction, which shadow records count exactly; Decision Programs, their tests,
and the OpenRouter-compatible /v1/decisions; decision-as-a-program for
studies: packages, the smallest weight, answer and assumption change that flips
a recommendation, and refresh by content-addressed cells.
Measured: the three bootstrap checkpoints on the nine recorded parity states
(Laya 0.3.20, torch f32 CPU). Two of three rank allow first for a command that
pipes ~/.ssh/id_ed25519 to curl; none puts more than 0.25 on deny; the act head
is 1.0 on all 36 answers. Upstream latency and accuracy are quoted and marked
[reported]; the Rust runtime and everything past it are marked [proposed].
The study illustration is constructed and says so.
Listed on papers.hanzo.ai with its PDF.
Co-authored-by: Hanzo Dev <[email protected]>
Regenerated with scripts/gen-index.sh: adds the two new papers and
locomo-subject-scope, which the last regeneration missed.
Co-authored-by: Hanzo Dev <[email protected]>
Design, prior art and a measurement protocol for a weighted inverted index
over a mixed sparse basis and part-level routing before per-part HNSW in a
ClickHouse-derived store. Each component is marked prior art or proposed.
The protocol fits C(N) = aN^alpha to parts, granules and bytes touched per
correct answer at a held recall. No numbers: every results cell is a
placeholder read from results-data.tex until the baseline lane writes it.
Co-authored-by: Hanzo Dev <[email protected]>
Describes /v1/graph at hanzo-inc/cloud 1fffdf408: one append-only table of
assertions, a server-derived knowable instant, reads at a valid and a
transaction instant, versions that correct each other only when learned
later, declared cardinality and schema as assertions, diff, path, erasure
with a receipt, Louvain communities and a citation-checked answer.
CronQuestions from hanzoai/benchmarks: 99.88% Hits@1 for the control,
semantica 0.7.0 and the store, question for question; 0.063 ms against
5,357 ms per call. The first run's 70.03% is reported with its two causes
and the two defects the harness found in the fix. LongMemEval-S is
included as a measurement of the retrieval engine, not of the store.
Co-authored-by: Hanzo Dev <[email protected]>
hanzo-dormant-agents was corrected in the .tex and its PDF rebuilt; the site's
own copy of the abstract was not, so papers.hanzo.ai advertised 187 ns to start
a goroutine, a 0.15 ms V8 context, a 150.80 ms OCI container and a 1016x
isolation ratio — every one of them a figure the paper itself had dropped.
It now reads 125 ns, 0.13 ms, a 309 ms microVM and 2377x, matching the document
it summarises. An abstract that disagrees with its own paper is worse than no
abstract: it is the part most people read.
Also ignoring site/tsconfig.tsbuildinfo — tsc incremental state, not source.
Co-authored-by: Hanzo Dev <[email protected]>
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]>
This repo had two workflows building one image. deploy-site.yml drove
docker/setup-buildx-action, docker/login-action and docker/build-push-action on
a runner, and that is not a road this fleet has: the ephemeral pool carries no
daemon and the job died on /var/run/docker.sock: no such file or directory. It
is deleted rather than pinned to the one host that still has docker, because the
answer to "no daemon here" is not "find the machine with a daemon".
cicd.yml drops `mode: buildx` and takes the door's default. The door builds one
BuildKit Job per architecture, each on a node of that architecture — in-cluster,
no docker anywhere, nothing emulated.
buildx was pinned because the door refuses a context below the repository root
and this image's was `site`. So the context is the root now, and .dockerignore
does the work the narrow context was doing: 827M of repository, and what reaches
the image is the site's own tree. site/node_modules alone is 414M of what it
drops. The Dockerfile's paths move with it.
platforms goes back to both. The declaration and the mode finally agree — two
platforms and a builder that can produce two, where before the tree asked for
two from a builder that could only ever make one and was refused for it, which
is the state the build sat in from 2026-09-03.
Co-authored-by: Hanzo Dev <[email protected]>
Dropping the hanzo-build- prefix widened this job's pool, and the pool it widened
into cannot do the job: the ephemeral runner-github-papers-* runners advertise a
bare linux-amd64 and carry no docker daemon, so the build died on
/var/run/docker.sock: no such file or directory. The run before it, on
evo-amd64, was green. Same workflow, same commit range, different machine.
The old label was not better — it was answered by evo alone, so when evo was off
the network the job queued forever with nothing to read. Both failures are the
same defect wearing different clothes: a label that does not mean what the job
needs.
self-hosted is what separates them, and it is already a documented capability
token rather than a machine's name, so the four names stand. An image build says
it needs a persistent runner; the ephemeral pool keeps the jobs that only need a
checkout and a node.
The real fix is upstream of this file: a runner that cannot build an image should
not advertise the label image builds ask for. Until the ephemeral pool either
gains a daemon or drops the label, this is the line that keeps the build on a
machine that can run it.
Co-authored-by: Hanzo Dev <[email protected]>
mab-fc.tex carries a row — typed search with one repair call — whose test cells
are ellipses and which the paper never mentioned. A reader meets an unexplained,
mostly empty row and has no way to tell a missing run from a rejected one.
It is a rejected one, and the traces say so precisely: across 196 dev questions
the repair fired ONCE, that single plan was chosen, and it is the entire
difference between 88 and 89 multi-hop. One question, for a 27B model held
resident beside the search. The row beneath it — exhaustive enumeration with a
lexical tie-break — buys five points with no model in the loop at all.
So it was not promoted to test, and the empty cells are the method working
rather than a gap in it: a configuration that loses on dev does not get a second
chance on held-out data. Reporting the cells empty and saying why is cheaper
than dropping the row and leaving no trace that the idea was tried.
The paper already reports its losing LoCoMo variants this way. This one had the
numbers and not the sentence.
deploy-site.yml's header states the build-to-deploy handoff runs through the
Hanzo Platform GitHub App and .platform.yml, and adds that "until that webhook
is live this workflow just publishes the image". There was no .platform.yml in
this repo, so the second half was the permanent state and nothing said so: the
image built green, ghcr.io/hanzoai/papers took a fresh tag today at 19:32, and
papers.hanzo.ai went on serving the build before it. A pipeline that publishes
and does not roll is not a slow deploy, it is a missing one, and the only
evidence was a 404 on a paper nobody could fetch.
tag-pattern is the git tag, matching app, gallery and playground. The branch
build publishes `main` and a SHA; floating tags never reach a cluster, so that
image was never going to move the site whatever else was wired.
amd64 alone, for the reason recorded beside the same decision in hanzo.yml: the
context is `site`, the door refuses a context below the repo root, and delegate
is the only road to a second architecture.
The build has been red since 2026-09-03, when platforms gained linux/arm64. The
caller has been on mode: buildx since 2026-09-10, and buildx is one runner, so
the shared workflow refused rather than emulate — correctly, and every published
tag stayed -amd64 through the whole period. Declaring two platforms did not
produce two; it produced a refusal.
Both settings are individually right and only wrong together. arm64 needs
mode: delegate, which builds each half natively in-cluster, and the door refuses
a context below the repo root. This image has one: context: site, so a relative
COPY does not read the fifty PDFs beside it. So delegate is closed to this repo
as it stands, buildx is what is left, and one architecture is what buildx is.
This is not the end state. replicas: 2 with no nodeSelector can place a replica
on spark, which is arm64, where a bare amd64 manifest runs under qemu until it
faults — which is the estate's stated reason delegate is the default. Getting
there means making the context the root and giving the repo a .dockerignore that
earns its keep, since the context then becomes the whole repository. That is a
build redesign and it is written down here rather than done in passing.
Both workflows asked for hanzo-build-linux-amd64. No online runner advertises it:
the amd64 pool that serves that alias is down, and two linux-amd64 runners sit
beside it carrying the bare label. So a build that could have run did not, and
the failure looks like nothing at all rather than like a queue.
runs-on is the machine a job needs. What the job is FOR is already the workflow's
name. Folding the two gave labels that read like a capability and were only ever
a habit, and this is the second time that habit has cost a build — the lux tree
lost three days to lux-linux-amd64, which was likewise not a label.
ci.yml already spelled it [linux-amd64] and already ran.
The benchmark paper was built and never published: papers.hanzo.ai served 32 of
the 50 PDFs in this repo and not this one, so the results every table in it
carries were not downloadable by anyone.
It is in site/public/pdfs and in the site manifest now, and the tables it inputs
are regenerated from the current runs. Two of those runs finished today after
four days unable to authenticate, so locomo-answers gains its oracle rows and
loses two partials that were flattering — enso-flash read 54.6 F1 at n=57 and
reads 45.1 at n=282.
The substantive change is to what the paper may claim. Naive's 91 / 57 was
described here as circulating without a published method, not locatable, and not
cited. It is published, at usenaive.ai/lab/memory, and although that page names
no dataset it is identifiable from its own comparison column: its baselines are
CAR's to the decimal, 78.0 / 30.2 and 54, 28, 18, 7, with the multi-hop scores
collapsed into one "<=7%". A table is identified by its baselines.
So the benchmark is MemoryAgentBench FactConsolidation, which this paper already
reports, and the comparison is ours: 98.3 / 84.5 with no reader against their
91 / 57 on a matched gpt-4o-mini backbone, +7.3 single-hop and +27.5 multi-hop.
Their per-lane split and protocol are unpublished, so it is pooled figures being
compared and the paper says so.
The prior-work section describes the 2022 backend by category, and the
comparison table and production section cover the systems Base is
measured against. hanzo-stack-comparison and hanzo-datastore drop one
reference each. hanzo-base.pdf had no source in the repo and is
superseded by hanzo-base-runtime. Committed PDFs rebuilt with make.
Co-authored-by: Hanzo Dev <[email protected]>
Its log ends mid-step with no error line, no failure marker and no summary:
the truncated signature of a killed job. It ran during the window when
git.hanzo.ai was down (the forge pod was preempted and then blocked on an RWO
Multi-Attach while a storage-migration job held its volume), so the runner lost
the control plane mid-build.
Nothing in this repo changed. Empty commit to get a clean signal now the forge
is back.
Co-authored-by: Hanzo Dev <[email protected]>
zenlm/papers had a sweeping withdrawal pass, 5deeeaa, and the owner reverted it in
f34f609 for asserting more than it verified. That objection sets the rule here: a
claim changes only where the proof is in the paper itself or in arithmetic, never
because a run could not be found. Twenty-seven of the eighty-one zen papers meet
that bar. Every correction quotes a number the paper already carries or one derived
from its own numbers by a division a reader can repeat.
Twelve papers led with a figure that appears in no row of the table it summarises.
zen-agent averaged GAIA 83.1/68.4/42.3 to 71.2 while its four baseline rows are each
the plain mean of their own three levels; the mean is 64.6. zen-embeddings-retrieval
and zen3-embedding claim MTEB averages of 72.4 and 74.3 over tables that supply their
task counts, where the 56-task weighted means are 67.1 and 67.4.
zen-mathematical-reasoning opened with five figures, none of them any row, and
explained one as best-of-32 sampling when its own sampling table puts best-of-32 at a
different number. zen-dso-protocol claimed 94% of centralized quality and a 78%
bandwidth cut against tables reading 99.4% and 99.8%-and-better, the second of them
the table that claim captions. zen-synthetic-data claimed an 8.4-point MT-Bench gain
on a scale that runs to 10, from a 7.84 baseline, where its table says 0.88.
zen-3d quoted the Chair column as the ShapeNet result. zen-multilingual understated
its own XNLI average. Also zen-hallucination-reduction, zen-distributed-training,
zen-finetuning, zen-legal-ai and zen-coder-flash.
Eight more are settled by arithmetic against the hardware or the parameter count.
zen-nano, zen-eco and zen-scribe each report INT4 needing as much memory as FP16 or
more, while their own FP16 and INT8 rows are exactly two and one bytes per parameter;
zen_family_overview already carried the right values. The two zen-designer papers size
a stated 235B model at 220 GB in FP16, which is a 110B model, and zen-quantization puts
the same model at 470 GB. zen-omni and zen-next recommend cards smaller than the memory
the same row requires. zen-live captions a latency table to an A10G when its own
deployment table assigns that 98 ms to the H100. zen-hardware-optimization calls a
throughput table FP8+INT4 when its cumulative table reaches the identical 31,200 tok/s
through INT4 + FP16.
Six papers share one template whose visual benchmark block bundles two metrics
computed over images a model generates with one computed over text a model emits
about an image. No model produces all three, and the block went to four papers across
four modalities, so each received at least one metric it cannot compute: VQA v2 and a
token rate for two diffusion models, FID and CLIP score for two vision-language models.
Each now keeps the rows its own stated output type can produce.
Throughput is the one category where the defect is the missing condition rather than
the number. Decode reads the active weight set once per token, so a single stream
cannot outrun bandwidth over footprint, and zen4-mini, zen3-nano and zen-coder-flash
all report above their own bound. Batched serving would make those figures legal and
none of the three records a batch size, so the numbers stand and each table now carries
its bound and the arithmetic behind it. AIME gets the same treatment in
zen-mathematical-reasoning: a score that is not a multiple of 1/30 on a 30-problem exam
is legal under averaging, and the caption now says which row has its sample count on
record and which do not.
What was examined and left is in LLM.md with the reason in each case. Training fleets
absent from this estate prove nothing about models trained on rented capacity.
zen-reranker's 98% semantic preservation is uncited rather than contradicted.
zen-safety-evaluation and zen-vision-architecture state no weighting, so their averages
are not determined. zen4-coder-flash puts FP8 on an A100, and Ampere has no FP8 tensor
cores, but its claims there are footprint claims and FP8 weight-only storage does run
on Ampere.
All twenty-seven rebuild under latexmk -Werror. Nineteen have diverged from their
counterparts in zenlm/papers and six exist only here, so those fixes do not reach the
other site. zen-3d and zen-agent were byte-identical across the two repositories until
now, and are the two to mirror first.
Co-authored-by: Hanzo Dev <[email protected]>
All ninety-six papers from 86d8915 were audited for numbers presented as
results. Three hundred and fifty-three turn out to be presented as measurements
with nothing behind them, and not one paper in the batch cites a harness, a run,
a checkpoint, a seed or a date. The thirteen product papers at the root are the
part of that this commit fixes.
Each carried a production-operations figure in its abstract — 200+ models across
48 GPUs at 99.9% availability, 2M authentications daily over 1,200 tenants,
$240M processed at 99.97%, 15TB across 400 tenants, three years of ledger
operation without a discrepancy, a 65% cut in mean-time-to-diagnosis, per-request
overhead against nginx and Caddy, an iPhone 15 Pro latency table. None of the
repositories behind them holds a benchmark that produces those numbers; no
deployment in this estate records those volumes; the hardware two of them name
does not exist here; and several papers are dated years before their own code was
first committed.
A design target can be relabelled. These could not, because a target is a claim
about the future and these were claims about a past that did not happen. So they
are removed, and every paper now carries a short section naming what it said,
why it is gone, and what run would put a number back. Nothing was replaced with a
number that was not measured either.
Two papers are different. pubsub and ledger ship harnesses that measure exactly
the quantities their tables report — the NATS benchmark suite in one, a
parallelism-flagged TPS harness in the other. Those tables stay, with their
provenance stated: not traceable to a recorded run, and here is what would make
them so. The gap is a run, not a mechanism.
The eighty-one zen/ papers hold the other 321 and are left alone. zenlm/papers
already had a sweeping withdrawal pass reverted for asserting more than it
verified, the models are largely real, and several of these are template-
generated with one pretraining sentence filled in for different models — that
needs a decision about the family, not an edit per paper. LLM.md records the
finding, the shapes it takes, and the two zen papers that already do it right.
Co-authored-by: Hanzo Dev <[email protected]>
hanzo-multi-hop-retrieval and locomo-subject-scope were written, built and never
listed, so both 404'd while hanzo.ai linked to them; hanzo-dormant-agents was
built and never copied out of pdfs/. All three are in the manifest with their
PDFs now.
Each paper a benchmark page cites links back to the page rendering its numbers,
so the pair reads from either end: the paper states the result, the page shows
the current run of it. The subject-scope entry keeps its harness pinned at
v0.2.4 — that is the tag its numbers were taken at — while the bench page
carries v0.3.0 and says which figures are newer than the paper.
Co-authored-by: Hanzo Dev <[email protected]>
hanzoai/ci delegates by default now, and the door builds the whole repository at
one commit, so images[papers] and its context: site would not survive the trip.
Co-authored-by: Hanzo Dev <[email protected]>
At \small in a two-column layout the four-column tabular overflowed the
measure by 30pt and landed on top of the neighbouring text, and the
paragraph that names three generated files stacked three long \texttt{}
tokens on one line for another 30pt. Both are gone: \footnotesize with
tighter column separation, GPQA and LCB as row labels with the units in a
line under the table, and the .tex suffixes dropped from the names so the
line can break. Overfull boxes are back to the six this paper already had.
Co-authored-by: Hanzo Dev <[email protected]>
The router repository's stored replay names a strongest single arm per
benchmark. We print fable-5 at 38.2 on HLE and gpt-5.5 at 85.5 on CharXiv,
both of which agree with it to the digit, and we leave LiveCodeBench blank.
On GPQA we print gpt-5.6-sol at 91.9 where the replay names grok-4.5 at 92.9,
over a wider pool than this gateway serves. Three cells sharing a source and
the fourth not is worth saying out loud next to the row whose margin the
fourth cell decides.
Co-authored-by: Hanzo Dev <[email protected]>
The measured cells are injected from a generated file, which guarantees the
table matches a file but not that the file is the only one. It was not.
results-data.tex was built up across eight commits between 2026-07-15 and
2026-07-17, each naming its seed, sample size and system count. The three
files the paper actually prints arrived together in 54f5713, "wip: preserve
in-flight work", which named no run at all and rewrote main.tex around them.
The two sets disagree on GPQA Diamond (enso 92.9 vs 87.9, ultra 92.9 vs 90.4)
and LiveCodeBench (93.7 vs 91.4, 89.1 vs 85.1), and agree on HLE and CharXiv
exactly -- which is how we know the later file is the earlier one with two
benchmarks re-run and two carried forward, and not a re-roll. enso-flash is
populated for exactly the two that moved.
So: rename results-data.tex to results-prior.tex, say in its header that
nothing inputs it and why it is kept, and report the disagreement in
Limitations with the gaps in items (ten questions of 198 on GPQA, four of 175
on LiveCodeBench) against the binomial error, and with the cost gap -- $50.6
to $11.1 on GPQA -- marked as the configuration change it is rather than
sampling. enso-bench and emit_paper.py are on no machine we have, so neither
run can be re-executed and neither can be adjudicated; the paper prints the
later one and the spread is the honest uncertainty.
Drop "edging the best single arm" from the evaluation. One accuracy point at
n=198 is two questions, inside the standard error of either cell. It is a
match, and the result on that row is the cost. The router repository's
held-out replay agrees: over the same items the strongest single arm scores
exactly what the router scores, on all four benchmarks.
Also fix the build. 54f5713 renamed the vendor out of the prose but left the
bibliography key behind, so six citations resolved to nothing and
latexmk -Werror failed on a paper nobody had rebuilt.
Co-authored-by: Hanzo Dev <[email protected]>
zeekay
z