What required evidence changes

A signed result can still be wrong in an important way.

Not because the signature is bad.

Because the verifier may have judged only the evidence someone chose to send.

That sounds subtle. It isn't.

Suppose an engineering agent is told:

Migrate production without breaking billing.

The database tests pass.
The API tests pass.
CI passes.
Checkout passes.

But production billing is failing for 3% of customers.

If that billing telemetry is included, the overall job should fail.

If it is omitted, a naive verifier can look at everything it was given and say:

Looks good.

That is the problem.

Missing evidence cannot quietly become success

The old question is:

Did the evidence I received pass the checks?

The better question is:

Did I receive all the evidence the agreement said I needed before I was allowed to call this successful?

Those are different questions.

For billing, the agreement might say:

• I need billing telemetry
• it has to come from the billing system
• it cannot be supplied only by the provider being evaluated
• it has to be less than five minutes old

Now the verifier has something much stronger than a checklist.

It knows what it was supposed to see.

Five different situations should stay different

If the evidence arrives and is valid, great.

But there are several ways it can fail before we even judge what it says:

Present
The right evidence arrived, from the right place, and it is fresh enough.

Missing
It never arrived.

Stale
It arrived, but it is too old.

Unavailable
The system tried to get it and could not.

Wrong provenance
The evidence exists, but it came from someone the agreement did not allow to satisfy that requirement.

Those should not all collapse into "fail."

They mean different things.

A failed check says:

We had the evidence, and it showed the requirement was not met.

Missing evidence says:

We do not know enough to make that call.

That distinction matters.

Uncertain is a real answer

If billing telemetry was required and never showed up, Spoolis should not say PASS.

It should also not pretend billing failed.

It should say:

We do not have enough evidence to know.

That is an UNCERTAIN result.

The same applies when the telemetry is stale, unavailable, or comes from the wrong source.

This is important because software may act on the answer.

A payment system might release money.
A deployment system might continue a rollout.
Another agent might start the next task.

"I don't know" is much safer than turning missing evidence into false confidence.

The evidence rule belongs in the agreement

The verifier should not get to invent stricter requirements after the work is delivered.

And the provider should not get to weaken them afterward.

So the evidence requirements live in the agreement itself.

Before the work starts, the agreement can say:

To call billing healthy, I need this telemetry, from this source, no older than this.

Then the receipt can say:

Here is what was required.
Here is what arrived.
Here is what was missing or stale.
Here is what the evidence actually showed.

That is a much stronger result than:

Here is how we judged whatever someone happened to send us.

Why I think this matters

The hard part of verification is not just asking AI whether something passed.

It is making the basis for that judgment explicit.

What evidence counted?
Who was allowed to supply it?
How fresh did it have to be?
What happens if it never arrives?

The signed receipt is useful.

But the more important thing may be making what had to be proven explicit before anyone acts on the result.

That is the direction Spoolis is moving.

For developers

Read the Outcome Receipt specification for the exact fields and the five completeness states. Read verify a receipt for requireOutcome usage and consumer policy checks.