Intake
Every door answers the same five questions about what arrived, and the answers are written onto the record and sealed into the receipt. They do not change a score.
An earlier design scored them. The engine’s own note refuses it: minimum-over-caps is sound because freshness, class and re-ingest ceilings measure different failure axes, and a step between two estimators of ONE axis produces a trough by construction. What an arrival proves about an identity claim is the axis the actor keyring already prices.
The five questions
| # | The question | Why it is asked |
|---|---|---|
| 1 | Can we tell WHO sent it? | A class is granted from an observer identity. If the arrival establishes nothing about who sent these bytes, the identity is a name somebody typed. |
| 2 | Can we tell it was NOT ALTERED on the way? | Integrity in transit. Without it, the bytes compared are not the bytes sent. |
| 3 | Can we tell it is not an OLD READING REPLAYED? | Freshness binding. A correct measurement presented late is a different fact. |
| 4 | If we fetched it: WHEN, and FROM WHERE? | A retrieval record is real evidence about a public source, and it is not the same evidence as a signature. |
| 5 | Can the source DENY having sent it? | Non-repudiation. This is the audit-log control AU-10 stated as a question about a door. |
What a class rests on
The engine decides what evidence is worth from who observed it. Two things can establish that, and they are not equally strong:
| How the identity was established | What it proves | What the class rests on |
|---|---|---|
| A signature over these bytes, from a key in a signed actor registry | this observer committed to this exact record | a signature |
| A signed rule table mapping actor names to classes | the operator signed the table; the actor name is still the caller’s | the operator’s control of their own ingest boundary |
| Neither — no registry configured | nothing about who sent it | nothing. The default floors every class to SELLER-ASSERTED, and says so on the record. |
Which door each product uses
| Product | What arrives | The doors it needs |
|---|---|---|
| TellmeTiresias | staff entry and IoT device readings | keyed, device |
| AttestedAssets | human entry and API responses | keyed, api |
| Stock Risk Receipt | API feeds, web pages and social posts | api, retrieved |
| Corobate | supply-chain activity from AI and human agents | agent, keyed |
| PaymentVerification | output of a sealed execution | sealed |
Where this is honest about not being finished
- The arrival is not yet recorded on the receipt. The transport layer strips it. This page states the contract; the record does not yet carry it.
- Two products — F08 and AttestedAssets — do not consume
provenance-classingat all, so the who-observed-it distinction does not reach them even in the declared architecture. - A sensor reaching its full class requires a signing key enrolled per device. Under the secure default a sensor is worth SELLER-ASSERTED, and no amount of naming it
actor:sys:sensor:changes that.
PaymentVerification · standalone install · one product · built by 27-console/build-console.js from the register, not typed.
This page loads nothing from another origin, makes no request at run time, and touches no browser storage. It works from a file on disk with no server.
Nothing in this console is legal advice.