When to use Noticer

Use it when your agent has submitted or delegated an action to another system, such as a deploy, a publish or an order update, the tools it has can't independently confirm the result, and the result shows up as one field in a public HTTPS JSON record.

You probably don't need it when a direct request you are allowed to make already answers the question, and nobody needs independent evidence. Just fetch it. You also can't use it when the result isn't visible in public JSON.

Remember: "request sent", "200 OK" and "accepted" mean the handoff happened. They don't mean the outcome happened. And Noticer reports what the source says, not the real-world event.

Before the next step: verify the previous handoff first. A gate or approval that allows a step does not mean the step ran.

BEFORE YOU START, CHECK THAT

If the evidence isn't good enough (the page didn't load, the control didn't match, the 20 to 120 second window ran out), you get INCONCLUSIVE. It's free, and your agent should treat it as "not confirmed".

WHAT IT CHECKS (ONLY THIS)

DO NOT USE IT WHEN

WHAT YOU GET

PROVED, DISPROVED or INCONCLUSIVE, with a signed receipt you can verify offline and a ledger entry. The verifier and signing keys are public.

PRICE

LIMITS

Payment buys a report only. It is not access control or a workflow gate. There is no exactly-once or no-click purchase promise.

WHICH PATH TO USE

There is one product. Pick the door that matches how you work:

ENROLL (START PAGE)

Use the Start page to enroll. Do not build a raw enroll request unless you know what you are doing.

VERIFY A DOWNLOADED PACKAGE

The published keys file (/.well-known/noticer-keys.json) is a JWKS object: {"keys":[…]}.

verifier.py --key needs one JWK object, not the whole JWKS file. Pass the key whose kid matches the receipt, or the first key in keys when there is only one. Passing the whole JWKS file fails with a bare ValueError.

START