Skip to content

Per-channel run measurability harness: every vote channel reports what it produced, per run (priority 1 — gates the monolith) #628

Description

@WilfordGrimley

What

Every vote channel must report what it produced, per run. Today, no such report exists.

This is the owner's stated priority-1 deliverable, and it is the gate on standing up the monolith.

Why it is first, and why it must be finished before the monolith runs

The sequence, per owner directive 2026-07-29:

  1. MEASURABILITY FIRST — every channel reports what it produced, per run.
  2. STAND UP THE MONOLITH, see what falls out.
  3. FIX WHAT FALLS OUT. Not before.

The reason for that ordering, stated directly: building the instrument and changing what it measures at the same time makes the first reading worthless.

The interpretive rule that depends on it:

A zero-row channel is evidence we never ran it, not evidence it is unnecessary.

Without a per-run per-channel report, a channel with zero rows after the monolith run is indistinguishable between "invoked and produced nothing" and "never invoked". That ambiguity is not hypothetical — it already produced a wrong conclusion: local-name-frequency-v1's zero invocations were presented as an argument to retire it, when they are an argument to keep it. It was never asked. (Contrast PrintingTagVote, retired in PR #615 for a positive reason: 0 rows, no resolver, no reader, no consumer ever written.)

Nothing is culled without a positive reason, and this harness is what makes a positive reason obtainable.

Scope

For all 21 vote channels, per run:

  • invoked? — was the channel reached at all, and by which runner (pooled run_image_evidence_cohort / local_calculate_verdicts / stage_e_dispatch / run_pilot);
  • eligible input count — the population it was offered;
  • abstentions, with reason;
  • votes cast, by outcome;
  • skips, by skip reason;
  • errors.

Keyed by run_id. Note PR #603 landed run_id on the last unstamped machine writer (evidence-transfer), so every machine write is now stampable.

The report must make the Stage D invocation route explicit — the audit established this is currently NOT ESTABLISHED for the planned run, and it is a blocker in its own right (see the pooled-runner reachability issue).

Status — RE-DISPATCH NEEDED

This work was dispatched and its agent was still running at handoff; it may have died in the same ~20:05Z API outage that killed four other agents. Verify before re-dispatching: check for a live agent and for any worktree under /home/ubuntu/ProxyPrints.github.io/.claude/worktrees/. Inspect with git -C <worktree> diff before deleting anything — the four confirmed-dead agents left uncommitted, unpushed work that may be worth salvaging.

Standing constraint: every agent writing to the catalog repo uses its own git worktree (OPS-CORR-0007), and never two agents on one branch (this happened on 2026-07-29 and left a revert-shaped staged index in an unwatched worktree).

What would close it

  1. A per-run, per-channel report covering all 21 channels with the fields above, emitted by the run itself (not a separate after-the-fact query).
  2. A test that a channel which is never invoked is reported as not invoked, distinctly from a channel invoked with zero output — this distinction is the entire point.
  3. The report checked in as an artifact of the first monolith run.
  4. Reconciles with Make the calculator roster a checkable contract: declare which tables each calculator writes, then verify it produces rows #577's calculator-roster-as-contract work rather than duplicating it.

Refs

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions