What the decision rests on today
A validity check, and nothing behind it.
Every one of these is believed because of who supplied it, and none of them can be checked after the fact by the person who has to act on it.
A certificate that validates today says nothing about what any log carried on the day in question.
A timestamp is whatever the reader's clock said. There is no second clock to hold it against.
A retention policy decides what survives the incident. The evidence you need is the evidence most likely to be gone.
What oddly puts on the record
The same thing, observed.
Two clocks on every row: when the log signed it, and when we looked. A root a day. An anchor outside us.
The certificate transparency logs, re-observed on their own cadence at the operators that publish them.
When the log signed its tree head, and when we looked. A log runs a few seconds ahead of our clock and we show the sign rather than hide it.
The day your agent's actions are observed the same way, its receipts sit under the same roots. Declared, not sold, until it exists.
The verbs
Observe. Seal. Publish. Anchor.
The same four on every surface. A product here is the record read for one decision, never a second machine.
Read the source as it is published, and write down both clocks.
Hash the row with its predecessor, so no receipt can move without every later one changing.
Fold the day's receipts into one root and put it where anyone can read it.
Submit the root to a chain we do not run. From then on, checking us does not involve us.
One signed tree head, read live
One log, its own clock, and ours beside it.
Every slot is read at load. A row reads [unread] when the newest observation on the ledger belongs to another class, because a sample row here would be the one thing this surface exists to refuse.
- observation
- [unread]
- log
- [unread]
- attribute
- [unread]
- value
- [unread]
- source
- [unread]
- the log signed at
- [unread]
- we looked at
- [unread]
- gap, with its sign
- [unread]
- receipt
- [unread]
- day root
- [today's root]
- anchored in block
- [pending]
- confirmed
- [pending]
A negative gap means the log's own clock was ahead of ours when we read it, which is a fact about a source we do not control and not a fault in the reading. The anchor reads [pending] until a day has been confirmed in a block, because a pending batch has no block height and printing one as anchored would be worse than printing nothing.