Negative Results Are Production Capital

Most agent demonstrations end with what the system produced.

Production systems need a second question:

What did the system refuse to produce, and can it prove why?

This is the story of a graph-relation trial that failed its quality threshold and wrote nothing to production. The zero was not an accident, an outage, or missing data. It was the intended outcome of a negative-result gate.

The trial

An extraction pipeline generated candidate relationships for a knowledge graph:

candidate relations: 308 human sample: 50 correct: 10 precision: 20% preregistered gate: 80% production writes: 0

Twenty percent precision was not close enough. The system retained the candidate artifact and the human review table, but wrote zero typed relations to the production graph.

The useful result was not a graph. It was a measured boundary.

Why a negative result is capital

A rejected trial can create five kinds of durable value.

1. Pollution prevention

A plausible graph can be more dangerous than an empty one. Labels look complete, tools consume the structure, and downstream users may assume that publication implies validation.

Zero writes prevented that false completeness from becoming shared state.

2. A concrete quality boundary

“The relation extractor is not ready” is vague.

This is concrete:

20% sampled precision against an 80% production threshold for this method and representation

It tells the next engineer what failed and what a restart must improve.

3. Comparative evidence

Future methods can be compared with the same retained candidate set and review sample. The negative result becomes a baseline rather than a forgotten experiment.

4. Recovery-cost avoidance

Once false relations enter a graph, later work changes: dashboards count them, retrieval uses them, reports cite through them, and cleanup becomes an investigation.

The cheapest time to remove a bad relation is before it reaches production.

5. Observable trust

A system that can say “we measured the output, missed our threshold, and wrote zero rows” is easier to trust than a system that reports only successes.

Refusal is a product capability.

What a negative-result gate needs

declare method and threshold → generate candidates → draw a human sample → compute precision → compare with the threshold → if below: retain candidates, review table, and zero-write proof → mark method deferred, not impossible

The evidence must survive:

candidate count;
human sample size;
correct count;
computed precision;
threshold;
production write count;
method and representation;
decision timestamp;
reviewer role.

Without those artifacts, “we decided not to ship” is only a story.

Refusal also applies outside graphs

The same pattern appears in a natural-reuse observation. Controlled workflows showed that claim cards could be selected and accepted. Later normal work in the first intranet cohort used zero of 27 target claims in the primary 50-project sample.

That did not prove the claims were useless. The cohort was highly concentrated by workflow type, configuration, and creation time. It did prove something narrower:

controlled adoption did not reproduce naturally in this cohort

Retaining the zero prevented a stronger and unsupported claim: that asset compounding had been demonstrated.

Failure must include its boundary

A negative result becomes harmful when it turns into a universal prohibition.

This trial does not prove:

relation extraction is impossible;
every generated relation is wrong;
the same threshold applies to every domain;
a different model or evidence binding will fail;
blocking the write improved business productivity.

It proves that one method, representation, prompt, evidence binding, and threshold combination did not meet the production bar.

That distinction is what makes the result reusable.

Make the gate executable

The pattern can be represented as a policy check. The block below is illustrative, not shipped code.

{ "id": "negative_result_gate", "policy_type": "threshold", "fail_closed": true, "threshold": { "metric": "human_precision", "minimum": 0.8 }, "on_failure": "block", "blocked_operation": "production_write" }

The evaluator passes when a failed precision blocks production and fails when the system writes rows anyway.

That is a small but important shift: the governance rule can be tested independently of the model that generated the candidates.

The practical test

For the next agent trial, ask:

What threshold did we declare before looking? What did a human actually sample? What would count as a failure? Did the failure stop the production write? Did we keep the evidence? What exact claim are we refusing to make?

If the team cannot answer those questions, the system is not demonstrating governance. It is demonstrating generation.

Non-claims

This article is grounded in one production research case and public aggregate evidence. It is not a universal claim about model quality, graph extraction, or productivity.

The stronger lesson is narrower: