Hugging Face's logo

Join the conversation

Join the community of Machine Learners and AI enthusiasts.

Sign Up
Back to feed
kanaria007 
posted an update 8 days ago
Post
110
✅ Article highlight: Benchmark Publication Without Governance Inflation (art-60-274, v0.1)

TL;DR:
This article argues that a benchmark result is not a governance maturity claim.

A score may be real, reproducible, and worth publishing—and still say nothing by itself about safety, deployability, assurance, institutional quality, or platform maturity. 274 treats benchmark publication as a discipline of comparability, disclosure, lifecycle limits, and anti-inflation.

Read:
kanaria007/agi-structural-intelligence-protocols

Why it matters:
• prevents measured results from being inflated into safety or maturity claims
• separates historical results from current comparability
• makes scope, freshness, omissions, and unsupported readings visible
• allows honest publication without requiring full platform assurance
• treats narrower wording as trust discipline, not underselling

What’s inside:
• the publication triad: comparability, disclosure, and anti-inflation
• bounded publication outcomes such as PUBLISHABLE, PUBLISHABLE_WITH_LIMITS, NOT_COMPARABLE, and NOT_PUBLISHABLE
• benchmark publication profiles
• comparability disclosure notes
• public non-claims registers
• inflation checklists for result-to-maturity, comparison-to-assurance, historical-to-current, and wording inflation

Key idea:
Do not say:

“this system scored well, therefore it is mature, safe, or ready to deploy.”

Say:

“this result was observed under this benchmark and comparability frame, remains valid within these lifecycle and disclosure limits, and does not support these broader governance claims.”

Better benchmark publication is not a louder score.

It is a result that is harder to overread.
dipankarsarkar

Your checklists catch inflated wording. The case I keep hitting inflates with no wording to fix.

A dependency-resolution dataset went up today carrying a narrowly worded claim: 90.0% accuracy on a sealed validation set of entirely unseen packages. Nothing in that sentence overreads. It names the split, the holdout condition, the metric.

I paged all 3,432 rows of that split this morning. It is 81.4% failures, so always predicting failure scores 81.4%. The reported number is 8.6 points over a constant predictor. And on the 718-row subset where the question is actually interesting, always predicting pass scores 89.0%, against that 90.0% headline.

None of your four inflation checks fire on it. Not result-to-maturity, not comparison-to-assurance, not historical-to-current, not wording. The sentence is honest. The split composition did the inflating.

So I think the triad is missing a leg, and it is a cheap one: publish what a trivial predictor scores on the same split. Majority class for a classifier, random guesser for multiple choice, empty output for generation. One number, computed from the labels alone, no model needed.

That also gives PUBLISHABLE_WITH_LIMITS something mechanical to key on. A result sitting within a couple of points of its own trivial baseline is not NOT_PUBLISHABLE. It is publishable with the baseline printed beside it, and readers stop overreading on their own.

Harder to overread is the right goal. I would push it one step: hardest to overread is a score that ships with the number it had to beat.

Does 274 have a slot for the trivial baseline, or does that sit under disclosure?

·
kanaria007
•
edited 8 days ago

You’re right. 274 had an implicit place for this under comparability and disclosure, but it did not make the trivial-baseline publication surface explicit, so your example passed the existing checks too easily.

I’ve updated the article to add baseline-relative legibility: a task-appropriate trivial baseline under the same metric, scoring rule, split, and slice; the same-scope delta; and a PUBLISHABLE_WITH_LIMITS posture when a meaningful trivial baseline is omitted, the same-scope comparison is unavailable, or the result falls within the declared materiality or uncertainty band.

I also separated two cases that are easy to conflate:

  • a split-derived diagnostic baseline, which shows how much of the score is explained by the realized evaluation distribution; and
  • a precommitted operational baseline, which represents a simple alternative that could actually have been run without inspecting the final labels.

The update also covers decision-relevant slices, baseline selection, and post-hoc operating-point selection.

So the answer to your last question is: it previously sat only implicitly under disclosure. It now has an explicit slot.

Thanks, “the number it had to beat” was exactly the missing publication surface.
dipankarsarkar

Your new section caught me before it caught the publisher.

I pulled art-60-274 at the current head and read 4.4. The clause I did not expect is the anti-gaming one: report the strongest materially applicable trivial baseline, and do not select only the weakest because it creates the largest apparent advantage.

I gave you the weakest.

So I recomputed on the same sealed split. All 3,432 rows, same metric, same scope.

trivial baseline role accuracy
always predict failure split-derived 81.4%
per-pair majority split-derived 81.4%
run the resolver, predict fail iff it fails precommitted operational 97.7%

The published result on that split is 90.0%.

The split-derived family is degenerate here. There are exactly four package pairs and all four lean the same way, so knowing which pair a row is in buys 0.0 points over the constant predictor. Worth knowing on its own for a split sold as unseen-package generalization.

The operational one changes the sign. Its rule is fixed without touching a label: run the resolver, believe it. 2,714 of 2,793 true failures caught, zero false alarms, 79 missed. Which means it also reaches the second published number, 100% precision on failures, at 97.2% recall. Both headline figures, no model.

So the reported result sits below its own trivial baseline, and the baseline I handed you in this thread was 16 points under the real one, in the direction that flattered the argument I was already making.

Your two-role split is what made that visible, and I now think it is the load-bearing part of 4.4 rather than the trivial-baseline idea itself. The 81.4% answers how easy the split was. The 97.7% answers whether you beat something I could have run. Only the second can land above the reported score, so only the second can move a posture.

Your slice clause fires too. The decision-relevant slice is the 718 rows that resolved, of which 79 failed later. That 11.0% is exactly what a resolver cannot see, and it is the reason the dataset exists. No same-scope system score is published for it, so PUBLISHABLE_WITH_LIMITS, as written.

One thing 4.4 has no slot for, and I am not sure it should. The strongest baseline here is the incumbent the work exists to replace. Median resolve stage in that data is 0.17s on a populated cache, so it is not even costly. When the trivial baseline is the status quo, "did you beat it" and "was this worth building" collapse into one question, and a posture rule can only answer the first.

Does the baseline family need an eligibility or cost note, or is that deliberately outside publication discipline?

·
kanaria007

This is a very useful follow-up. And yes: I think eligibility belongs inside publication discipline, while cost belongs there only insofar as it materially affects whether the comparator is actually applicable. Whether the work was “worth building” is deliberately outside that boundary.

4.4 already points in that direction by defining an operational baseline as something that could actually have been run under the stated conditions, and by allowing task costs and operational consequences to affect materiality. So I do not think this needs a new posture rule.

The publication question is:

did you beat an eligible operational comparator under the declared conditions?

If latency, compute, data access, or another operating cost makes a comparator materially non-equivalent, that should be disclosed as part of the comparison. But cost should not be used silently to exclude an incumbent that was in fact available.

The next question

was the improvement worth the engineering effort, purchase price, deployment complexity, or opportunity cost?

is a separate value and decision surface. A benchmark can provide evidence to that decision, but it should not supply the utility function.

More generally, my own view is that this is the healthier role for a benchmark: it is a snapshot of where a system currently succeeds and fails, not a verdict on whether the work was worth building. Falling below an incumbent can be a useful result precisely because it tells you what remains to be solved. The publication problem begins when that snapshot is stretched into a commercial or deployment claim that the measurement itself does not support.

Your resolver result also makes the two-role distinction much clearer than my original example did. The 81.4% split-derived baseline tells us how much the realized evaluation distribution explains. The 97.7% operational baseline tells us whether the published system beat something that could actually have been run.

I would make one small distinction from your wording: I do not think only the operational baseline can affect publication posture in principle. A diagnostic baseline can also force a downgrade if the reported result is at or below what the realized split composition already provides. The operational baseline affects it for a different reason here: the system loses to an available comparator.

And with the 0.17s median resolve stage you reported, at least latency does not appear to explain away that comparison.

Thanks again for rerunning this against the revised section. The anti-gaming rule turning back on the original baseline choice is exactly the kind of failure mode I wanted 4.4 to expose.
dipankarsarkar

Taking the correction. A diagnostic baseline can downgrade, and my "only the operational one" was too strong.

But this split has a property I do not think 4.4 has a name for yet. Its diagnostic baseline is not independent of the operational one.

The 81.4% constant-fail number is not a fact about the task. It is the resolver’s failure rate. 2,714 of 3,432 rows fail at resolution, and that alone is what makes FAIL the majority class.

Condition on the incumbent and the majority flips. On the 718 rows the resolver passes, 639 pass. Always-PASS scores 89.0% there. Same split, opposite constant predictor, and it also clears 81.4%.

So the diagnostic baseline here is the operational baseline with its per-row discrimination deleted. Same rule, one bit instead of 3,432. That is the entire 16.3 point gap: 81.4% is assume the resolver’s modal answer, 97.7% is read it.

Which makes the diagnostic number worse than uninformative when it is reported alone. The published 90.0% clears it by 8.6 points, so the comparison reads as due diligence done. It is the incumbent, wearing enough of a disguise to pass.

I doubt this is rare. Any benchmark whose split composition is produced by the pipeline it means to replace inherits it. The label distribution is the comparator’s output distribution.

So does 4.4 need to ask where the split composition came from? If the majority class is an artifact of the comparator, a diagnostic baseline is not a second check. It is the first one with the evidence taken out.

·
kanaria007

Yes, I think this found a real missing axis, and I updated 274 for it.

I ended up giving it a separate 4.5 rather than stretching 4.4 further, because the issue is broader than baselines:

same-scope comparison is necessary, but it does not establish evidential independence.

The new section asks not only what an evidence surface reports, but where it came from, when it was fixed or selected, and what other published surfaces materially depend on the same upstream source or selection process.

So in your example the relevant questions are now explicit:

where did the split composition come from?

what material dependency exists between the diagnostic baseline and the operational comparator?

I also generalized the failure mode beyond this split. The same problem can occur with comparator-conditioned slices, label generation, scored populations under selective answering, or metrics and materiality rules selected after final outcomes are known. I called the broader failure mode evidence-dependency inflation: separately named evidence surfaces look like multiple checks even though they materially share provenance.

One arithmetic correction, though. 2,714 / 3,432 is about 79.1%, not 81.4%. The 81.4% constant-FAIL baseline comes from the 2,793 / 3,432 true failures. So I would not say that the label distribution is literally the resolver’s output distribution, or that the 81.4% baseline is literally the resolver with its row-level discrimination removed.

But I think your structural point survives that correction.

Of the 2,793 true failures, 2,714 are already in the resolver-fail region, while the remaining 79 sit inside the 718 resolver-pass rows. On your description, the realized evaluation surface and the incumbent comparator are therefore materially coupled. The diagnostic baseline should not be treated as independent corroboration of the operational comparison.

I would also stop slightly short of calling the 81.4% diagnostic worse than uninformative. It still tells us something real: a constant FAIL prediction gets 81.4% on this realized split. What changes is its evidential role. Reported alone, it can make a dependent diagnostic look like independent due diligence, especially when the published 90.0% clears it while still losing to the 97.7% operational comparator.

The update therefore does not prohibit dependent evidence. It makes the dependency visible and says not to count separately named surfaces as independent checks unless their provenance supports that interpretation.

I also updated the illustrative object so the diagnostic baseline, operational baseline, incumbent-pass slice, and their dependency relationships are separately identified rather than flattened into unrelated numbers.

So yes: “where did this split composition come from?” is now explicitly part of the publication discipline. I think that is the right generalization of the failure mode you found.
dipankarsarkar

Your arithmetic correction is right, and it makes the dependency provable rather than suspected.

2,714 / 3,432 is 79.1%, the resolver's FAIL rate. 81.4% is 2,793 / 3,432, the true-failure rate. My "the label distribution is literally the resolver's output distribution" was wrong by 79 rows.

Those 79 rows are the proof.

I paged all 3,432 rows of the sealed validation split again, this time pulling only outcome and stages. The whole split has exactly four stage ladders:

2,714 resolution_failure: create_environment:0 > capture_runtime:0 > capture_toolchain:0 > resolve_artifacts:1 > cleanup_environment:0
639 pass: ... resolve_artifacts:0 > install_exact_artifacts:0 > capture_environment:0 > smoke_test:0 > cleanup_environment:0
60 import_failure: same ladder, smoke_test:1
19 smoke_test_failure: same ladder, smoke_test:1

So resolution_failure is not correlated with the resolver. It is resolve_artifacts exiting 1, on 2,714 of 2,714, and the run halts there with no install and no smoke stage. Score that exit code as the predictor: tp 2,714, fp 0, fn 79, tn 639, 97.698%.

fp = 0 is not a precise incumbent. It is an identity. A false FAIL is unconstructible on that region, because the label and the prediction are the same variable. The 79 errors are all downstream stages the resolver never claimed to cover.

That is a detection rule 4.5 could carry, and it is stronger than the provenance question. "Where did the split composition come from" needs the publisher to answer honestly. A zero off-diagonal cell is visible from the published artifact alone. Thousands of scored rows with exactly one empty error cell means the label and the comparator probably share a producer. So: publish the confusion matrix, not the accuracy.

Smaller thing I hit on the way. import_failure and smoke_test_failure have byte-identical ladders, and exception_type is ImportError on all 79 of them, 60 of 60 and 19 of 19. What actually separates them is an in-band stdout sentinel, {"deplab_stage": "imports_passed"}, present on 19 of 19 and 0 of 60. It works, but two of the four label values cannot be reconstructed from the machine-readable fields a consumer reaches for first.

Is that the same axis, or does a label need its own clause: reconstructible by a reader who only has the published columns?
In this post