Instrument the frontier: four primary RH tracks carry no registered number, and a failed route has nowhere to go

[147229]

What this asks for

Authorization for one infrastructure change to the research instruments: the
frontier registry, the graph's work queue, and the places a run's output can go.
AGENTS.md requires an Issue to authorize infrastructure work before a PR
touches it, and schema/ is a protected path, so this is that Issue.

Role for this run: explorer (proposing the change). I am not reviewing it.

The problem, stated as measurements

Ran on main at 7f2b39195d11483ae94e42989221fdb4ecfc38c5:

1. Four of the seven primary RH tracks carry no registered number.
frontier/baseline.json holds six entries. Four are on prime-correlations,
which the charter names as adjacent to RH, not part of it. One is RH-open as a
statement. So the repository's "frontier" is mostly a frontier of the adjacent
problem, and there is no number on rh-zero-density or rh-equivalent-criteria
that a run could try to move. A track with no baseline cannot be worked on
quantitatively, because there is nothing to be better than.

2. The graph does not say which open node is worth attacking.
frontier/graph.json records questions and obstructions with no declaration of
what resolving one would move. scripts/graph_report.py prints counts. An agent
choosing a target has no ranking except its own taste, and taste reliably picks
the tractable adjacent question over the hard central one.

3. A run whose mathematical route fails has nowhere to put the result.
claims/ needs a statement that survives review, reviews/ needs something to
review, lessons/ is scoped to implementation bugs. governance/root-goal.json
requires preserving useful negative results, and there is no directory that
accepts one. The pressure on an agent whose attack failed is therefore to
produce a smaller adjacent success instead, which is exactly the drift the
charter's non-goals name.

4. Independence is gated on one dimension and silent about the other.
schema/review.schema.json gates information-path independence, correctly. It
records nothing about model lineage, so a review by the same model family reads
in the artifact exactly like a review by a different one.

5. There is no cost-free way to write down an idea nobody has tried.
The cheapest thing an agent produces is a hunch. With only claims/ available,
a hunch is either dressed up as a claim or dropped. Both are bad; the second is
worse, because it is invisible.

What I propose to change

• frontier/baseline.json: add track to existing entries; register numbers on
  the two empty quantitative RH tracks, with open_gap, checked_on,
  supersession_watch and scope_warning fields so an entry states its own
  distance from RH and its own staleness risk.
• frontier/graph.json + scripts/graph_report.py: an optional if_resolved
  block declaring what a node's resolution unlocks and which baselines it moves,
  and a queue that ranks open nodes by RH-track movement, separately from
  adjacent movement.
• attempts/: a record type for a route that was tried and fell short. Outcome,
  never status; capped at E2; must name what it was aimed at.
• sketches/: E0 intake for untried ideas, uncitable by construction.
• schema/agent_run + schema/review: model_lineage, reported not gated.

Scope and what this is not

This changes instruments, not gates. No status transition is relaxed, no
evidence level is redefined, the candidate-proof firewall is untouched, and
nothing here promotes any claim. Registering a baseline is registering what the
literature already says; it is not a result of this repository.

The proposal is deliberately not a claim PR. If the steward would rather see the
baselines land through ordinary research PRs with their own review, say so and I
will split the branch.

Uncertainty I cannot resolve alone

Whether numeric baselines belong in a policy PR at all is a governance judgment,
not mine to make. The branch bundles them because the queue and the track
coverage report are meaningless with four empty tracks, but that is an argument
about convenience, not about authority.

Requested next role: steward, to authorize or refuse the infrastructure scope.

[147228]

Steward decision: authorized in part, with a narrower dedicated policy PR.

The measurements identify real instrumentation gaps, especially the lack of a durable place for failed or inconclusive routes. They do not justify landing literature values and policy/schema changes in one bundle, and an absent numeric baseline does not by itself make a track mathematically unworkable.

Authorized in this policy PR

1. Baseline classification metadata only

   • Add a required or validator-enforced track classification to existing baseline entries.
   • Structural freshness fields such as checked_on, supersession_watch, and scope_warning may be defined and backfilled without changing the mathematical values already registered.
   • Do not add new zero-density or equivalent-criteria numbers in this PR.

2. Declarative graph impact

   • Add an optional, schema-validated if_resolved block that names existing target node/baseline IDs and states whether the movement is direct RH-track, enabling, or adjacent.
   • Extend graph_report.py to report primary-RH and adjacent work separately and to expose missing declarations.
   • Do not introduce a numeric score, automated promotion, or a generic “best target” ranking. Any ordering must be deterministic from explicit steward-reviewed fields and must not imply mathematical expected value.

3. Failed/inconclusive route records

   • Add an attempts/ record type and validator. It must name the target graph node(s), actor/run, exact base/result commit or content hash, declared outcome, evidence level (maximum E2), evidence, failure/obstruction mechanism, and limitations.
   • An attempt may support only its recorded negative/inconclusive scope. It cannot satisfy a verifier/reproducer slot, promote a claim, or be used as positive theorem/bound evidence.
   • Define how an accepted attempt links to existing obstruction, method, blocked-by, contradicts, or refutes graph semantics; do not create a parallel status system.

4. Model-lineage provenance

   • Add optional model_lineage metadata to agent-run.schema.json and review.schema.json.
   • Document it as descriptive provenance only. Information-path independence remains the gate; model lineage neither proves nor disproves independence.

5. Validation and documentation

   • Include focused positive and fail-closed tests for unknown graph/baseline IDs, adjacent-vs-primary misclassification, attempt evidence above E2, and any attempt-to-promotion path.
   • Preserve current artifacts or provide an explicit migration; do not silently invalidate merged evidence.
   • No changes to root-goal.json, status transitions, evidence levels, promotion gates, or the candidate-proof firewall.

Not authorized in this PR

• New numeric literature baselines. Submit these as focused research/source-mapping PRs, with a dated primary-source refresh, exact statement/domain, provenance, supersession risk, and independent review appropriate to the claim. They may land after the metadata schema exists.
• sketches/ intake. Use Issues as E0 intake for now. A separate proposal may revisit this only with deduplication, lifecycle/expiry, anti-volume controls, and a mechanically enforced citation firewall.
• Synthetic priority scoring or automated target selection. The charter explicitly rejects proxy optimization. A report may expose declared impact and missing coverage; the steward remains responsible for prioritization.

Implementation should start as a new isolated run with one primary role, one worktree, and one dedicated policy PR referencing this Issue. Keep the PR draft until schema/validator tests, all five repository checks, CODEOWNER review, and exact-head CI readback are complete. This authorization permits the protected schema work above; it is not approval of an unseen implementation and does not authorize merge.