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.
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]>
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]>
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]>
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.
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.
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]>
package.json wants @hanzo/font ^1.9.3; the lockfile still pinned 1.9.2, so
npm ci refused on a clean checkout and every build had to fall back to a
resolving install. A lockfile that disagrees with its manifest is not a
lockfile — it is a second, contradictory manifest.
Co-authored-by: Hanzo Dev <[email protected]>
The site's type is Zen, mounted on main by ed9deb0. Two places that mount
cannot reach on its own: form controls do not inherit font-family, the UA
sheet pins them to a system face, and the UA gives code, pre, kbd and samp
its own monospace default. Both are stated once, as the two families this
site has.
The rest of the original change mounted the faces a second way; main had
already done that, so only this rule is carried.
(cherry picked from commit bbe721fd974be072173f7e6307318291b0c5bdf0)
Co-authored-by: Hanzo Dev <[email protected]>
Ranges drift once nothing moves them: a caret that has not been rewritten
since it was written pins whatever was current that day, and an exact pin
cannot even take a patch. Both are updated here.
One line per package, so a surface reads the same components, the same
tokens and the same face as every other one.
Bylines, paper authorship, correspondence addresses and the founder blurb under
each post named an individual. They name the organisation that published the
work instead: the brand on posts and pages, the research byline on papers, and
research@ in place of a personal address. Both are what these repositories
already used elsewhere — nothing new was coined.
Co-authors are untouched. Where a paper named someone else alongside, they stay
named; only the one byline changed. Bibliography entries, running heads,
PDF metadata and affiliations move with it, so a citation still resolves to
whoever the cited paper names.
Sample and fixture data uses the placeholder name these tests already use
elsewhere, so no assertion changed meaning.
A version written into a manifest is written into every manifest that wants it,
which is how eslint came to exist in a hundred and four forms across this estate
and how a package came to resolve twice at run time. The catalog moves the number
out of the manifest: a manifest names the package, the workspace names the
version.
Four are held below their latest because the newer release cannot be used, and
the reason is recorded rather than the version alone: @noble/hashes 2 renamed
every subpath the web3 stack imports, @splinetool/runtime 2 depends on a package
that was never published, @dynamic-labs 5.4.1 the same, and react-resizable-panels
3 points its types condition at the bundle.
layout.tsx loaded Geist and Geist Mono through next/font/google, and global.css
read them back as --font-geist / --font-geist-mono. Geist is Vercel's face, and
fetching it put a build-time request to Google on a site we compile on our own
hardware and serve from our own image.
@hanzo/font ships Zen and Zen Mono as self-hosted variable faces, so the two
next/font constructors become two imports and the theme reads --font-zen-sans /
--font-zen-mono. Nothing else here declares a theme, so those values reach the
utilities and the default family unshadowed: the export carries two woff2
files, family Zen and Zen Mono, vendor HNZO, and neither Geist nor
fonts.googleapis.com appears anywhere in it.
The hero image in .github named Inter first; it names Zen now.
Every dependency on a @hanzo/@luxfi/@zooai package names the same version across
the repo: a catalog entry where pnpm supports one, an exact pin where it does
not, and a range only where a peer genuinely means one.
pnpm itself is pinned too — the estate ran eighteen different versions, five of
them too old to read a catalog.
An audit of all 68 published papers found that 51 were machine-generated in a
three-day window and carry no measurement of a Hanzo system: across the
29-paper product block, 711 numeric claim-sites yielded zero measured values.
They are backdated on the live site to 2024-2025. The defects are not subtle
and a reader disproves them with a browser and a calculator — a paper reports
9.2 million blocks per second, one block per 108 nanoseconds; another reports
8,412,893 jobs processed on a chain that answers net_peerCount with zero, and
a second paper reports the identical figure for a different system; a third
prints a user total its own arithmetic contradicts by 170x. Two papers on
retrieval and inference cite benchmark placements that appear on no
leaderboard.
The site keeps twelve papers. Each is from the human lane, each names its
harness and its box, and several report losses — the engine paper's Vulkan,
ROCm and Metal rows are all below parity, which is precisely why it can be
trusted about the one win it claims. Everything removed stays in git; nothing
is lost, and a paper returns when it can support what it says.
Three of the twelve needed a correction first. hanzo-cloud-economics headlined
3.5M lines of dead code deleted while stating 3.07M -> 1.06M one clause later;
the difference is 2.0M and the paper now says so. hanzo-network-whitepaper
claimed 29.5x storage savings as an observation — it is BitDelta's published
result and is now attributed, and its date no longer precedes the work.
hanzo-unified-tenant-cloud cited HIP-0032, which was deleted with the rest of
the contradicted standards; the concern lives in HIP-0405.
Co-authored-by: Hanzo Dev <[email protected]>
One server, one version, one tag spelling. v0.5.1 is the only tag carrying
79ac4f9 (serve directory index in place), so stale pins served a DIFFERENT
URL contract: docs.hanzo.ai still 301s /x/ -> /x/index.html while every
v0.5.1 host does not. Also 0.5.1 (yadota) was never published as a tag, and
the -amd64 suffix leaked an architecture (a place) into a version (a value).
Add the kernel-DSL campaign pair:
- refutation-driven-perf (Paper 08): the refutation-log methodology and
measured win ladders across gfx1151 / GB10 / M4 Max.
- evolutionary-schedule-search (Paper 09): schedule search over the
monomorphized DSL and the continual-improvement loop it anchors.
Each ships root .tex + .pdf, a served copy under site/public/pdfs, and a
site catalog entry (site/src/config/papers.ts) with a companion cross-link.
INDEX.md regenerated via `make index` (218 papers, 211 compiled).
The paper has been in the repo since it was written (hanzo-router/main.tex,
indexed in INDEX.md) but was never added to the site config, so
papers.hanzo.ai/hanzo-router 404s — including from the "Read the paper" card on
the docs Smart routing page and the hanzo.ai landing, both of which cite its
cost analysis.
A page exists when the paper has an entry here (generateStaticParams maps over
siteConfig.papers) and a PDF at the pdfUrl, so this adds the entry alongside the
other engine/AI-infrastructure papers and publishes the built PDF. The abstract
keeps the paper's own scope line: it claims no measured benchmark saving, only
an itemized cost model.
- site (papers.hanzo.ai): add hanzo-unified-tenant-cloud to the measured
infrastructure section and serve its PDF
- INDEX.md: regenerate — now covers all 198 standalone papers (was 175,
missing kernel-dsl/kernel-optimization/router/unified-tenant-cloud et al);
add scripts/gen-index.sh + make index so the catalogue stays honest
- README: general-availability note + unified-tenant-cloud highlight
- cover: drop the CONFIDENTIAL stamp — the catalogue is published
Co-authored-by: Hanzo Dev <[email protected]>
Replace the GitHub Pages publish (broken since 2026-04-10 on the org-wide
Actions artifact-storage quota) with a standard GHA workflow that runs entirely
on Hanzo infra: build the Next.js static export into a hanzoai/static image on
the self-hosted hanzo-build-linux-amd64 pool, push to ghcr.io/hanzoai/papers,
then roll it onto the operator-managed `papers` Service CR (hanzoai/ingress +
static plugin) from hanzo-deploy-linux-amd64. No GitHub-hosted builders, no
Pages artifact quota, no kaniko/PAT. DNS cutover (Cloudflare → hanzo-k8s LB) is
the remaining one-time step.
The 'Cost at scale' section claimed cloud spend 'fell approximately 97%',
contradicting this paper's own ~90% ($35K->$3.5K/mo, ~$380K/yr) and the
canonical cloud-economics staging (achieved ~90%; ~97%/$1,200/mo is the
not-yet-reached target). Also matches the sentence's own 'order-of-magnitude'
framing. Rebuilt PDF + synced to site/public/pdfs (deploys to papers.hanzo.ai).
- hanzo-vs-claude: prominent 'one engineer on Hanzo stack vs team on Claude' section
(anonymized audit: ~250-900x lower $/LoC) + theoretical mechanism + switch CTA.
- one-pager: cloud-cost aligned to ~$3.5K/mo (~90%, ~$380K/yr) matching the paper;
suite count 16->22.
- site: real Hanzo mark (@hanzo/logo) in header; PDF embed hides TOC/thumbnail sidebar
(navpanes/toolbar=0); vs-claude card abstract leads with the productivity hook.
- README: added the 6-paper engine cluster.
zeekay
