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]>
The control was run over the 2x2 and the reach figure as well as the main
table, and leaves all three byte-identical, which is what the abstract already
claimed. Section 8.1 said only Table 1.
Co-authored-by: Hanzo Dev <[email protected]>
A rerun of the measurement at hanzoai/semantic v0.2.4 found the result sound
and some of the prose around it not. Three statements were false. The subject
resolver matches any name the conversation uses and not only the two speakers,
so 11 questions fall back to searching everything, not 22. Deleting the derived
facts moves six more cells than the sentence admitted, and moves them both
ways: single-hop F1 up a thousandth, reach down two. And constant abstention at
0.228 is above every arm that has to retrieve, but not above the oracle's
0.252, which the paper's own Table 1 prints two pages later.
Two claims outran their evidence. "At every matched silence rate" generalized
from four wide-gap points past an 8% crossing where the gap is 0.002, and below
that rate the flat index cannot be matched at all; the sentence now says which
rates were measured and what happens at the quiet end. And the adversarial
questions carry no reference answer — the field the dataset gives them holds
the distractor, "yoga" for the worked example — so the paper no longer
describes a reference saying the conversation does not say.
"Scoped" named both a specific arm and a general property. Arms are now set in
typewriter and mean one thing each, subject scope is the factor, and the
abstract says which effect +0.152 is. Differences are taken from the unrounded
scores and rounded once, which §2.2 states and which moves the claim-span
effect to -0.029 and the interaction to +0.179.
Section 13 claimed seven commands produced every number, and at least six sets
came from nowhere in the repository. The harness now computes them: -stats
reads a predictions file back for the constant-abstention score, the AUCs and
the bootstrap intervals, and the run prints sessions, build totals and the
subject counts. The commands missing from the table are in it, and the four
figures that no command produces say where they come from.
The measurement, the tables and the conclusion are unchanged. Five interval
endpoints move by a thousandth, because the bootstrap is now enumerated over
all 92,378 resamples instead of sampling 10,000 of them.
Co-authored-by: Hanzo Dev <[email protected]>
A graph-structured memory beats a flat turn index on LoCoMo's adversarial
questions, 0.502 against 0.200, and the paper is mostly about what that is
not. The aggregate usually quoted for the benchmark is degenerate: constant
abstention scores 0.228 and beats every system, because a quarter of the
questions award a point for declining. Emptying the knowledge graph leaves
every figure byte-identical. Removing the inference layer, which derived 44
facts from 23,942 claims, moves nothing at three decimals.
What is left is a 2x2 over what is indexed against what a query may reach.
Subject scope alone is worth +0.152, the claim-span unit alone -0.030, their
interaction +0.180. The mechanism is reader-independent: the scoped index can
reach 27% of adversarial evidence against the flat index's 96%, and only the
scoped index's retrieval confidence carries any signal about whether a
question is answerable at all (AUC 0.698 against 0.514, chance).
Make now rebuilds a paper when its figures, sections, bibliography, local
style file or the shared preamble change. It did not, so editing a figure left
`make` reporting a stale PDF up to date. The touch after a successful run
records what latexmk established, so make and latexmk agree on what is current.
The forge reads .github/workflows natively and github.com reads nothing else,
so one directory serves both planes instead of two conventions that disagree
about which one is live. The reusable in hanzoai/ci already lives there, so a
caller naming that path now resolves to a file that exists.
Co-authored-by: Hanzo Dev <[email protected]>
hanzo-build-linux-amd64, lux-build-linux-amd64, zoo-build-linux-amd64 and
every other org-prefixed spelling all meant the same machine. Which org a
job belongs to does not change which host can build it, so the org bought
one pool name per org per arch and each could go stale on its own -- the
evo host alone answered to fourteen names for one label.
One vocabulary now: linux-amd64, linux-arm64, macos-arm64, win-amd64. The
generic labels every plain workflow uses (ubuntu-latest, self-hosted) are
untouched, so naive CI keeps working.
Co-authored-by: Hanzo Dev <[email protected]>
hanzoai/ci keeps the reusable at .github/workflows/build.yml — the one path
both planes resolve, since github.com reads a reusable only from there and the
forge reads it too. The v1 tag moved with it, so a caller still naming
.hanzo/workflows/build.yml asks for a blob that is not in the tree:
InsertRun: read hanzoai/ci@v1:.hanzo/workflows/build.yml: object does not exist
The caller itself stays at .hanzo/workflows/cicd.yml on purpose: github.com has
no runner for these labels, so a caller placed there could never be scheduled.
Co-authored-by: Hanzo Dev <[email protected]>
Both report benchmarks that already live in hanzoai/cloud under bench/, so the
numbers have a script behind them rather than a spreadsheet.
hanzo-dormant-agents takes apart the estimate that costs an agent as a process.
State, execution and isolation are separable and differ by five orders of
magnitude: a dormant agent is 477 bytes on disk and resumes in 0.034 ms, a
parked loop is 601 bytes of heap, and the isolation boundary — the expensive
one — is only owed by an agent actually running. The paper argues the container
is worth its price where it is needed and says so; the claim is about which
agents are charged for it.
hanzo-multi-hop-retrieval is a negative result. On LoCoMo a dense retriever
finds every required turn for 78.2% of single-hop questions and 22.7% of
multi-hop ones, but finds at least one required turn about 80% of the time in
both — so it understands the questions and cannot reach all of the answer. Four
retrieval policies over one fixed index move that by at most 0.7 points and two
make it worse. A diagnostic says why it was never going to work: 95.4% of
multi-hop evidence spans sessions and the median worst-ranked gold turn sits at
rank 67, so the missing signal is linkage rather than similarity. Publishing the
dead end is the useful part.
Each paper carries results-data.tex, generated from the runs, and prints XXX in
place of any constant that file does not supply — a number cannot drift from its
measurement without the drift showing on the page. Both compile under the CI
gate's flags, -Werror included.
INDEX.md is regenerated by make index, which also picks up the papers added
since it was last written and the header its current generator emits.
Co-authored-by: Hanzo Dev <[email protected]>
The measurement belongs to the monitor. hanzo-vm folds the kernel, the command
line it builds, the root image and the shape into an extend-only SHA-384
register under the TDX extend rule, and its bind is the 64 bytes a hardware
report carries as caller data. hanzod signs that bind and publishes a record;
computing a second number here would be a second answer to a question that has
one, and it would not fit a report.
States the trust base plainly: host-asserted evidence says a node made a claim,
not that the node fed those images to the monitor. hanzod cannot produce an SNP
or TDX report at all — those are asked for from inside a guest — so it carries
what the monitor found and does not claim it.
Reports a run on M1 Max end to end, and a record checked with OpenSSL and a
re-fold of the register, using no Hanzo code.
Co-authored-by: Hanzo Dev <[email protected]>
An outside operator sells inference on hardware we do not own. Two properties
have to hold before we pay for it automatically: the prompt stays confidential
on a machine its owner controls, and the operator cannot bill for a model it
did not run. Confidential computing answers the first directly and the second
only by implication, and the paper keeps those apart.
It specifies the flow (measured image, launch, attestation-gated key release
from KMS, sealed session), the field checklist a verifier must actually run for
SEV-SNP, TDX and a GPU in confidential mode, and the settlement receipt that
binds the model commitment, the decoding regime and the input to the output --
adding the tokenizer digest, the sampling seed and the raw-input digest that
HIP-0901's binding does not cover, so an auditor can replay a request exactly
rather than testing it statistically.
Then it says where this stops. A measurement is a hash of bytes, not a proof
about what those bytes do; a model commitment is membership, not use. "The
advertised model produced this output" is inherited from five named
assumptions, and the receipt has no evidentiary value if any of them fails --
which is different from the one cryptographic statement available, the
Freivalds check over an exact integer accumulator. Every guarantee is
classified cryptographic, hardware-trust, economic or open, and execution
integrity on the floating-point path is open.
Grounded in the tree rather than in intent: the privacy-tier crates verify with
mocks that return success; hanzo-attest declares snp/tdx and refuses them by
name, which is where the real verifier belongs; the on-chain evidence backends
are fail-closed with an empty voucher set; and the attestation verifier they
depend on signs a 48-byte Lux header with no report-data field, so the binding
those contracts document cannot yet be checked. One vendor root is embedded,
Intel's. The reachable bench host exposes no CPU TEE, so nothing here is
measured on confidential hardware and the paper says so.
Co-authored-by: Hanzo Dev <[email protected]>
Specifies the compute ledger of the Hanzo sovereign L1 on Lux. The chain is
not new: birth is CreateNetworkTx/CreateChainTx/AddValidatorTx/ConvertNetworkTx
against the Lux P-chain with security.Mode{Admission: Open, Manager: Contract},
finality is the Quasar ladder, and the attestation verifier is the one already
compiled into the precompile block.
Separates the two money flows the deployed code braids together. Escrowed buyer
credit pays for ordered work: a transfer, bounded by the order. Emission
additionally rewards attested work: a mint, bounded by a per-epoch pool and split
pro-rata. Reading precompile/ai, the second flow is presently unbounded — the
reward magnitude is read from computeMinutes and the spent-set key from a nonce,
both fields the claimant writes, so one attested device computes up to 6.44e9 AI
per claim and can produce unboundedly many claims.
Gives the admission predicate A1-A7 over the existing ML-DSA verifier, the
existing TEE device binding and the existing spent set; the fault classes F1-F4
with the bond in the manager contract, since the P-chain balance is a continuous
fee balance and weight zero is removal rather than suspension; and the on-chain
/ off-chain boundary, with the anchor root kept out of the payment path.
Every claim about current behaviour is labelled observed, derived, proposed or
assumed, and cites its file.
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]>
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.
Leadership and team cards, board and founding prose, an AI persona modelled on a
named individual, contributor and partner entries, and personal correspondence
addresses all named one person. The organisation carries them now.
Other people keep their names. Where a card, a board list or a founding line
named someone else alongside, they stay exactly as they were; only the one entry
was removed, and prose that listed two names now reads with one.
Sample and fixture data uses the placeholder name these tests already use
elsewhere, so the IAM username defect the notes describe still reads as written.
The zoo/yapp MIT notice names the foundation that publishes it.
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.
runs-on was a bare scalar. Jobs written that way queue and are never
picked up — link and quest have waited since 10 August, painter since the
5th, none of them with a single success — while repos writing the same
label as a sequence drain within seconds of a push on the same fleet.
Same label, same runners, different shape. It fails silently: nothing errors,
the job simply never starts, so the lane looks configured and does nothing.
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.
Lux Partners Limited is the Isle of Man company and does not appear on a
public surface. Lux Industries Inc, a Delaware C corporation, is the one
these copyright lines, citations and terms name.
Lines binding the name to another legal fact — a domicile, a signed
counterparty, a quoted third-party article — are left alone, because
renaming those would falsify a record rather than correct one.
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.
coinage a token sold and a token minted for work are different instruments
that share a data structure. Backing a mined token converts
compensation back into an investment and gives the position away for
nothing — the same price support comes free from the opposite
arrangement, where a fund holds the token instead of backing it.
Sets out what the protocol mints against, and what a network
adopting it receives: a mint conditioned on verification, four
attestable confidentiality tiers, a no-fork post-quantum retrofit,
and the regime-aware market maker.
soundness closed models cannot be verified by execution but can be verified by
provenance — a session terminating at the vendor endpoint under a
pinned certificate. The guarantee belongs to whoever terminates the
session, so a relay must sit inside an attested boundary for it to
reach the buyer. One market, two verification stories.
Two papers were missing and four understated what we already run.
mechanism the Hamiltonian market maker: price as position under a
regime-dependent anharmonic potential, symplectic so it does not
drift on noise, regime recovered as the latent state of a hidden
Markov model, per-resource states whose prices never cross, one-bit
tenant preference deltas, quotes deterministic given job and market.
States plainly why a constant-product curve cannot express
perishability, deadline pressure or scarcity convexity.
training training and data as market workloads over open weights: the
tradable units and their properties, gradient verification, the
four confidential-compute tiers with local attestation, and
train-without-transfer for weights and corpora that may not be
copied.
soundness attested execution rewritten. At a few percent overhead it is the
default for everything byte equality cannot reach, not a curiosity;
paired with algebraic spot-checks it beats replication on both cost
and coverage.
clearing the pricing layer and the learned per-request router are existing
systems, not proposals; open weights are what a provider network can
actually schedule.
residency the shared-object-plus-tiny-delta pattern appears at the pricing
layer too, and where the analogy stops is the interesting part.
surplus verification for the nondeterministic majority, and training and
data, as sized surplus lines; three additions to the risk register.
Eight papers covering what a decentralized market in heterogeneous compute
needs from a cryptographic and serving substrate, and where the joint surplus
with a market operator actually comes from.
residency personalized agents give compute memory; adapter locality as a
price term, and the serving primitive that separates a 175-
accelerator deployment from a 2-accelerator one
equality bit-reproducible work verifies at O(1) against a canonical, making
determinism a job attribute the market prices
soundness six verification tiers with honest cost models; soundness is a
demand-side parameter, not a protocol constant
retrofit hybrid post-quantum identity and key exchange added to a live
protocol without a fork, from two shipped deployments
custody escrow and payout where the private key never exists, behind a
signer-agnostic assembler boundary
search Las Vegas workloads verify for free; the grind-selection rule and
why container choice can dominate cryptography
clearing exchange mechanics: feasibility before price, four order types
including rent on state, cache as perishable inventory
surplus four sources of joint surplus, sized, with a risk register
Shared preamble at shared/market-preamble.tex so the series reads as one voice.
"Forge" named nothing in this estate. The product is Hanzo Git, the address is
git.hanzo.ai, and the in-cluster service is hanzo-git.hanzo.svc. A generic word
invented for it sends a reader looking for a system that does not exist.
Comments only. ("unforgeable" stays — different word.)
.hanzo/workflows/deploy.yml built ./site and pushed
ghcr.io/hanzoai/papers:<sha7> from `git rev-parse --short HEAD` — a tag no
release can be named by, and the only tag this image had. It has been
redundant since the hanzo.yml/cicd.yml pair landed: the shared lane builds
the same site/Dockerfile and on 2026-08-06 published 1.0.0 alongside it. Two
producers on one push, and the sha kept arriving next to the semver.
The caller is now the only producer. Every build publishes the semver
hanzoai/universe pins plus sha-<short>-amd64 for forensics. The version is
site/package.json's, read by imgver from the image's own context: 1.0.0 is
out, 1.0.1 is next, each derived from the registry rather than typed.
github.com has no runner for hanzo-build-linux-amd64, so a caller under
.github/workflows is a gate that can never be scheduled. This is the ~7-line
caller on the plane that can (git.hanzo.ai git-runner fleet), pinned @v1.
Co-authored-by: Hanzo Dev <[email protected]>
The paper architected investor onboarding around a named KYC vendor from the
satschel lineage — 13 references across five files, including two TikZ nodes and
a \bibitem. That name must not appear in a Hanzo paper.
The architecture is unchanged and is legitimately ours: an external KYC provider
returns a signed attestation by webhook, compliance validates it, the investor
lands in IAM and then on the on-chain ComplianceRegistry. Only the vendor's
identity is removed, so the paper still says exactly what it said.
The \bibitem was never \cite'd — checked before deleting rather than assuming,
since removing a cited key breaks every reference to it. Both TikZ node ids were
renamed with their \draw edges in the same pass, so the diagrams still connect.
Rebuilt: pdflatex clean, 6 bibitems, 165787 bytes.
Co-authored-by: Hanzo Dev <[email protected]>
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]>
Three defects an audit found in published sources, each fixed at the source.
A control-plane IP was printed in a paper the site serves — hanzo-platform's
deployment section named the cluster's address, and the unified-harness paper
named two. A reader does not need our addresses to follow the argument, and an
attacker does not need to scan for them.
Two defense papers carried 'Approved for public release; distribution
unlimited'. That is a Department of Defense distribution statement, issued by a
review office after a review we have not requested and did not undergo. We may
publish these papers because they are ours; we may not claim a marking that
asserts a federal authority reviewed them.
refutation-driven-perf reported a ROCm decode win of 1.07x. That comparison was
refuted on 2026-07-20: the llama-HIP build it beat was a weak one, and against
a properly built llama on the same gfx1151 box we lose both phases — decode
0.91x, prefill 0.72x. Both are now in the table, marked open, and the two
prose restatements of the win are gone. A paper about refutation cannot be the
last place a refuted number survives.
Co-authored-by: Hanzo Dev <[email protected]>
The image job has failed on every run with
::error::REGISTRY_TOKEN is unset, so nothing was published. Add the org secret.
The guard is doing its job; the name is simply wrong. The hanzoai org defines
exactly GHCR_TOKEN, GHCR_USER, GH_PAT, KMS_CLIENT_ID, KMS_CLIENT_SECRET,
OCI_TOKEN and OCI_USER. There is no REGISTRY_TOKEN and never was, so the
suggested remedy — add the org secret — would have minted a second credential
for the registry every other repo already logs into with GHCR_*.
Only ui and papers invented that name. Both now use the GHCR_* pair, and take
the username from GHCR_USER instead of hardcoding hanzo-dev, so rotating the
publishing identity stays a single org-level change.
Tagging is untouched: still the short HEAD sha, which is what a CR pins.
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]>
Every paper compiled. The run's own check printed `missing: 0`, and the single
failing step is the artifact upload:
❌ Failure - Main actions/upload-artifact@v4
@actions/artifact v2.0.0+, upload-artifact@v4+ and download-artifact@v4+
are not currently supported on GHES
git.hanzo.ai is Gitea, which presents itself as GHES, and the v4 action refuses
on that basis before uploading anything. So the red badge was reporting an
action this forge cannot execute, not a broken paper — the worst kind of CI
failure, because it looks like the thing the job exists to check.
v3 speaks the artifact protocol the forge implements. Nothing else changes:
same name, same `pdfs/**/*.pdf` path, same 90-day retention, still
`if: always()` so the PDFs are captured even when a paper fails to build.
Co-authored-by: Hanzo Dev <[email protected]>
Superseded: the Hanzo GitHub App pushes a webhook, so the forge tracks GitHub
without a per-repo workflow. This file called git.hanzo.ai/api/v1/.../mirror-sync
— a Gitea API for a system we no longer drive — and would sit inert in every repo.
One mechanism, in one place, instead of ~350 copies of a cron.
Sequel to HIP-0106. The unified binary removed the mesh and the
container-per-service tax, and accidentally bought a shared link: editing one
line in one of 107 applications costs the same as editing all of them.
Measured, warm, same tree and machine:
monolith 4,347 pkgs 20.23 s 5.6 GB 497.1 MB
plugin 646 pkgs 2.11 s 0.63 GB 43.3 MB
host 313 pkgs 0.65 s 0.31 GB 25.4 MB
A one-app rebuild is 9.6x faster and takes 8.9x less memory, and the host does
not rebuild at all. The monolith's 19.49 s no-op rebuild is the proof that the
cost was never in the edited code.
Also reports the larger finding: one outward-only import put 1,154 packages —
every k8s, aws, grpc and container SDK — beneath all 107 applications. Inverting
it and one Kubernetes client took the shared floor from 1,798 to 644.
States the limits honestly: 83 cross-app import edges remain, several
process-global couplings would break silently rather than loudly across a
process boundary, and the numbers are warm-cache single-machine developer-loop
figures, not CI throughput.
Co-authored-by: Hanzo Dev <[email protected]>
Two commits removed this repo's GitHub workflows without writing the native
replacement they named, so nothing built the papers or the site image and no
run failed to say so. papers.hanzo.ai has served a frozen Pages build since.
Restore both into .hanzo/workflows, which the forge reads:
- ci.yml from 8185428^ build-papers.yml. Compiles with `make -k all` so one
broken paper does not hide the rest, then asserts every expected PDF exists.
The predecessor could not fail: every Makefile rule ends in `|| true` and
prints FAIL instead of exiting. Drops the v<run_number> Release and the
commit-PDFs-back step, which wrote to what is now a mirror.
- deploy.yml from ad31900^ deploy-site.yml. Builds and pushes
ghcr.io/hanzoai/papers:<sha> and does not deploy; the universe CR names the
tag that is live. Authenticates to ghcr with REGISTRY_TOKEN, since a
forge-issued GITHUB_TOKEN authenticates nothing there.
Makefile gains `manifest`, the expected PDFs one per line, so the gate reads
ALL_PDFS rather than restating which papers exist.
.github/workflows/sync.yml becomes the canonical push-refs workflow from
universe infra/ci/sync.yml, replacing a mirror-sync nudge that documented
GitHub as upstream and asked the forge to pull.
Co-authored-by: Hanzo Dev <[email protected]>
git.hanzo.ai mirrors this repo by PULL on a ~10-minute interval, and arcd runs
CI/CD there — so every push waited out that interval before anything built.
This asks Gitea to pull HEAD immediately.
Latency only: the repo already mirrors via the App webhook, so a missing
HANZO_GIT_TOKEN or a failed curl is non-fatal and never fails the push.
Idempotent (mirror-sync just pulls HEAD) and concurrency-coalesced.
This workflow ran on a self-hosted actions-runner-controller pool. ARC is
being decommissioned: CI executes inside git.hanzo.ai (Gitea Actions,
.hanzo/workflows) and delivery is cd.hanzo.ai reconciling the reviewed image
pin in hanzoai/universe. GitHub is a mirror and runs nothing.
Removed rather than repointed — there is no GitHub-side pool to move to, and
leaving it would keep ARC load-bearing.
This workflow ran on a self-hosted actions-runner-controller pool. ARC is
being decommissioned: CI executes inside git.hanzo.ai (Gitea Actions,
.hanzo/workflows) and delivery is cd.hanzo.ai reconciling the reviewed image
pin in hanzoai/universe. GitHub is a mirror and runs nothing.
Removed rather than repointed — there is no GitHub-side pool to move to, and
leaving it would keep ARC load-bearing.
The *.pdf ignore rule in this repo is commented out and 511 PDFs are already
tracked, so the compiled artifact belongs beside its .tex source rather than
being the one paper you cannot read without a LaTeX toolchain.
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).
zeekay
