COREEvidence product
Evidence Engine
Evidence is not collected here. It is created, as a byproduct of the operation itself. This product defines what a record is, writes it while the operation runs, seals it at that moment, and answers whether it still matches what was sealed.
Four other evidence products read what it produced. None of them can produce it, which is why the architecture begins here.
A record is only useful if a stranger can check it.
Most records are readable but not checkable. You can open them, and you can be told they are accurate, but nothing in the record itself establishes that. Nor can the gap be closed afterwards: a record assembled once the operation is over is a description written by whoever survived it, and no amount of later care makes it evidence. This product exists because that gap can only be closed at the moment the operation runs.
- A log: Describes an event
- A record: Is part of the event
- A log: Trusted because of where it is stored
- A record: Trusted because of its own bytes
- A log: Checked by asking the operator
- A record: Checked by anyone holding it
Every claim the platform makes resolves to a record this product wrote.
A receipt binds to one. A verification checks one. A coverage ratio counts them. An executive view reads them. If the definition of a record were loose, everything above it would inherit that looseness. That is why the definition is the product rather than a detail inside one.
Three record types. One layer.
envelopeWhat happened
The operation as it occurred: what was requested, what the policy returned, what followed. Written during the operation, not assembled from it afterwards.
receiptProof it happened
A sealed statement bound to exactly one envelope by its digest, carrying the time it was sealed. It proves the envelope existed then and has not changed since.
provenanceWhere it came from
The origin of the operation: which agent, which surface, which version produced it. Part of the record rather than inferred from timestamps later.
Content-addressed
A record is identified by the digest of its own bytes. Changing any part of it changes its identity, so a modified record is not a modified record. It is a different one, and the reference to the original stops resolving. Tampering does not produce a corrupted record; it produces a missing one.
Written once, read by everything
There is one evidence layer and every surface reads it. No product keeps a private copy, so there is nothing to reconcile, no synchronisation step and no second version of what happened.
Written, sealed, read, checked.
Four stages, and the interesting property is what is missing between them: no transport, no ingestion, no transformation and no expiry. A record is the same object at every stage.
Both outcomes are written. A refused operation produces the same object as a permitted one, with a different outcome, so the absence of a record never means an absence of scrutiny.
The receipt carries the time of sealing. Sealing later would only prove the record has not changed since the seal, which is not the interval anyone is asking about.
Reading never rewrites. An executive view, an assessment and an export of the same record are three readings of one object rather than three derived copies.
The check runs against the bytes and returns one of the canonical states. It does not consult us, and it does not need the deployment that produced the record to still exist.
●Ready The receipt matches the envelope it refers to.
- envelope
ev_bf6442d03d1d4615…- receipt
rcpt_711e51de6f0049…- checked by
local · no remote call
A check has more than two answers
Valid and invalid are not the whole set. A record can be partly present, absent because everything looked and nothing matched, or unavailable because nothing could look. Those last two are different facts, and they are never merged.●Ready◐Partly done○Nothing yet?Cannot tell
You do not install it separately.
This is the one evidence product with no install path of its own, and the reason is structural rather than commercial: it is the layer the runtime writes into. Where governed operations happen, it is already there.
- Run an assessment
- Nothing is installed. Records are produced and can be checked immediately. The shortest path to holding one.
- Install the runtime into an editor
- From then on, operations produce records as they happen. Two editors install today.
Depth is inherited, not configured here
How much a record contains follows from the capture level enabled in the runtime. This product defines the shape of a record; it does not decide how much of one gets filled in.
A level never enabled produces no record, and a reader is told nothing could look, never that nothing was wrong.
There is no packaged installer for anything in the platform, and nothing on this page is a download. The two routes above are the whole of how records come to exist today.
What a record never claims.
A record establishes what was requested, what the policy returned and what followed. Whether that was the right thing to do is a judgement it does not make.
Records are of operations, not of states over time. Nothing here supports a claim about improvement or decline across a period.
No severity is produced, so nothing orders one record above another. Records are read in the order they occurred.
A receipt is evidence, not a certificate. Nobody is accredited by holding one.
No composite, grade or percentage is derived from a set of records. A ratio can be counted from them; a score cannot be checked against them.
Operations that did not pass through the runtime leave no record, and their absence is reported as absence rather than as approval.
The value of a record is exactly the set of things it refuses to say.
An object that answers every question is answering some of them by guessing, and a reader has no way to tell which. Narrowing what a record asserts is what makes the assertions worth relying on years later. Evidence first. The rest follows. Every capability above this layer reads what it wrote, so adding a capability does not add another source of truth.