Skip to content

feat(evals): add blinded paired experiment - #38

Merged
vriesd merged 3 commits into
mainfrom
codex/eval-phase-7
Aug 25, 2026
Merged

feat(evals): add blinded paired experiment#38
vriesd merged 3 commits into
mainfrom
codex/eval-phase-7

Conversation

@vriesd

@vriesd vriesd commented Aug 25, 2026

Copy link
Copy Markdown
Contributor

Summary

  • replace marginal benchmark summaries with a frozen v2 complete-pair experiment
  • add nonce-backed per-block allocation, deterministic task-stratified bootstrap, power metadata, transcript leakage scanning, and controlled unblinding
  • persist exact masked analysis before allocation reveal and recompute masked semantics from the finalized report
  • add whole-pair reserve handling, budget stops, exact evaluator provenance, and request/failure honesty

Verification

  • bun run check: 496 pass, 1 skip, 0 fail
  • bounded packed-host pilot: 1 complete pair, 0 unresolved, both arms hidden-correctness pass
  • exact transcript scan binding: 2 scans for 2 transcripts, clean
  • observed cost: $0.2450722 under a $1 ceiling
  • four-model Interrogate: no unresolved blockers

Stop gate

The pilot is advisory and makes no product-value claim. Both arms tied, Flow tool presence is visibly unblinded, and 1 planned pair misses the conservative 265-pair power requirement. The decision is INCONCLUSIVE.

@vriesd
vriesd merged commit 9e31dfe into main Aug 25, 2026
6 checks passed

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4d140f1d03

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread evals/benchmark-run.ts
maxUsd: options.maxUsd,
unknownCostPolicy: "stop",
maxOutputTokens: 200_000,
maxWallClockMs: 3_600_000,

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Raise the wall-clock budget for powered runs

For any successful run large enough to clear the fixed power gate, the runner needs at least 265 complete pairs (530 sequential arm attempts), while each successful runPrompt/runCommand waits through the harness's default 25-second quiet period. That alone requires over 3.6 hours, so this hard-coded one-hour ceiling necessarily stops the campaign before it becomes claim-eligible. Derive the wall-clock allowance from the planned pair count or make it configurable.

Useful? React with 👍 / 👎.

Comment thread evals/experiment.ts
Comment on lines +759 to +762
const scansValid = input.scans.every(
(scan) =>
TranscriptScanSchema.safeParse(scan).success &&
scan.sha256 === scanSha256(scan),

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Reject self-declared clean scan records

When scan records are reconstructed from persisted or external JSON, this validation accepts any well-shaped record whose hash merely authenticates its own fields; it does not require the current scanner version or enforce that passed agrees with findings. A caller can therefore supply a matching transcript digest with passed: true and even nonempty findings, causing a contaminated transcript to remain claim-eligible. Validate the scanner version and pass/finding invariant, or rescan the persisted transcript bytes at this boundary.

Useful? React with 👍 / 👎.

Comment thread evals/report-store.ts
Comment on lines +367 to +372
if (
record.reportId !== report.reportId ||
record.planSha256 !== report.plan.planSha256 ||
record.reportSha256 !== pairedReportSha256(report) ||
record.allocationCommitmentSha256 !== report.allocationCommitmentSha256 ||
record.allocationCommitmentSha256 !== allocationCommitmentSha256(secret)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Validate allocation mappings before persisting them

When an exported ReportStore.writeAllocation() caller supplies an allocation directly instead of obtaining it from revealPairedAnalysis, these checks prove only that the secret matches the previously committed hash. They do not verify that its blocks and tokens match the plan or that each attempt's ordinary/plugin artifact matches the revealed arm, even though validateRevealBindings performs those checks elsewhere. This permits the durable store to publish an allocation that contradicts the finalized report, so the store should invoke the same reveal-binding validation before writing.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants