Versioning

The four-designator grammar

The canonical version key is a single coordinate with four designators:

v.<Release>.<Era>.<Name>-<fix>

• Release— a major-tier deity. The deity’s leading letter isthe release ordinal: A = 1, B = 2, … Z = Zeus. The ordinal is derived from the letter, never from list or file position. The locked Releases bound to shipped history are Aether (A=1, “Foundation”), Boreas (B=2, “Genesis”), Chronos (C=3, “Chronos”).
• Era— an integer counting the major arcs within a Release.
• Name— a minor figure (a non-reserved Greek / mythological name) drawn within an Era. The Name carries day-to-day identity: operators say “Argus is in flight” instead of reciting the coordinate.
• fix— an optional lowercase-letter patch suffix (-a, -b, …). An absent fix sorts strictly before that Name’s -a.

The full coordinate (Release, Era, Name, fix?) is the canonical key — nothing else is identity. A compact three-letter short code is derived from it only for tight badge real estate; the long coordinate always wins on conflict. The operator-facing build stamp currently surfaces vH.1.49 alongside its Release Chronos.

The retroactive-fix model

Touching shipped work under a historical Name does not open a new head node. It mints a retroactive fix under that Name at its historical coordinate: the next-unused fix letter, minted as the maximum existing fix plus one.

• The first retroactive touch of a Name that shipped with no fix mints -a (the no-fix base still sorts strictly before a).
• The next retroactive touch mints -b, and so on: a → b → … → z → aa (lowercase-letter sequence, with carry).
• A genuinely-distinct newsub-effort under the same old Era is not a fix on the existing Name — it mints a new Name drawn from the unused pool, never a fix letter.

This keeps the patch chain attached to the work it patched: a fix to old Foundation work is numbered under that Foundation Name’s coordinate, not as a brand-new head of the current Release.

Codename uniqueness & Release reservation

Every major-tier deity that occupies a Release slot is permanently reserved. A reserved Release-tier name may never appear at the Name layer, and no codename bound to a shipped coordinate is ever reused. A historical Name that collides with a reserved slot is re-drawn from the unused pool deterministically; it is never silently kept and never used twice.

• Prometheusis a reserved Release-tier deity — any historical Name that landed on Prometheus is re-drawn from the pool so the slot stays uniquely the Release’s.
• Demeteris a reserved Release-tier deity — any historical Name that landed on Demeter is re-drawn from the pool so the slot stays uniquely the Release’s.

Consequence: the de-duplicated Iris node keeps its shipped-coordinate Name while a later planned release that reused “Iris” is re-drawn; and a historical Name colliding with a reserved Release slot — the H-arc Demeter node, re-drawn to Daedalus — is re-drawn rather than reused. A re-draw can also be reversed by an explicit, bounded operator decision (the v0.7.10.x node keeps its historical Prometheus name by sanctioned override); the reservation invariant itself is never weakened — uniqueness is an invariant of the model, not a per-page convention.

The five era kinds

An era is the nature/cycle the work belongs to. There are five canonical era kinds. The three roster eras and their identities are single-sourced from the release roster; the Chaos and Gluon kinds are single-sourced from the typed release dossier — the page itself states only what each kind signifies, never a hand-written membership literal.

• Chaos — the ordered primordial-origin kind: everything built before the first codenamed Foundation era, the pre-roster origin slot. Chaos arcs are ordered for history but pre-date the roster eras. The model-sourced Chaos arcs are Pygmalion, Chiron, Echo, Proteus, Jason, Theseus, Midas.
• Aether (Foundation) — the original pre-Genesis foundation era: all pre-Genesis v0.7.x work. Roster mapping: “Foundation” — “Foundation (all pre-Genesis v0.7.x)”.
• Boreas (Genesis) — the Genesis-refinementera — “the new dawn”, refining what Genesis added. Roster mapping: “Genesis” — “Genesis launch arc”.
• Chronos — the benchmark/scoring-refinement era — the H.1.x benchmark/scoring rehaul arc. Roster mapping: “Chronos” — “The H.1.x benchmark/scoring rehaul arc”.
• Gluon — the orderless cross-cutting maintenance kind: work with no nameable feature identity of its own. Gluon members are orderless (no per-era ordinal, excluded from the feature strict-total-order, date-sorted for display only); bucket identity is by KIND, not by time. Its four thematic buckets, single-sourced from the dossier and the canonical KIND token map, are:
  • Aegis — security/hardening
  • Atlas — deps/infra
  • Angelia — deploy/CI/release
  • Lethe — cleanup/refactor-glue

The era axis and the codename axis are independent: the era reflects the iteration’s cycle, the codename is the stable subsystem identity. A coordinate of the form era-of-the-current-cycle + an older codename + a patch-number is valid and expected.

Governance: how new work is placed

Five canonical rules govern how every future change is placed in the coordinate space. They are the canonical prose statement of the same governance the next-coordinate algorithm enforces.

1. The codename-minting rule. All new work flows through exactly one of four branches: a specmints the next codename in the era at patch-number 1; a feature quick increments a patch-number under the subsystem-owning codename (not merely “the active codename”); a hotfix advances a hotfix-letter within the existing patch-number (it does not increment the patch-number); a maintenance / architectural quick lands in the matching Gluon bucket. There is no third path — every change is exactly one of these four.
2. The subsystem-fold discriminator. Mint a new codename only when a change introduces a distinct nameable capability (spec-sized); add a patch-number when a change refines a capability an existing codename already owns (quick-sized); a maintenance / architectural change with no feature identity routes to a Gluon bucket.
3. The Genesis-0 anchor model. Every codename’s entire existing history is grouped at patch-number 0(its “Genesis” entry); the first future quick is patch-number 1.
4. The modular one-target-per-quick rule. Every future quick must declare exactly one explicit append target (era → codename → patch-number). A request spanning multiple codename positions must be split into multiple quicks.
5. The audit-cycle-codename rule. The audit-cycle codename (Asclepius) is the designated landing place for audit-cycle work; future audit cycles append under it as patch-numbers 1, 2, 3, … An audit-cycle codename’s Genesis-0 can be legitimately empty at spec-start (its prior content faithfully attributed elsewhere); the codename and its node are reserveduntil a real audit cycle lands as patch-number 1. This is a deliberately-reserved-empty state, stated explicitly as doctrine — not a defect.

These rules are the canonical prose doctrine; the portable ChronVer.md specification states the same doctrine project-agnostically, and the placement skill is its executable enforcement.

Codenames carry day-to-day identity

Each coordinate is paired with a Greek / mythological codename. The codename is what the dev team and operators use day-to-day instead of reciting the coordinate; the coordinate is the stable handle that orders work and survives renames.

Shipped

• v.G.0.1Cassandrav0.7.9.x
• v.G.0.2Prometheusv0.7.10.x
• v.G.0.3Pythagorasv0.7.11.x
• v.G.0.4Hydrav0.7.12 l-chain
• v.G.0.5Medusav0.7.12 non-l series
• v.G.0.6Papyrusdocs + spine rehaul
• v.G.1.1Genesis Patchesv.G.1.x post-launch fixes
• v.G.1.3Antikytheracpu benchmark chainweb-tuning
• v.H.1.0Hipparchusbenchmark-score rehaul
• v.H.1.1Pheidippidesbench transport push-primary
• v.H.1.2Argusbench-version admin oversight
• v.H.1.3Daedalusdisk as a first-class benchmark entity
• v.H.1.4Triptolemusgreenlight-gated bench reuse + bulk orchestration
• v.H.1.5Nemesisforward-only red → no-stoicism economic gate
• v.H.1.6Perseusmodel-minted version stamp — the versioning rehaul dogfooded as a shipped node
• v.H.1.7Cadmusthe ChronVer versioning foundation, dogfooded — this spec minted as a shipped node through its own placement procedure
• v.H.1.8Cadmuschangelog/era/naming refinement round — Cadmus.1, the second Cadmus stone laid through the same grammar
• v.H.1.9CharonTriton Panel + fleet/disk benching refinement — Charon.1, the second Charon stone laid through the same grammar
• v.H.1.10CharonStoicism-score display rework on /hub/nodes/ — Charon.2, the third Charon stone laid through the same grammar
• v.H.1.11CharonStoicism / earnings-page rehaul — Charon.3, the fourth Charon stone laid through the same grammar
• v.H.1.12CharonTriton-Panel bulk-benching refinement — Charon.4, the fifth Charon stone laid through the same grammar
• v.H.1.13Charonvirtual-prime commitment-redness + Argus Status-icon column — Charon.5, the sixth Charon stone laid through the same grammar
• v.H.1.14Charonper-server virtual-prime redness consistency + always-one-eligible-disk + forced-rebench button — Charon.6, the seventh Charon stone laid through the same grammar
• v.H.1.15Charonsingle-source virtual-prime display — score + colour computed once server-side, rendered verbatim everywhere — Charon.7, the eighth Charon stone laid through the same grammar
• v.H.1.16Charonsingle-source real-node display — a real node’s score + colour computed once server-side, rendered verbatim everywhere; the three duplicate live-score wrappers collapse to one — Charon.8, the ninth Charon stone laid through the same grammar
• v.H.1.17Charonsingle-source EarnScore — "EarnScore" now means ONE thing everywhere (the take-home capacity score), computed once and rendered verbatim on /hub/nodes and /hub/earnings; the earnings page’s live accrual rate is a separate, clearly-labelled figure — Charon.9, the tenth Charon stone laid through the same grammar
• v.H.1.18Charonsingle-source score program complete — virtual slaves, segregated chainweb children and disk entities each gain one canonical server-computed score+colour, and ServerScoreCard retires its competing colour system; every score entity is now computed once and rendered verbatim everywhere — Charon.10, the eleventh Charon stone laid through the same grammar
• v.H.1.19Caduceushub sovereign Ouronet integration — Caduceus.0, the Genesis stamp of the staff-of-Hermes codename: the herald carrying signed transactions across the boundary between the off-chain hub and the on-chain StoaChain through the same grammar
• v.H.1.20Galateareal-launch preparation — Galatea.0, the Genesis stamp of the statue-brought-to-life codename: the shadow→live hard reset, the tiered warmup grace, the ancient-only live-state lock and the TEST/LIVE mint provenance through which the test economy becomes the living one
• v.H.1.21Narcissuspool payout-v2 — Narcissus.0, the Genesis stamp of the true-reflection-in-the-pool codename: the cross-chain consolidation sweep, the single bulk threshold-gated payment, new-account create-and-fund, the never-overpay reconciliation guard, the operator-armed daily run and the operator preview/control panel
• v.H.1.22ArachneOIDC/SSO identity provider — Arachne.0, the Genesis stamp of the one-fabric-of-many-threads codename: the hub becomes a central OpenID Connect provider (RS256/JWKS + discovery + opaque stable subjects), a salted-hash client registry, the authorize/token/userinfo/logout endpoints with S256 PKCE and atomic single-use codes, the CORS/rate-limit/break-glass controls, Pythia wired end-to-end, and the published integration how-to
• v.H.1.23MarsyasPythia node pool — Marsyas.0, the Genesis stamp of the play-through-the-fleet codename: the hub exposes its chainweb fleet to Pythia as IP-keyed slots via a POST-to-read node listing, meters the reads Pythia routes and stores them as they arrive, keeps each slot healthy with autonomous per-IP failover, surfaces a per-container Eye badge in /hub/nodes, and carries an inert-until-armed operator-reward scaffold
• v.H.1.24MarsyasPythXP redefined as usage — 1 PythXP = 1 keyed request served, settled always-on from the usage ledger with its own settle-once marker and retro-backfilled over the whole history, decoupled from the arm-gated Stoicism money path — Marsyas.1, the second Marsyas stone laid through the same grammar
• v.H.1.25MarsyasPythLevel bracket scaffold — the inert-until-configured leveling curve (row index = level, XP thresholds + Stoicism-per-XP rates as money-grade decimal strings) with strict validation and an ancient-gated fresh-confirm editor on /hub/pythia-admin; no level math runs until a curve is stored — Marsyas.2, the third Marsyas stone laid through the same grammar
• v.H.1.26MarsyasPythLevel mint engine — with a curve stored, rewards mint the pure-Decimal bracket integral over each operator’s XP span (deferring per row to the XP-settle verdict so XP and Stoicism reconcile 1:1), the first armed run retro-grants the whole recorded history, and with no curve the legacy flat path runs byte-unchanged — Marsyas.3, the fourth Marsyas stone laid through the same grammar
• v.H.1.27MarsyasPythXP surfaces — the operator /hub/pythxp page (own XP, PythLevel + progress, per-slot contribution, recent settles) under a new Earnings group beside Stoicism, and the Ancient /hub/pythia-pool fleet standings (operators by XP with levels and minted Stoicism, per-slot totals, settle feed) under a new Pythia group beside Pythia Admin — Marsyas.4, the fifth Marsyas stone laid through the same grammar
• v.H.1.28MarsyasFeed economics — the nodes feed sends per-slot earnings back to Pythia as optional-additive fields (operator PythXP + PythLevel, rewarded requests, Stoicism earned as a decimal string, earned-since), the base contract byte-unchanged, plus the Marsyas.1–.5 docs consolidation and the field-name reply handoff — Marsyas.5, the sixth Marsyas stone laid through the same grammar
• v.H.1.29MarsyasPondus plumbing — the request-weight metric (classBase + √gas/2 + bytes/4096, Pythia-computed per request, summed per window) lands in the ledger, the usage report, the operator accumulator and the settle markers, with a keyed×10 baseline fallback for unmetered rows; economics-neutral until the Opus curve consumes it — Marsyas.6, the seventh Marsyas stone laid through the same grammar
• v.H.1.30MarsyasThe hardcoded curve — CURVE_V1 in code: Petitions → PythLevel (1k ×1.1), Pondus → Ergon Level (10k ×1.2), Opus = their sum driving UNA-per-pondus = 5×10⁸ + Opus × 1.25×10⁷ (UNA = 10⁻¹⁵ Stoicism); the mint engine switches to pondus × Opus rate, the runtime economics editors retire for a read-only display, and Pythia gains her public odometer — Marsyas.7, the eighth Marsyas stone laid through the same grammar
• v.H.1.31MarsyasVerified-payee attribution — earnings flow only to a verified Ouronet account (verified node override, else the owner’s verified main account; an unverified override falls through), with unverifiable usage HELD un-settled forever and retro-settling entirely the moment verification lands, surfaced as the "Held — assigned to no one" cache card with the add-and-verify warning — Marsyas.8, the ninth Marsyas stone laid through the same grammar
• v.H.1.32MarsyasPer-IP attribution — Pythia earnings resolve per IP through the owner-locked funnel (verified IP override → verified hub-wide collector → verified Prime → held), with per-(user, account) verification recognition, the no-duplicate-target validation law, the per-IP override panel on Petitions & Pondus, and the profile page split into Identities / Earning-targets tabs — Marsyas.9, the tenth Marsyas stone laid through the same grammar
• v.H.1.33MarsyasThree-tier verification — the account vocabulary settles at Prime / Secondary (Pythia collector) / Tertiary (individual overrides), and the Ownership Verification surface reorganizes to show all three: Prime, the always-shown Secondary position (defaults-to-Prime when unset), and Tertiary split into chainweb-based and IP-based with explicit empty-states — Marsyas.10, the eleventh Marsyas stone laid through the same grammar
• v.H.1.34MarsyasReachable node feed — the feed advertises each slot’s cert-valid public chainweb endpoint https://<hostname> (nginx :443) instead of the firewalled raw IP:service-port, keeping id as the bare IP for reward attribution and dropping hostname-less slots; fixes the earning-blocker where every advertised endpoint was unreachable from Pythia — Marsyas.11, the twelfth Marsyas stone laid through the same grammar
• v.H.1.35MarsyasEligibility keystone — a per-container Pythia-servability probe (SSH-side local curl --resolve <host>:443:127.0.0.1 https://<host>/info: nginx up, cert SAN covers the hostname, chainweb answering) is AND-ed into the one shared health predicate, so the failover sweep rotates off an at-tip-but-unservable container to an eligible sibling on the same IP and the feed advertises only endpoints Pythia can read; plus the three-tier hostname fallback that un-drops the co-located node — Marsyas.12, the thirteenth Marsyas stone laid through the same grammar
• v.H.1.36MarsyasPythia slot map — a new Ancient page (/hub/pythia-slot-map) showing every IP that serves a Pythia slot and the chainweb containers behind it, each one’s tip + Marsyas.12 servability verdict + reason, which container is assigned, and the red IPs with a servable sibling the failover sweep should rotate to (polled live so the swap is visible); plus a probe body-shape fix so a real node whose nodeVersion sits past a truncation boundary is no longer false-negatived — Marsyas.13, the fourteenth Marsyas stone laid through the same grammar
• v.H.1.37MarsyasPythia remediation — a per-node ancient-gated job that makes a chainweb container servable to Pythia by replicating node1’s setup (enable the nginx :443 read-API vhost with the node’s Let’s Encrypt cert on its bare hostname, proxy to the local service port, deny the backup routes, open the firewall to Pythia’s egress), with a default dry-run preview, backup + nginx -t + rollback, and a post-apply re-probe; surfaced as a Make-eligible control on the slot map — Marsyas.14, the fifteenth Marsyas stone laid through the same grammar
• v.H.1.38MarsyasSlot-map redesign + per-IP serve toggle — the Pythia slot map becomes explorer-style (one collapsible entry per IP, paginated at 10, no horizontal scroll) and each IP gains an Ancient "Serve to Pythia" toggle backed by a per-IP denylist that gates the feed, so a viable IP (e.g. the Mining Pool’s chainweb box) can be excluded from the pool at will; plus an apt-install-nginx step in the remediation job — Marsyas.15, the sixteenth Marsyas stone laid through the same grammar
• v.H.1.39MarsyasRemediation coexistence — the remediation inspection reports which process owns :443/:80 and which web servers are installed, so a box hosting a website coexists with the chainweb node on :443 via an nginx server_name vhost (like node1’s box); a non-nginx :443 owner (e.g. Pythia’s own co-located box) is flagged as needing a vhost on that server instead; plus a derived "unreachable — box down" state on the slot map, distinct from a fixable red and self-healing — Marsyas.16, the seventeenth Marsyas stone laid through the same grammar
• v.H.1.40MarsyasCaddy provisioning backend — remediation now serves a box fronted by Caddy (not just nginx): it inserts a marked chainweb site block into the Caddyfile (reverse_proxy to the local service port, backup routes denied) coexisting with the existing site on :443, and lets Caddy’s automatic HTTPS obtain the cert (no certbot), with backup + caddy validate + reload + rollback and a retrying re-probe; a third-party :443 owner is still flagged foreign — Marsyas.17, the eighteenth Marsyas stone laid through the same grammar
• v.H.1.41MarsyasCaddy is the standard — remediation now installs Caddy on a bare box (detecting apt via the Cloudsmith repo or pacman on the CachyOS rigs) with a fresh Caddyfile carrying the chainweb site block, instead of nginx + certbot; existing nginx boxes keep nginx and existing Caddy boxes coexist — the first step of the Caddy-forward, NAT-friendly-serving plan — Marsyas.18, the nineteenth Marsyas stone laid through the same grammar
• v.H.1.42MarsyasExternalisation port (read path) — a per-node externalisation port (default 443, inherited from the machine/host) flows through the read path: the Pythia feed advertises https://<hostname>:<port> when it isn’t 443 and the eligibility probe checks the box’s local :<port>, so multiple machines behind one NAT IP each serve on their own port (like the per-machine SSH ports already forwarded) — Marsyas.19, the twentieth Marsyas stone laid through the same grammar
• v.H.1.43MarsyasExternalisation port (write path) — remediation on a home/NAT box makes Caddy listen on the externalisation port, obtains the cert via DuckDNS DNS-01 (auto-adding the caddy-dns/duckdns plugin + the vault-sealed token, redacted in the preview) and UFW-allows the port; DNS-01 needs no inbound ports so it works behind NAT, and a residential multi-machine IP can finally serve Pythia per-machine — Marsyas.20, the twenty-first Marsyas stone laid through the same grammar
• v.H.1.44MarsyasExternalisation-port setter — an ancient-gated setter for a node’s externalisation port, surfaced on the slot map as a per-container :<port> control (click to set a custom port for a machine sharing its IP, blank/443 to clear), so the per-machine ports for a multi-machine NAT IP are assigned from the UI and flow into the feed, probe, and remediation — Marsyas.21, the twenty-second Marsyas stone laid through the same grammar
• v.H.1.45MarsyasNodes-registry port setter — the externalisation-port setter moves to the Nodes registry (/hub/nodes) as a per-machine ext:<port> control on each server row (ancient-gated, amber when custom), with the canonical public IP + the port threaded onto every row as the foundation for the per-IP grouping tier; the slot-map stopgap becomes a read-only indicator — Marsyas.22, the twenty-third Marsyas stone laid through the same grammar
• v.H.1.46MarsyasNodes IP-tier + firewall tie + archive — machines sharing a public IP cluster under an IP-header row on /hub/nodes; setting a machine’s externalisation port now reconciles a Cerberus firewall_rules row so the port opens on UFW to Pythia; and a node-archive subsystem (auto after >7 days continuously offline, plus manual ancient override) drops archived machines out of the Pythia pool + scoring into a collapsed Archived section — Marsyas.23, the twenty-fourth Marsyas stone laid through the same grammar
• v.H.1.47MarsyasPythia operability round — /hub/nodes renders every public IP as its own card with its machines grouped inside (one eye per IP, owner column widened, ext/archive clicks no longer navigate); the slot map groups containers by machine, shows an X/Y-servable count, and offers remediation on http-3xx redirects; remediation always lands the latest Caddy and stops locking the caddy user out of the Caddyfile; and promoting a DNS hostname to primary re-points the chainweb pin so Pythia follows — Marsyas.24, the twenty-fifth Marsyas stone laid through the same grammar
• v.H.1.48MarsyasCaddy-standard round — new chainweb installs are eligible-by-default (a successful install auto-enqueues the Pythia remediation, so the container serves Pythia the moment it exists, no manual Make-eligible), and an nginx→Caddy migration with a read-only preview + a validate/rollback-guarded convert (known-pattern vhost translation; complex sites flagged manual and left on nginx) on the node’s Tools → nginx tab — Marsyas.25, the twenty-sixth Marsyas stone laid through the same grammar
• v.H.1.49MarsyasPythia hardening — the nginx remediation obtains a Let’s Encrypt cert inline (certbot HTTP-01) instead of blocking, so an nginx box is one click; and a reconcile clears any Pythia slot whose backing has left its IP (moved / archived / removed), run first in the failover sweep, fixing the data behind the eye-on-the-wrong-container bug — Marsyas.26, the twenty-seventh Marsyas stone laid through the same grammar

Launch milestone (in flight)

v.G.1.0 — Genesis. The launch milestone of the Ancient Holdings hub as StoaChain infrastructure support.

Forward roadmap

• v.G.2.0Athenaplanned
• v.G.3.0Icarusplanned
• v.G.4.0Hermesplanned
• v.G.5.0Zeusplanned
• v.G.6.0Mnemosynefuture
• v.G.7.0Atlasfuture
• v.G.8.0Hephaestusfuture
• v.G.9.0Phalanxfuture
• v.G.10.0Nikefuture
• v.G.11.0Aegisfuture
• v.G.12.0Agorafuture
• v.G.13.0Apotheosisfuture

The forward codenames are committed but most have no shipped code yet. Their slot in the coordinate space is reserved; the per-Release plan is what gets edited as each Era moves into design and flight. See the Roadmap pillar for the per-phase mission statements.

The canonical model is authoritative

One file is the single source of truth for everything on this page:

• lib/releases.ts owns the coordinate record, the A–Z deity Release roster, the major-tier classification set, the minor-Name draw pool, the per-Release forest, the strict-total-order comparator, and the retroactive-fix mint rule. Every grammar, retroactive-fix and uniqueness fact above is derived from it — no per-page literals.
• The codename roster and the live build stamp on the chrome are themselves pure derivations of that same model, so the three surfaces (releases, roadmap, this chapter) always agree.

Practical consequence: to add a Release or Era, edit the model. The release pages, the roadmap, and this chapter all update from that edit with no per-page rewrite required.

Legacy-track historical note

The pre-Genesis builds shipped on a legacy semver track. The model maps that entire pre-coordinate history onto Release A — the Foundation Release, whose roster mapping is “Foundation (all pre-Genesis v0.7.x)”. Concretely, every legacy v0.7.x build re-coordinatizes onto the Foundation Release’s nodes, so old operator notes and changelog references stay resolvable while every new release is stamped against the four-designator coordinate only.

The legacy strings are preserved on each Foundation node as its legacyMap — reader infrastructure for the changelog extractors, not an active versioning rule going forward.