# 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.