Routes, trust boundaries, deployment, and public cache behavior.
ZergLang public surface
Status: implementation and operations guide. This document is not normative language authority.
The public ZergLang surface is one origin with four independently versioned sources of truth:
| Public surface | Authority |
|---|---|
| Guides and specifications | checked-in docs/ and spec/ revisions |
| ZL256 tasks and profiles | content-addressed benchmark catalog and task files |
| Benchmark results | signed, immutable publication bundles |
| IDE downloads | immutable GitHub Releases and release manifests |
The website is a read-only projection. It must never become the only copy of a specification, release, benchmark task, or result.
Route contract
/presents the current language status without implying stable Core-1./downloadsadvertises only platforms and channels present in a verified release manifest. An unavailable feed is shown as unavailable, not replaced by a guessed version./docscontains non-normative guides./specdistinguishes stable Core-0 authority from cumulative Core-1 previews and preserves anchors into the checked-in source revision./benchmarksshows the ZL256 maturity funnel and keeps language conformance separate from model synthesis./benchmarks/zl256/tasks/:category/:slugshows the task revision, public context, public cases, normative clauses, and official observations./runs/:runIdresolves one immutable, signed evidence bundle./comparecompares compatible runs and refuses misleading performance comparisons when machine or toolchain fingerprints differ./roadmap,/updates, and/communityare informational at launch.
ZLM1 and ZLM2 remain checked-artifact format names. The dashboard labels
its score families Language Conformance and Model Synthesis.
Trust boundary
The production image contains only the generated public content projection. It does not contain the compiler source tree, held-out benchmark cases, executable oracle code, active synthesis reference solutions, CI credentials, or signing keys.
Official evidence is created by protected source-repository workflows and published by a distinct public-repository workflow. The latter revalidates all digests and signs a public manifest with the benchmark evidence key. It never uses the IDE updater key. The site fails closed when a manifest, signature, digest, or schema is invalid.
Candidate code from model-synthesis runs may be public. The dashboard shows its signed path, size, digest, and contamination warning, then links to the immutable GitHub Release bundle. Candidate bytes are not copied to Pages.
Deployment
Production and staging are separate Fly applications in the epoch-ai-in
organization, with Los Angeles (lax) as the primary region. Production keeps
one small instance available; staging may stop when idle. Both expose
/api/health.
The deployment workflow builds one immutable container image, verifies it in staging, and promotes that exact digest to production. Production and staging use different app-scoped deploy tokens. A deploy does not mutate DNS or the IDE updater feeds.
The apex zerglang.com is canonical and www.zerglang.com redirects to it
with HTTP 308. Registrar records are changed only after the Fly hostname,
health endpoint, TLS certificate requirements, and exact rollback values are
known. Nameservers, mail, DMARC, Domain Connect, DNSSEC, and unrelated
verification records are outside the deployment’s authority.
Cache and availability behavior
Specifications and the task catalog are embedded at build time and remain available during an upstream outage. Release and benchmark indexes use bounded server-side caching. A stale, previously verified index may be displayed with its age; an unverified response is never admitted into the cache. Run manifests and assets are immutable and may be cached indefinitely by content identity.
No third-party analytics or public write endpoint is enabled at launch.