Drop7 Research
approaches/baselines-diagnostics/throughput-probe/README.mdxMDX108 lines · 5.3 KB
---
title: Cover-throughput probe
family: baselines-diagnostics
summary: Asks whether telling a simple player to care much more about breaking open gray discs makes it live longer, and finds that turning that dial up barely moves anything.
status: rejected
evidence: task-record only
reads: public
---

A test of one tempting instinct: gray discs are what eventually kill you, so
tell the player to attack them much harder and it should survive longer. Turned
up over four increasing settings, it barely changed the outcome.

<EvidenceLabel status="rejected" evidence="task-record only" reads="public" />

## The intuition

Every five drops a new row of gray discs is pushed in underneath. A gray disc
carries a hidden number, contributes nothing until it is opened, and takes up a
cell in the meantime. A player that never opens them fills the board and dies;
a player that opens them keeps the board turning over.

So: take a hand-written evaluator and multiply the terms that reward attacking
covers — points for cracking, points for revealing, points for reducing the
cover count, penalties for covers that are high up or hard to reach, rewards for
having a trigger ready when the next rise arrives. Then play complete games at
four increasing intensities and see whether the score curve rises with the dial.

The instinct is not silly. It is the same intuition the flow arithmetic
supports: the board demands roughly 1.4 reveals per move to stay level. The
question this probe asks is narrower and worth separating out — *does weighting
the immediate, local cover reward more heavily produce that flow?*

## How it works

1. Start from the hand-written weight vector that the evolutionary experiments
   use as their reference point.
2. Build four variants by scaling about a dozen cover-related weights with a
   single intensity parameter at 0.25, 0.50, 0.75 and 1.00. Nothing else about
   the player changes.
3. Play the same 256 complete games with each of the five profiles, from a
   fixed, previously used exploratory seed range, with a 1,000-move cap and
   seven imagined chance outcomes per decision.
4. Report mean, median, 10th and 90th percentile, minimum and maximum score,
   mean moves, and the censored count for each profile.

Everything read is public. The output is explicitly stamped
`"selectionEligible": false`: the file states in its own header that it is not
a validation benchmark, and it names the seed range it reuses.

## What happened

The dial did almost nothing. In the recorded reading, the best of the five
profiles was **nearly flat** against the others, so larger local cover weights
were not promoted into any policy.

The conclusion is narrow. This rejects *one* mechanism: scaling up
immediate, one-move cover rewards inside a shallow hand-written evaluator — and
it does not reject the underlying idea that reveal flow governs survival. A
policy can want more reveals per move and still be unable to get them by paying
more for each individual crack, because the crack has to be *available*, and
making it available is a structural problem several moves earlier. That is the
same conclusion the
[constructive and reservoir family](/approaches/constructive-reservoir) reaches
from the other direction.

<TechnicalDetails title="The technical record">

**Status: rejected; task-record only.** The
[experiment index](/docs/research/experiment-index) records: "the strongest
profile was nearly flat, so larger local cover weights were not promoted." No
per-profile numbers, protocol, artifact hash or per-game data survive, and
[audit 04](/docs/exploratory/audit-04-blind-spots) §B.3 lists this source among
the 30 whose rejection "cannot be re-derived". Treat the verdict as provisional
in exactly the way the index instructs; this page quotes no scores because none
are retained.

Configuration, read from the source: 256 games, 1,000-move cap, 7 chance
probes, seed start `0x3d700000` (also catalogued in
[audit 03](/docs/exploratory/audit-03-claim-arithmetic)); profiles `hand`,
`cover-0.25`, `cover-0.50`, `cover-0.75`, `cover-1.00`. The weights scaled are
immediate clears, immediate reveals, immediate crack progress, occupancy
reduction, cover reduction, cover load, cracked load, cover and cracked
altitude, cover exposure, accessible cracked, stored high numbers, direct and
release readiness, next-drop and rise triggers, projected occupancy debt and
phase height risk. It embeds
`approaches/heuristic-search/evolution/evolution.cpp` for the policy and game
loop, and prints the engine's level-bonus constant into its own output so the
scoring mode of a run is self-documenting.

Because it reruns a previously evaluated exploratory range, a fresh run of it
is a re-reading of spent data, not new evidence.

Source: `throughput-probe.cpp`.

</TechnicalDetails>

## What this taught us, and what is still open

- Paying more for each individual crack or reveal does not buy more of them.
  Availability, not price, is the binding constraint.
- The rejection is one configuration on one shallow evaluator, recorded only as
  a task record. It says nothing about cover-focused terms inside a deeper
  search.
- The same family's [trajectory throughput](/approaches/baselines-diagnostics/trajectory-throughput)
  study attacks the same question from the measurement side, by asking what
  clear and reveal rates a much stronger, and privileged — player actually
  sustains.