Original publication document, rendered from the unchanged release Markdown. Its historical statements retain their original experiment scope; later quality experiments are documented separately in Quality Evaluation.

Horizon technical notes — publication edition v3

Authored 2026-09-15 for technical-preview-residency39-v3. This explanatory source map introduces no measurement. Source paths below identify repository anchors; the runtime source is private by author decision and these references do not imply public availability of a particular file or revision.

Publication policy

Authority: docs/superpowers/specs/2026-09-15-contract-valid-publication-policy-design.md in the Horizon repository, the owner-approved policy dated 2026-09-15. Validation (valid) records contract satisfaction. Evidence level (E3) records controlled research and its permitted claims. Publication (public) records admission under the exact contract. Reproduction (not_attempted) records independent reproduction provenance. These are independent dimensions. Valid, verified E2/E3 results are publicly admissible within their exact scope; E4 denotes paper-grade maturity. not_attempted is provenance, not invalidation. reproduced requires its own evidence and E4; neither public display nor E4 automatically establishes independent reproduction.

Product and backend boundaries

Horizon RunMap investigates MoE execution under constrained GPU memory through expert placement and selective compression. Storage, residency, execution precision, measured speed, and output quality are separate questions. A resident expert may be absent from routing for the current token.

Source anchors: PRODUCT.md; docs/decisions/0002-expert-backend-port.md; docs/architecture/runtime-backends.md; and docs/architecture/operational-flows.md, section 4. They define product intent, expert backend boundaries, profile precision, misses, materialization, and slot eviction; they do not establish general model compatibility or output quality.

Immutable cache and ADR 0009

docs/decisions/0009-resident-qpacked-immutable-expert-cache.md, accepted 2026-08-27, authorizes the default-off P0 Qwen vertical slice of resident-qpacked-cache-v1. OLMoE support, later optimizations, release and public claims have separate gates. Sharing a page with the September campaign does not establish that every campaign executor implements this ADR.

1. Preparation validates and publishes complete immutable, process-owned qpacked host backing, including identity, inventory and layout.
2. Miss transport follows backing → bounded pinned staging → unpublished GPU spare rows. Staging waits for its transfer completion event before reuse.
3. Readers keep a complete cache generation while a group is prepared. Version 1 serializes admitted miss transactions.
4. After transfer completion, an atomic snapshot publishes a complete new generation. Active leases, reservations and incomplete consumers constrain eviction.
5. An evicted GPU row becomes reusable spare storage after publication and retirement of its prior consumers. Eviction discards a copy; it performs no expert D2H writeback or host-backing rewrite.
6. Capacity is fixed before admission. Insufficient staging/spares fail startup. Before publication, failure preserves the prior snapshot; ambiguous failure after publication faults the cache.

ADR anchors: “Immutable process-owned host authority”, “Discard-only qpacked GPU cache”, “H2D-only miss transport”, “Snapshot publication and concurrency”, and “P0 support and claim boundary”. These describe that profile's contract.

For this profile, host/GPU expert weights stay qpacked on the declared W4A16 path. The earlier offload-qpacked instead dequantizes low-bit source into bounded FP16/BF16 slots. ADR 0008 mutable tiers have a different lifecycle and must not be relabeled as the discard-only cache. Original checkpoint values, source bit width, scale dtype, execution slots, activation and accumulation dtypes remain distinct. FP16/BF16 reconstruction does not recover original values or demonstrate equal output quality.

Recorded campaign and measurement contract

artifacts/residency-executors-39-20260911-01/consolidation-01 supplies the closed contract, summary and report. residency-report.md is copied unchanged; thirteen JSON extracts and the campaign dataset are curated aggregates. OLMoE 0924/0125 c30, c40, c50 and c60 use PRODUCT-core scalar; c64 uses Grouped T3. Qwen c20, c30 and c39 use top4-fused-v1. Capacity means resident experts per layer, out of 64 for OLMoE or 60 for Qwen, not a model-wide count. The c60-to-c64 change cannot isolate a residency-only causal effect. Cross-model speed ranking and output-quality conclusions are outside this measurement contract.

Each configuration has twelve prompt IDs over three blocks: 36 measured 128-token responses, with warmups excluded. Across thirteen configurations there are 468 responses, 39 workers and 39 excluded 64-token warmups. Repeated prompt IDs are not independent prompts. Pooled decode is sum(N−1)/sum(internal decode seconds), numerator 4,572; overall output rate is sum(N)/sum(internal response runtime), numerator 4,608, including first-token wait. TTFT and 128-token response time are arithmetic request means. Neither block rates nor per-response rates are averaged to produce pooled decode. Three block rates each pool twelve requests; range is 100 × (max−min) / pooled configuration rate, descriptive rather than a confidence interval.

VRAM is the whole-worker device-wide driver peak including preparation, warmup and shared desktop use, not process-exclusive or decode-only. RSS is a separate whole-worker process peak. H2D is a sum over 36 measured requests excluding warmup, not a transfer rate or per-response quantity. Controller residual time is a subtraction, not directly instrumented overhead. Internal timing is not uniform HTTP/SSE latency: OLMoE HTTP is UNSUPPORTED; isolated prefill is UNKNOWN. INT4 storage uses 256-value blocks and FP16 scales; execution values are distinct from original checkpoint values. Quality remains unevaluated.

The v3 guide served as audit-method-v1.md explains compatibility filenames, offline verification, and the mutable index. The standalone checker establishes hash and aggregate-copy consistency, not raw recomputation, publisher authenticity or experiment reproduction. The full raw bundle is not included; independent reproduction has not been attempted.

Version 3 directory and publication preflight

This edition preserves the v1 and v2 releases unchanged and introduces no new measurement or policy state. The v3 verifier enumerates the physical release directory and requires exactly the nineteen manifest files plus manifest.json, all regular files. Extra files, subdirectories, missing entries, symlinks and other file types are rejected.

Before any release write, the v3 builder checks both the complete existing destination inventory (when present) and the pending index candidate publication-index.json.v3-next. A conflicting candidate or an incomplete, extra or wrong-type destination fails without creating or completing a release. Byte-identical complete releases remain idempotent.

The sole mutable discovery index advances from the exact admitted v2 baseline to v3. It retains explicit historical manifest references to both v1 and v2, as well as the eighteen existing flat URL records and classifications.