Passnet Orchestrate

---
name: passnet-orchestrate
description: >
  Round/batch planning and decision support for PassNet graph optimization. Use for
  multi-sample triage, worker allocation, eval-budget policy, and post-eval keep/revert
  decisions. For solving one concrete sample end to end, use passnet-solve as the entry
  skill; consult this skill only when you need broader planning or a specific decision gate.
---

This skill is the **planning and decision** layer for PassNet. It is not the single-sample
entry point. For one concrete sample, start with **passnet-solve**; it owns the end-to-end
loop and calls passnet-pattern-fusion, passnet-triton-opt, and passnet-feedback at the right
time. Use this skill when planning a multi-sample round, choosing which sample families to
dispatch, auditing whether a line of attack is overhead-bound, or deciding whether to keep,
revert, or stop after completed evaluations.

For context, a **sample** = several **graph variants** of the same subgraph (different dtypes —
float32 / float16 / bfloat16 — and seeds/batch dirs). You write passes; the harness
pattern-matches them into each variant's graph, checks correctness vs eager, and measures
end-to-end speedup. Your deliverable is a final report (§8).

This skill is self-contained: every decision below is made from each variant's `model.py`
(the computation), `weight_meta.py` (shapes/dtypes), and the evaluation results. It does not
depend on any external helper script. It does, at two points, rely on *capturing the real
graph and running the real matcher/kernel* (to confirm a pattern matches and a kernel is
correct before spending a GPU eval) — that is a local, GPU-free check you can run yourself.
The `passnet-feedback` scripts package that check for convenience; use them if present, but
the flow never requires them and you must have a hand fallback when they can't capture a
graph.

---

## 1. The score is the strategy

Four metrics are reported; the **AS Score** (an ES-weighted geometric mean of per-variant
"rectified speedups") is the headline, and the other three (G-Mean Speedup, Correctness,
fast_1) move with it. Optimize the AS Score. Two facts about it drive every decision below:

**The rectification cliff.** Per variant, your outcome is worth roughly:

| outcome                                   | worth (rectified speedup) |
|-------------------------------------------|---------------------------|
| no pass matched, or a crash/runtime error | **~0.1**                  |
| matched but numerically wrong             | **~0.15**                 |
| matched + correct, end-to-end speedup `s` | **~s** (even when s < 1)  |

So a **matched, correct pass that runs at 0.8× scores ~8× better than not matching (0.1).**
Slow-but-correct is a *good* outcome; not-matching is a disaster.

**The geometric-mean trap.** The sample score is a geometric mean across **all** variants.
One variant at 0.1 drags the whole sample down hard — a single red variant outweighs a hero
result on another. **Consistency across every variant beats a peak on one.**

Consequences this skill enforces (internalize these — they explain every rule that follows):
1. **Never finish with an empty or non-matching `pass_dir`.** A floor pass is mandatory.
   Matching even a *free-in-eager* region for a sub-1.0 score is far better than 0.1 — when
   that's the only region you can bind to, take it (a constrained floor of ~0.5 still beats
   0.1 by ~5×).
2. **Never ship a change that turns a previously-green variant red.** Protect the gmean.
3. **Prefer ONE pattern that covers every variant** over per-variant passes — fewer ways to
   leave a variant unmatched, and one evaluation validates them all. The way to do this is to
   write patterns with NO shape/scalar literals that differ across variants.
4. **You do NOT have to cover every observable output.** A single matching pass already
   modifies the graph (no 0.1); any output your passes don't produce simply runs in eager and
   still scores. So target the **highest-value single region** rather than trying to absorb
   the whole graph. (Tiny diffs may appear on outputs your kernel never touched — e.g. eager
   dtype-cast nondeterminism — and they pass baseline tolerance; don't chase them.)

(The exact tolerance weights and scoring formula are mechanics — see passnet-skill / its
references. You don't need them to make decisions; you need the cliff and the trap.

When the harness reports an **authoritative aggregated score**, trust THAT over any estimate.
A variant is "correct" at the dtype's *baseline* tolerance — not the strict bit-exact column.
Read the end-to-end speedup, the success/failed status, and baseline-tolerance correctness;
do not be alarmed by a nonzero diff that is still within baseline tolerance.)

---

## 2. "Can I even win?" — the cost gate

The compiled path pays a **fixed per-call tax** (graph-guard + interpretation + wrapper +
launch overhead) that does not exist in eager. It is small on tiny graphs and grows with
graph size; each Triton kernel launch adds more on top. You don't need the exact numbers —
you need the rule they imply:

> **You only win when the eager work you absorb into your kernel(s) per launch exceeds the
> tax you add.** Replacing one cheap op on a small graph loses; absorbing many ops, or
> replacing genuinely heavy memory-bound work, wins.

Calibrate the real tax for *this machine and graph* from your first evaluation (compare the
compiled median against eager minus the work you removed) and reuse it when estimating later
regions. The detailed performance model lives in **passnet-triton-opt**; bring just enough
intuition here to triage floor-vs-ambitious in §3.

---

## 2.2 The one heavy-op exception — non-overlapping conv reduces to a patch matmul

The right question is never the op's *name*, it is its *regime*. A vendor kernel
(cuDNN/cuBLAS) is near-optimal only for (a) the shapes/parameters it has tuned kernels for and
(b) the *general* form of its op class. You can beat it only when the op's concrete parameters
put it OUTSIDE that efficient regime AND make it equal to a cheaper computation you can express
as a legal Triton kernel. Otherwise you are competing with a vendor library on its home turf and
will lose. Derive this from the parameters in front of you — do not memorize a per-op verdict.

The clearest checkable win, and the one to actively look for:

- **A convolution whose windows do not overlap** — `stride == kernel_size` along each spatial
  dim, `kernel_size > 1`, `padding == 0`. Each output reads a disjoint input patch (no input is
  reused), so the conv is *exactly* a dense matmul of flattened patches by the flattened weight
  (`patches @ W.reshape(Co,-1).T` plus bias). cuDNN does not specialize for this — it runs its
  general convolution path (implicit-GEMM / im2col / Winograd) built for the overlapping case,
  which for an odd kernel/channel shape can be far off a well-shaped GEMM. A `tl.dot`
  patch-gather kernel that also folds the flatten/transpose/tail into its epilogue can win by a
  wide margin. Confirm `stride == kernel_size` and `kernel_size > 1` from the parameters.

Why the *same* rewrite usually LOSES on the other conv/matmul shapes — i.e. why the reliable
default is "leave the op in aten and fuse its elementwise tail":

- **1×1 conv** already *is* a pointwise matmul (PyTorch lowers it to a cuBLAS GEMM); there is no
  general-conv overhead to remove, so a hand `tl.dot` competes head-to-head with cuBLAS.
- **overlapping conv** (`stride < kernel_size`, e.g. 3×3 s1): writing it as a matmul needs
  im2col, which materializes a ~kernel_volume× larger matrix — the exact memory blow-up
  cuDNN's implicit-GEMM/Winograd avoids. You pay more, not less.
- **depthwise / grouped conv**: memory-bound with specialized vendor kernels; a hand kernel
  rarely wins and grouped indexing is bug-prone.
- **large/general dense matmul**: cuBLAS's sweet spot.

None of this is an absolute rule — **the completed eval is always the arbiter.** The lines above
are strong *priors*, not prohibitions: if the concrete parameters give you a specific reason to
believe a case sits outside the vendor's efficient regime (e.g. a tiny/degenerate matmul, or a
memory-bound op you can fuse with a long tail into one kernel), you may try it — but only AFTER
banking the tail/floor pass, and you KEEP it only if a completed eval beats that floor. Do not
spend budget rewriting an op that is squarely in the vendor's sweet spot on a hunch, and do not
skip the non-overlapping case just because no rule forbids it.

Two matchability facts (independent of the above): `conv1d/2d/3d`, `matmul`, `F.linear` are
C-bound functions the pattern tracer binds to fine — "it's a big cuDNN op" never means the
pattern can't match.

Discipline (unchanged and mandatory): **always ship the tail/floor pass FIRST** (S3); only then
attempt a rewrite as an additional ambitious region; REVERT (S5/GATE e) if a completed eval does
not beat the banked floor. The rewrite is upside insurance layered on top of the floor, never a
replacement for it.

---

## 2.1 Round triage gate — choose likely-amortizable samples first

When planning a multi-sample round, do not dispatch workers randomly across small graphs.
Spend a cheap triage pass first and label each candidate sample:

- `likely_amortizable`: at least one legal single-output region absorbs substantial real
  compute per launch: a large-output broadcast/binary op, a sizeable reduction plus its
  arithmetic, a long elementwise/norm chain over enough elements, or a compute tail that can
  be fused without reimplementing a vendor-optimal heavy op.
  Judge this from candidate regions, not only whole-sample labels: a sample with global
  returned values or producer fanout can still be likely amortizable when a downstream
  consumer-side region leaves the shared producer outside the pattern and returns one legal
  output.
- `downside_cap_only`: only tiny regions, layout/view/reshape-only work, returned views,
  split/fanout layout tails, or cheap consumers behind boundaries that are not worth
  repairing. These can still justify a floor pass to avoid 0.1, but they should not consume
  scarce worker slots in a performance-strategy round unless you need calibration examples.
- `blocked_by_contract`: every promising compute region would require multiple externally
  observable outputs, hiding a shared producer with outside consumers, RNG/data-dependent
  work, or a call form that cannot be recovered by exact/manual-FX matching. These are
  pattern-fusion lessons, not performance targets.
- `unstable_eval_risk`: previous or local evidence suggests evaluator timing instability,
  timeout risk, or many variants with heavy compile cost. Track this separately from
  numeric, no-match, and unauthorized-operator failures; it may justify rerunning an
  unchanged confirmed state, not rewriting the kernel.

Dispatch priority for performance validation:
1. `likely_amortizable` long memory-bound elementwise or broadcast-affine-activation chains:
   layout/broadcast producers plus multiple affine, activation, residual, or normalization
   consumers that can be contained in one single-output region. Repeated round evidence shows
   these are the best first allocation for performance-strategy validation because they can
   save multiple memory passes per Triton launch.
2. Clean normalization-affine compute prefixes and concat-to-normalization-affine prefixes:
   allocate formal workers to them after verifier/probe success, but record mixed outcomes
   separately. The same static family can produce strong wins, near-eager correct states, or
   a reverted floor depending on size, branch structure, dtype boundaries, and whether the
   profitable prefix is truly the actual winning region.
3. Local-region candidates recovered by a backward slice from a promising output. Allow
   shared, returned, vendor-heavy, or otherwise risky producers to stay outside the pattern
   as inputs when the downstream region itself has one output and absorbs enough compute.
   Repeated evidence shows this avoids over-pruning while preserving the single-output
   contract.
4. Other `likely_amortizable` samples with all key anchors matchable.
5. `likely_amortizable` but one boundary uncertain, if a cheap pre-flight can settle it.
6. A small number of reduction-only or vendor-tail controls. Allocate these deliberately,
   not as filler: repeated results show they often end correct-but-slow unless a larger
   compute-containing region is both legal and numerically clean.
7. Defer `blocked_by_contract` unless the round is specifically about matcher behavior.

For batch planning, keep separate fields for `triage_family`, `worker_confirmed_family`,
and `actual_winning_region_family`. Do not credit a successful larger replacement to the
initial triage family when the completed evaluation shows the winning region was really a
different family, such as a compute-plus-normalization prefix, a layout materialization tail,
or a vendor-heavy replacement. Use family-level completed-evaluation counts to adjust the
next batch allocation: wins above eager, correct-but-slow, numeric-preflight blocks,
correctness regressions on larger regions, and larger-region attempts.

This gate is benchmark-general: the goal is to spend workers where absorbed eager work can
plausibly pay for wrapper/framework/launch tax, then use completed evaluations to confirm.

---

## 3. The decision flow

Follow this top to bottom. Gates are marked **(a)–(e)**; sub-skill hand-offs are marked
**→→ CALL**.

```
S0. SET UP  (mechanics — see passnet-skill)
    - Read graph_list + every variant's model.py and weight_meta.py.
    - In service mode, confirm service health and verify uploaded pass files with /files before any /evaluate call.
    - In Codex managed sandboxes, try bounded normal localhost curl first; if it fails, retry once and then use the approved escalated localhost path if available. Do not interpret sandboxed connection failures as service downtime.
    - Clear stale files from pass_dir (it is imported as a package; leftovers shadow yours).

S1. CHARACTERIZE  (no GPU; read the graphs, then verify matchability with the real matcher)
    - For each variant list: ops in their EXACT written call form, tensor shapes, dtypes.
    - Mark each node matchable / unmatchable for normal callable patterns (the rules are in
      passnet-pattern-fusion). RNG/data-dependent nodes are hard walls. Keyword-form Python
      functional calls are walls for callable patterns, but a high-value single-output region
      may be recoverable with an exact manual FX `GraphModule` pattern; require real matcher
      proof before treating it as legal. In-place / augmented-assign ops (a node written as
      `x op= c`, or a call flagged in-place) often normalize to a different form than your
      pattern produces; bind to neighbours unless passnet-pattern-fusion proves an exact
      pattern can match and the replacement preserves the eager mutation semantics across
      repeated calls.
    - Partition the graph into maximal matchable REGIONS, each with exactly ONE value
      consumed outside it. Eyeballing model.py tells you the candidate regions, but whether a
      given op actually matches is often NOT visible by eye — confirm it with the real matcher
      (capture the graph + run the subgraph matcher, see S3 pre-flight) before you commit the
      strategy to a region.
    - Mark region economics before authoring: compute-heavy and large-output regions are
      likely amortizable; layout/view/reshape-only regions, returned views, and split/fanout
      layout tails are downside caps unless they bridge compute or remove a real
      materialization.
    - Classify the sample against the archetype table (§4) — this names your line of attack.
    - Cross-variant literal check: do shape/scalar LITERALS differ across variants? If yes,
      a shared pattern must avoid those literals (or you need per-shape passes). Every
      variant must end with >=1 matching pass.

S2. CEILING TRIAGE          ===== GATE (a): FLOOR vs AMBITIOUS =====
    Estimate, per region, whether absorbed eager work clearly exceeds the tax (§2).
    - Total eager work tiny / no region absorbs more than the tax
            -> OVERHEAD-BOUND. Target = a safe FLOOR only. (Ceiling < 1; do not chase >1.)
    - The only legal matchable regions are layout/view/reshape/split-fanout floors
            -> DOWNSIDE CAP. Evaluate the safest correct state if needed, but do not tune it
               blindly; stop after a completed correct eval unless a larger compute-containing
               region becomes legal.
    - The dominant cost is a heavy conv/matmul in the vendor sweet spot (1×1, depthwise/grouped,
      overlapping conv, or a general dense matmul) with no worthwhile cheap tail
            -> DEFAULT to not reimplementing it: floor on an adjacent node; accept ~1.0.
      Precondition: you checked §2.2. The clearest upside case (below) is a non-overlapping conv
      (`stride == kernel_size`, `kernel_size > 1`, `padding == 0`); the others are strong-prior
      walls, not absolute — a completed eval may still justify a rewrite in a specific
      off-regime shape.
    - There is a fusible region whose absorbed work clearly beats the tax, OR a heavy op that
      §2.2 shows sits outside the vendor's regime and equals a cheaper computation
            -> REAL UPSIDE. Ambitious path enabled.

S3. SHIP THE FLOOR FIRST  (cap the downside before taking any risk)
    Pick the single most trivially-correct matchable region — one compute node you cannot get
    numerically wrong. This caps EVERY variant at "matched + correct."
    →→ CALL passnet-pattern-fusion  — author the floor pass (pattern + replacement + a single
       kernel; use the shared-dispatch layout from the start even for one pass).
    - PRE-FLIGHT (no GPU) — MANDATORY before every eval (this is the single biggest lever for
      not wasting evals). Check two things:
        (1) MATCH: re-read your pattern against each variant's model.py — exactly one output?
            exact call form (method vs function, positional vs kwargs, no in-place op inside)?
            literals equal across the variants it must cover? every inside-node consumed only
            inside? Confirm it would match EVERY variant.
        (2) NUMERICS: run your kernel once on inputs of the right shape/dtype and compare to
            the eager computation at the dtype's baseline tolerance. Index-arithmetic kernels
            (copies, permutes, strided gathers) are the #1 source of silent wrong answers —
            always numerically check them before an eval.
      The reliable way to do BOTH checks without a GPU eval is to reproduce the harness
      locally: capture each variant's real graph (compile the model with a graph-capturing
      backend, or trace it) and run the actual subgraph matcher with your pattern against it,
      then run your kernel on correctly-shaped/dtyped inputs and compare to eager. The
      passnet-feedback checker packages exactly this — use it if available. But it is only a
      convenience: it can itself fail to capture some graphs (e.g. ones using advanced integer-
      tensor indexing or other data-dependent ops). When it fails, fall back to capturing the
      graph yourself the same way and running the matcher/numeric compare directly — do NOT
      skip the pre-flight and "just try an eval." Reading model.py by eye is the weakest form
      of this check and misses non-obvious unmatchable forms; prefer the real matcher.
    - EVALUATE  (GPU eval #1).                ===== GATE (e) applies after every eval =====
        * service upload unconfirmed -> do NOT evaluate; fix upload/listing first.
        * empty/interrupted/non-JSON eval response -> no metrics exist; retry or fix service access/state before making strategy conclusions.
        * not matched / wrong -> fix MATCH or NUMERICS and re-eval; a floor that doesn't
          match is worse than useless.
        * matched + correct  -> snapshot this pass_dir as BEST-KNOWN-GOOD; calibrate the tax
          from this eval's numbers.
    - If GATE (a) said FLOOR-only -> go S7. Else -> S4.

S4. BUILD UPSIDE — one region at a time
    Choose the single highest-expected-gain region not yet addressed.
    →→ CALL passnet-pattern-fusion  — pick which ops to absorb into the region, author the
       pattern, and (for >=2 passes) wire the shared-dispatch architecture.
       GATE (b): any time you author or repair a pattern, or decide what to fuse, you are
       in passnet-pattern-fusion — not here, not passnet-triton-opt.
    - PRE-FLIGHT (no GPU), MANDATORY — same two checks as S3 (match every variant + numeric
      sanity at baseline tolerance). Fix any match/numeric problem BEFORE spending a GPU eval.
    - EVALUATE (GPU eval #k). Read per-variant status + speedups + the authoritative score.

S5. ===== GATE (e): REVERT or KEEP =====   (run after EVERY eval)
    - Authoritative score < BEST-KNOWN-GOOD, OR any variant that was green is now red
            -> REVERT to BEST-KNOWN-GOOD immediately. Do not stack a new change on a worse
               base. Diagnose from the log, then try a DIFFERENT single change or abandon the
               region.
    - Otherwise -> this becomes the new BEST-KNOWN-GOOD. Continue.

S6. ===== GATE (c): matched + correct but SLOW? =====
    - A region matches and is correct but its speedup is below the ceiling, OR correctness
      misses by a SMALL numeric margin (a dtype-tolerance miss, not a gross bug)
            →→ CALL passnet-triton-opt  — perf tuning and/or numeric-fidelity fix. Change ONE
               class at a time (perf XOR numeric). Re-eval -> back to S5.
    - A completed eval is matched and correct but slower than eager, and the region is already
      maximal or only layout/view/fanout work remains
            -> OVERHEAD-BOUND STOP. Keep the best completed state as the floor/downside cap;
               do not spend evaluations on block-size sweeps or tiny independent kernels.
    - A wider legal attempt completed but scored lower than the floor or narrow state
            -> REVERT and STOP that line unless a different likely-amortizable region remains.
    - A broad manual-FX attempt is matched and correct but unstable or slower after absorbing
      an in-place node
            -> REVERT to the best state and consider a narrower downstream region that leaves
               the side effect in eager.
    - Matched, correct, at/near ceiling -> this region is done.

    ===== GATE (d): STOP? =====  Stop when ANY of:
        * best score >= ~0.9 x your estimated ceiling, OR
        * GPU-eval budget exhausted AND a matched+correct pass is in place, OR
        * the last 2 evals produced no improvement, OR
        * no un-addressed region has expected gain greater than the tax.
    Otherwise pick the next region -> S4.
    CEILING SANITY: if a dominant conv is the reason your ceiling is ~1.0, first confirm (§2.2)
    it is NOT a non-overlapping conv (`stride == kernel_size`, `kernel_size > 1`, `padding == 0`)
    — that one case has a much higher ceiling via a patch-matmul rewrite. Do NOT "preserve
    budget" by stopping early when that specific reformulation remains unattempted and evals
    remain. (For 1×1 / depthwise / general matmul a ~1.0 ceiling IS correct — don't chase them.)

S7. FINAL REPORT (§8). Make sure BEST-KNOWN-GOOD is what is on disk.
```

Compact tree:

```
read sample -> characterize -> ceiling triage (a)
   overhead-bound / vendor-heavy  -> floor (b) -> eval -> report
   real upside                    -> floor (b) -> eval -> [loop: pick region (b) -> eval
                                                           -> revert-or-keep (e)
                                                           -> if slow/near-miss tune (c)
                                                           -> stop? (d)] -> report
```

---

## 4. Graph-shape archetypes → line of attack (operator-AGNOSTIC)

Classify by **dataflow structure, tensor-size regime, and matchability — never by which
operator it is**. (The right kernel is derived from the graph in front of you; this table
only tells you *where the upside lives* and *what to try first*.)

| structural shape | size regime | line of attack | rough ceiling |
|---|---|---|---|
| a chain of cheap elementwise/normalize ops feeding ONE output | any | fuse the maximal matchable region into one kernel | good if tensors large; ~1.0 if tiny |
| a reduction over a large axis, then arithmetic on the result | ms-scale tensors | one fused reduction kernel producing the final output | among the highest (often >1.5×) |
| a broadcast/expand feeding a binary op that WRITES a large output | large output | one shape-aware kernel; absorb the layout ops | strong even alone |
| a heavy conv/matmul + a cheap tail — 1×1 conv, depthwise/grouped conv, overlapping conv, general dense matmul | any | default: leave the heavy op in the graph; fuse only the tail. Rewriting the op is usually a loss (vendor sweet spot) — try only if parameters suggest off-regime AND a completed eval beats the floor | bounded by tail size |
| a non-overlapping conv (`stride == kernel_size`, `kernel_size > 1`, `padding == 0`) | any | reformulate as a `tl.dot` patch-gather kernel + fused tail; the conv is the region ANCHOR, not a wall. Ship a tail floor first | can be large |
| tiny total eager time (a couple of cheap ops) | small | overhead-bound: ship a floor, accept < 1 | < 1 |
| mostly layout ops (view/reshape/permute/transpose) + 1 compute op | any | replace the compute op only; absorb adjacent layout for free | modest |
| the only matchable region is a layout op whose result is RETURNED directly (a view eager never materializes) | any | replacing it FORCES a copy eager skips, so it scores < 1 — but it still matches; take it ONLY as a last-resort floor to escape 0.1 | < 1, but >> 0.1 |
| split/fanout layout region with multiple externally observable consumers | any | single-output floor or separate consumer-side passes only; do not hide the shared producer | < 1 unless each pass absorbs real compute |
| graph contains RNG / data-dependent / unrecovered call-form / in-place nodes | any | those nodes are walls by default; try exact manual FX only for valuable single-output call-form blockers, otherwise fuse around them | bounded by what's left |

Rules for using this table:
- **Matchability overrides structure.** A graph can look exactly like a high-upside row (a
  reduction-then-arithmetic chain, say) yet score < 1, because the op that would anchor the
  fusion is in a form a normal callable pattern cannot reproduce, or because an in-place,
  RNG, or data-dependent node severs the region. So BEFORE you commit to an ambitious row,
  confirm the anchor op actually matches. For kwargs-form Python functional blockers, first
  try the normal callable form; if it near-misses and the region is valuable, use
  passnet-pattern-fusion's manual FX pattern path and verify it with the real matcher.
  **Verify matchability with the real matcher** (the passnet-feedback checker, or a graph
  capture you do yourself per S1) before building on a region — not just before the eval.
- Pick the row that matches the **structure** AND whose anchor op is matchable, then hand the
  region to **passnet-pattern-fusion** to turn into a concrete pattern + kernel.
- Layout-only ops are ~free in eager: absorbing them pays only when it lets you bridge two
  compute ops into one kernel or erase a materialization — not as a goal in itself. The one
  exception is the last-resort floor above: when EVERY compute op is unmatchable, materializing
  a returned view is the only way to modify the graph, and a ~0.5 beats a 0.1.
- If two rows apply, prefer the one with the larger absorbed-work-per-launch.
- Your kernel can be faster than eager in isolation yet the sample still lands near 1.0,
  because an unmatchable neighbour you couldn't absorb stays in BOTH paths. The ceiling is set
  by absorbed work, not total work — estimate it from what you can actually bind to.

---

## 5. Dead ends (DON'T) and disciplines (DO)

**DON'T** (each line is a path that scores badly — avoid it):
- **Finish with an empty or non-matching `pass_dir`.** That's the 0.1 floor; a slow correct
  pass is ~8× better.
- **Return more than one value from a pattern.** Multi-output crashes the variant -> 0.1.
  If two intermediates are observable, that's two separate passes (passnet-pattern-fusion).
- **Add a second pass without the shared-dispatch architecture.** With >=2 passes the harness
  silently drops any pass whose replacement function differs -> variants stop matching.
- **Re-implement a vendor-optimal heavy op in a custom kernel that does the SAME work** — a
  general dense matmul, a 1×1 conv (already a pointwise GEMM), a depthwise/grouped conv, or an
  overlapping conv, when it sits in the vendor's efficient regime. You will lose to the library;
  fuse its cheap tail instead. (The clearest exception is not "the same work": a non-overlapping
  conv — `stride == kernel_size`, `kernel_size > 1`, `padding == 0` — is algebraically a dense
  patch matmul while cuDNN runs a heavier general path, so a `tl.dot` patch-gather rewrite is a
  real algorithm change worth pursuing; see §2.2. This red line is a strong prior — a completed
  eval can still justify a rewrite for a provably off-regime shape. Also: never conclude a heavy
  op is unmatchable — it is a C-bound function that binds fine.)
- **Chase >1.0 on an overhead-bound sample.** The tax caps the ceiling below 1 — take the
  floor and move on.
- **Tune a correct-but-slow tiny/layout-only/fanout floor by reflex.** First ask whether a
  larger legal compute-containing region exists; if not, stop with the floor.
- **Make multi-change rewrites between evals.** Regressions become un-diagnosable. One
  change-class per eval.
- **Build on top of a change that lowered the score.** Revert to BEST-KNOWN-GOOD first.
- **Put RNG / data-dependent / unrecovered call-form nodes inside a pattern.** They are
  region boundaries; including them without exact matcher proof means no match.
- **Evade the anti-cheat** (operator laundering, dispatch tricks, returning precomputed eager
  results). It's classified as hacking, scores 0 on the leaderboard, and is usually slower
  than eager anyway.
- **Spend a GPU eval to discover a match failure** you could have caught by running the real
  matcher against the captured graph, or a numeric bug you could have caught by running the
  kernel once on correctly-shaped inputs.
- **Mis-judge correctness from a strict bit-exact comparison.** A variant counts as correct
  at its dtype's *baseline* tolerance, which is loose for fp16/bf16. A small nonzero diff —
  especially on an output your kernel never produced — is usually fine. Read the authoritative
  speedup/score, not the strict-equal column.
- **Abandon a region as "infeasible" because your first kernel was wrong.** A wrong result is
  a numeric bug to fix (one change-class), not proof the strategy can't work.

**DO** (process discipline that the trajectories show pays off):
- **Ship a trivially-correct floor pass first**, then build upside on a known-good base.
- **One change-class per iteration** (match | numeric | perf) so every eval is attributable.
- **Track a BEST-KNOWN-GOOD snapshot** and revert to it on any regression. In service mode
  keep a local copy of every uploaded version.
- **Write patterns with no shape literals when variants differ only by shape** — one pass
  then covers all variants and one eval validates them.
- **Calibrate the per-call tax from your first eval** and reuse it in ceiling estimates.
- **Maximize ops absorbed per launch** rather than shaving an already-tiny kernel.
- **Recognize overhead-bound samples early and accept a sub-1.0 floor.**
- **Classify evaluator timing instability separately** from no-match, numeric,
  unauthorized-operator, timeout, and OOM failures. If the pass pre-flights cleanly and
  successful variants are correct, an unchanged rerun can be a valid use of budget.
- **Abandon a fundamentally-losing line of attack early** (don't sink evals into fighting a
  vendor kernel or a region whose absorbed work can't beat the tax) — but distinguish "wrong
  strategy" from "right strategy, buggy kernel": fix the bug before abandoning.
- **Read the authoritative result.** Use end-to-end speedup + success status + baseline-
  tolerance correctness as ground truth; treat any other estimate as a hint, not a verdict.

---

## 6. GPU-eval budget & iteration discipline

GPU evaluations cost minutes (many trials × many variants) and there is a hard per-eval
timeout. Treat them as the scarce resource and plan around them:

- **Budget ~6–8 GPU evals per sample.** If you're past that without progress, ship
  BEST-KNOWN-GOOD and stop.
- **Eval #1 is always the floor pass** — it buys downside insurance and calibrates the tax.
  Never spend eval #1 on an ambitious multi-pass attempt.
- **Pre-flight before every eval is mandatory** (both checks in S3: match-every-variant +
  numeric sanity at baseline tolerance — by hand or with the optional checker). A GPU eval
  that only learns "didn't match" or "kernel was wrong" is wasted; the budget assumes you
  never spend one that way. Done well, this drives wasted evals toward zero.
- **One change-class per eval** — so each eval answers exactly one question.
- **Many-variant samples (tens to 100+ graphs) risk timeout.** There, minimize compile cost:
  no autotune, a single fixed kernel config, the fewest passes, and a small fixed set of
  compile-time specializations. (The *how* is passnet-triton-opt; the *decision to do it* is
  yours, here, based on variant count.)
- **Snapshot every evaluated pass_dir state** so reverting is instant.

---

## 7. Generalization & anti-copy

The sample you are given will differ from anything you've seen. **Derive the optimization
from the dataflow in `model.py` and the shapes/dtypes in `weight_meta.py` in front of you** —
not from a remembered "for operator X do Y" recipe. If you catch yourself recalling a
per-operator formula, stop and re-derive it from the actual graph; the held-out set is built
to punish memorized answers. This skill deliberately gives you *decision structure* (where to
start, what to try, what to avoid), and leaves the operator-specific kernel math to be worked
out per problem in passnet-pattern-fusion / passnet-triton-opt.

---

## 8. Final report

End your work with:
- **Final AS Score** (from the last evaluation) and whether the pass matched.
- **Per-variant summary**: dtype → matched? correct? speedup.
- **Pass files** you created and a one-paragraph strategy description.
- If below the ceiling you estimated: the specific blocker (overhead-bound, vendor op,
  numeric limit, timeout, …).
- Do NOT write result files to disk; your reply text is the result.

---

## 9. Where things live (boundary map)

| skill | owns |
|---|---|
| **passnet-orchestrate** (this) | the decisions: where to start, what to try, dead ends, floor-vs-ambitious, revert/stop, eval budget |
| **passnet-pattern-fusion** | authoring patterns that match, choosing fusion regions, multi-pass shared-dispatch wiring, kernel templates |
| **passnet-triton-opt** | making a matched kernel fast (block/grid/warps/autotune/launch) and numerically faithful per dtype |
| **passnet-skill** | mechanics: fetching the problem, the pass-file format, how evaluation is invoked |
| **passnet-feedback** (optional) | scripts that give the same analysis/pre-flight/log-parsing faster — never required by this flow |

This skill is the **strategy** half and **passnet-skill** is the **mechanics** half; use them
together (this one to decide, that one for how to fetch/format/evaluate). If you only need to
know *how* to do a mechanical step, go straight to passnet-skill; for *what to do and in what
order*, stay here.