# Horizon technical notes — publication edition v1

Authored 2026-09-13 for `technical-preview-residency39-v1`.
This is an explanatory source map, not a new evidence bundle or run result.
Repository-relative paths below identify the inspected sources; they do not
imply that those files or their complete repository are publicly downloadable.

## Product and backend boundary

Horizon Runtime investigates execution of mixture-of-experts models under memory
constraints, including expert placement and selective compression. Storage,
residency, execution precision, measured speed and output quality are separate
questions. An expert can be resident in GPU memory without being selected by
routing for the current token.

Source anchors in the Horizon Runtime repository:

- `PRODUCT.md`: product intent and claim boundaries.
- `docs/decisions/0002-expert-backend-port.md`: expert backend boundary.
- `docs/architecture/runtime-backends.md`: profile-specific precision and
  execution contracts.
- `docs/architecture/operational-flows.md`, section 4: expert misses,
  materialization, execution-slot use and eviction in their declared profile.

These contracts do not establish general model compatibility or output quality.

## Immutable cache — the scope of ADR 0009

Source: `docs/decisions/0009-resident-qpacked-immutable-expert-cache.md`, accepted
2026-08-27. Its implementation authority is the default-off P0 Qwen vertical
slice of `resident-qpacked-cache-v1`. OLMoE support, later optimizations, release
and public claims are separately gated. Do not infer that all executors in the
September campaign implement this ADR merely because both appear on this site.

The documented lifecycle is:

1. Preparation publishes a complete immutable, process-owned qpacked host
   backing with validated identity, inventory and layout.
2. A miss reserves bounded pinned staging and unpublished GPU spare rows.
   Transport is backing → staging → spare. Staging cannot be reused before
   its transfer completion event retires.
3. Readers continue to see a complete cache generation while a new group is
   being prepared. Version 1 serializes admitted miss transactions.
4. After routed-group transfer completion, one atomic snapshot transition
   publishes the new complete cache generation. Active leases, reservations
   and incomplete consumer events constrain eviction.
5. An evicted device row becomes reusable spare storage only after publication
   and retirement of all consumers of its previous generation. Eviction
   discards a cached copy, without expert D2H writeback or host-backing rewrite.
6. Capacity is fixed before request admission. Startup rejects insufficient
   staging or spare capacity. Failure before publication leaves the previous
   snapshot authoritative; ambiguous post-publication failure faults the cache.

ADR source 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 are design/contract
statements within that profile, not new performance observations.

## Precision is profile-specific

For `resident-qpacked-cache-v1`, ADR 0009 specifies qpacked host and GPU weights
and a declared W4A16 path. This does not imply dequantized FP16/BF16 expert slots.
The earlier `offload-qpacked` contract instead dequantizes low-bit source into
bounded FP16/BF16 execution slots. ADR 0008's mutable tiers have still another
lifecycle and must not be relabeled as the discard-only cache.

Original checkpoint values, source bit width, scale dtype, execution slots,
activation dtype and accumulation dtype retain their separate meanings.
Reconstructing values into FP16/BF16 does not recover the original checkpoint
values or demonstrate equal output quality.

## Recorded campaign and executor boundaries

Selected source: `artifacts/residency-executors-39-20260911-01/consolidation-01`.
The closed `contract.json`, `summary.json` and `report.md` identify the recorded
matrix. The public `residency-report.md` in this edition is an unchanged copy of
that report; the campaign dataset and thirteen JSON files are curated aggregates.

- OLMoE 0924 and OLMoE 0125 use PRODUCT-core scalar at c30, c40, c50 and c60.
  Their c64 configuration uses Grouped T3.
- Qwen uses top4-fused-v1 at c20, c30 and c39.
- Capacity counts are resident experts per layer. The total is 64 for the
  OLMoE models and 60 for Qwen, not a model-wide expert count.

The UI separates c64 because executor and residency change together. Its
difference cannot identify a residency-only causal effect. The three recorded
block rates and their relative range are descriptive, not confidence intervals.
The campaign remains E3 exploratory with no quality evaluation or market ranking.

For sample counts, metric formulas, download verification and its limits, read
`audit-method-v1.md` in the same edition. The full raw bundle and public source
repository access were not confirmed for this publication; this note does not
substitute for them or claim independent reproduction of the experiment.