Orchid — From Dispatch Patterns to Silicon, Validated by Measurement

TLDR

This is the capstone of the Orchid research arc. Orchid (Orchestration Intelligence Device) asks a strange question seriously: if a PM framework's dispatch intelligence — which model, which skill, which batch, for which task — is a real optimization problem, what would it look like as silicon? The arc runs from a behavioral proof (Orchid v1, 25,305 runs) through an additive, ABI-stable hardware spec (Orchid v1.5), through a mapping of the framework's v7.x software defenses onto silicon units, and finally to the HADF measurement program, which supplies the empirical evidence those unit decisions need.

The final disposition: the central dispatch claim is CONFIRMED — at the sensing layer. All four HADF Phase 2-bis sub-experiments passed their pre-registered thresholds. The cloud-provider fingerprint strengthened under endpoint diversity (silhouette 0.5566 → 0.7003 @ k=5); cross-window anchors held stable (0.19σ drift, silhouette 0.98 @ k=2 in Sub-exp 1B); cloud and on-device substrates are separable (KS p ≪ 0.01); and the routing-layer falsification test — the one designed to refute a v2 design dimension — survived (signature_delta_ratio 2.89 > 2.0). One honest boundary travels with the result and is load-bearing throughout: sensing (signatures are detectable) is confirmed; acting (routing on them improves outcomes) is a separate, still-unproven claim, pre-registered as RQ4 / Phase 3B.

1 — Thesis: orchestration as a silicon problem

Most of this site is about a fitness app and the PM framework that builds it. Orchid is the framework looking in a mirror. Every dispatch decision the framework makes — route to Opus or Sonnet, hit cache or recompute, batch or run serial, trust a hardware hint or ignore it — is a scheduling-and-routing problem, the same kind of problem a CPU's front-end solves in hardware.

Orchid IS: a RISC-V research accelerator; a cloud-emulated, open, parameterizable design vehicle; a way to pressure-test the framework's own patterns by forcing them through the discipline of an instruction-set architecture.

Orchid IS NOT: a product, a chip we are taping out, or a claim that FitMe needs custom silicon. It is a research instrument whose value is the rigor it imposes on the framework's self-model.

2 — v1: the behavioral proof [T1]

Orchid v1 modeled seven functional units (U1 Dispatch Scorer, U2 Skill Router, U3 Cache Controller, U4 Batch Scheduler, U5 Speculative Prefetcher, U6 Coherence Unit, U7 Systolic Array) as Python behavioral models — Layer A in a Layer A → B (RTL) → C (SoC) progression. The point of Layer A is to find out whether the design space even has structure before paying for RTL.

It does. Across 25,305 benchmark runs [T1] there were 0 invariant violations [T1]. The design-space exploration surfaced real, actionable structure: prefetch_ahead was the dominant variance lever, and a cache below ~10 entries fell off a thrashing cliff. Mesh dimensions showed no effect on the synthetic traces — a null result worth knowing before sizing the systolic array. This is the empirical floor the rest of the arc builds on.

3 — v1.5: additive units, ABI-stable [T1/T2]

Orchid v1.5 chose Option B — land new capability additively without disturbing the v1 U1–U7 CSR allocation — over a v2.0 rewrite. Four primitives:

• U8 Patrol Scrubber — periodic self-audit that detects and raises rather than masks; the silicon analogue of the framework's 72h integrity cycle.
• U9 Validation Bus — a mandatory trap channel plus an advisory counter channel; the silicon analogue of pre-registered pass/fail (mandatory) vs. interpretive narrative (advisory).
• Tier propagation — T1/T2/T3 data tiers carried as 2-bit user[1:0] on TileLink, with user[7:2] reserved for v2.0 (a reserve-don't-spend ABI bet).
• U3 PMU exposure — read-only counters (cache hits/misses/evictions) so the dispatch layer can observe what the cache controller actually did.

Tracks L (Layer A behavioral models) and D (tier-aware DSE end-to-end) shipped (PRs #179, #180, #182, #183, #184). Honestly pending: Track R (Layer B Chisel RTL) is blocked on toolchain install, and Track D D3 (the 26K-run sweep) is deferred. That is by design — Option B's whole point was that the behavioral and mapping work does not block on RTL.

4 — Mapping v7.x software defenses to silicon [T2/T3]

The framework's data-integrity work (v7.1 → v7.9) is, abstractly, a set of self-checking disciplines. Each has a hardware analogue, and the v1.5 unit set is that mapping made concrete:

The bridge runs both ways: the software discipline tells the hardware what to check, and the hardware framing tells the software which of its checks are load-bearing enough to be worth a trap.

5 — HADF: the empirical validation

A design mapping is a hypothesis. HADF (Hardware-Aware Dispatch Framework) is the measurement program that tests it on real endpoints. The contract is explicit: "HADF generates the empirical evidence Orchid v2 needs for design decisions on units U1–U9."

What has landed [T1]: cloud endpoints cluster cleanly by latency fingerprint. HADF Phase 2 measured silhouette 0.5566 at k=5 over n=700; Phase 2-bis Sub-exp 1 measured 0.7003 at k=5 over n=2,600 across 4 endpoints and 2 providers — the signal strengthened by +25.8% as n grew 3.7× and provider count doubled, with the k=5 cluster structure preserved, at an actual cost of $0.324 (92.86% valid rate). The kill criteria did not fire.

What this validates in Orchid [T3 over T1 data]:

• U1 Dispatch Scorer — 13-bit input bus. Clean, well-separated k=5 clusters mean endpoints are distinguishable by separation, not by dynamic range — so the narrower, cheaper 13-bit bus is empirically defensible (no need to widen to 16 bits for cloud variance).
• U4/U5 scheduling — per-endpoint stability. Stable, separable per-endpoint TTFT/TPS profiles over ~700 dispatches each are the precondition U4's round-robin arbiter and U5's BTB-style predictor assume — strengthening the DSE-reduced 16-entry prediction table over the original 64.
• Tier ABI bet. HADF's own experiments are rigorously tier-tagged at n=2,600, demonstrating the 2-bit tier vocabulary survives real measurement at scale — field evidence for the reserve-don't-spend choice.

What the two closing sub-experiments resolved [T1]:

Sub-exp 2 — cloud vs. on-device — SEPARABLE. A local Ollama llama3.2:3b endpoint on an M2 and the cloud anchors occupy distinct fingerprint regions: two-sample KS rejects equality decisively on both marginals (TTFT p = 9.3e-136, TPS p = 5.9e-322, n=800, both ≪ 0.01). This licenses the device_modifier for the >0.7 band, and it picks the open v1.5 forks: U7 systolic-array sizing leans toward the 8×8 compute-bound profile (local inference is compute-bound, not bandwidth-bound), and the U3 cache model resolves to "local fits in RAM, cloud does not." The on-device branch is no longer activation-ahead-of-evidence.

Sub-exp 3 — routing-layer falsification — SURVIVED. This was the keystone: a pre-registered delta_ratio < 1.0 would have refuted the HADF dispatch premise on the routing axis and contraindicated two Orchid v2 units. It did not. Bedrock-haiku and Anthropic-direct-haiku — the same claude-haiku-4-5 model id, differing only in the serving substrate — fingerprint apart beyond the within-provider noise floor: signature_delta_ratio 2.89 (inter-endpoint Mahalanobis 1.043 / intra-anchor noise 0.361), median TTFT 1.468s (Bedrock) vs 0.868s (Anthropic-direct), n=2,239, anchor drift 0.19σ. The routing layer carries real signal → BUILD U2 routing-class field + U6 multi-routing-layer coherence. Pre-committing the refutation branch is what makes the survival meaningful rather than confirmatory.

The honesty boundary that survives confirmation. All of the above is the sensing claim — signatures are detectable, general, and stable. Whether a dispatcher that routes on these signatures produces better outcomes is the acting claim, and it is not tested here. It is pre-registered as RQ4 (Phase 3B), a separate experiment. Sub-exp 3's delta_ratio 2.89 confirms aggregate distribution-level separability, not per-request classification accuracy (RQ5) — which is why the Phase 3A sensing layer that consumes this evidence ships advisory / detection-only.

6 — Activation posture: what the data licenses

HADF v7.0 shipped inert (enabled: false) as a hardware_context input to the existing v5.2/v6.0 dispatch engine — Extension-not-Replacement. A three-band confidence gate governs effect: < 0.4 ignored (dispatch bit-for-bit identical to v5.2, zero regression); 0.4–0.7 advisory only; > 0.7 hardware scores multiply routing weights.

Licensed now by closed data: all three discrimination modifiers clear the

0.7 band on the sensing axis — cloud-provider (silhouette 0.7003 → 0.98), device-local (KS p ≪ 0.01), and routing-layer (delta_ratio 2.89). The zero-regression gate guarantees the flips carry no risk to the system-wide guardrails (crash-free >99.5%, dispatch bit-for-bit identical below threshold).

But the activation that matters is gated on a claim this program did not test. Flipping a confidence modifier into the >0.7 band changes how the dispatcher weights a routing decision — that is the acting layer. Phase 2-bis proved the signal is real to observe; it did not prove that acting on it improves any outcome (latency, cost, quality). So the licensed posture is: ship the Phase 3A sensing layer (detect, attest, monitor drift — observability only, no routing change), and hold the live routing flip until RQ4 / Phase 3B tests decision-value directly. The confirmation earns the sensing surface, not a behavior change.

7 — Honest close

The arc closes at CONFIRMED — at the sensing layer. All four HADF Phase 2-bis sub-experiments passed their pre-registered thresholds, including the one written to refute a v2 design dimension. That is a real result, and a rare shape for one: a fitness app's PM framework produced a falsifiable, pre-registered, externally-auditable hardware hypothesis, ran it on real endpoints for ≈$1.74, and the hypothesis survived a falsification test it could have failed. The unit decisions it licenses are concrete — U7 8×8 compute-bound, U3 local-fits-RAM cache model, build U2 routing-class + U6 multi-routing coherence.

The discipline that makes the "CONFIRMED" honest is the boundary it refuses to cross: sensing is proven; acting is not. The signatures are detectable, general, and stable — that is what the data shows. Whether routing on them improves dispatch is a separate, still-open question (RQ4), and per-request attestation accuracy is another (RQ5). A confirmation that names exactly what it has not shown is worth more than one that quietly widens its own scope.

The forward path: Phase 3A activates the sensing surface (shipped as advisory / detection-only producers); RQ4 / Phase 3B designs the decision-value experiment that would license a live routing change; External Audit #2 (2026-06-12) independently checks the raw verdicts; and the Orchid v2 spec stub — gated on the Chisel toolchain — turns the surviving unit decisions into RTL intent. Track R waits; the evidence does not.

Reference

• Research anchor (FT2 upstream): docs/research/2026-05-29-hadf-activation-orchid-validation-analysis.md
• Predecessors: HADF v7.0 · HADF Phase 2 · HADF Phase 2-bis synthesis
• Orchid v1.5 spec: docs/superpowers/specs/2026-05-03-orchid-v1-5-design.md
• Framework-v7 silicon mapping: docs/research/2026-04-28-orchid-framework-v7-mapping.md
• HADF↔Orchid integration contract: docs/research/2026-05-12-hadf-phase2bis-orchid-integration.md