Skip to content
deedglassdocs

What VERIFIED means (and what it doesn't)

VERIFIED means Deedglass compared what the agent reported with an independent observation and found no difference. The level says which observation: L0 Reported is the tool’s own response; L1 Confirmed is a read-back from the target after the action; L2 Witnessed is the change Postgres actually committed, read from its change log. VERIFIED does not mean the action was a good idea, that nothing else changed outside what Deedglass watches, or that a compromised host could not lie. When Deedglass can’t observe enough, the verdict is UNVERIFIABLE, never VERIFIED.

At each level

Section titled “At each level”
  • Claimed ·Matches The connector Deedglass called returned success, and its output matched the tool’s schema when the tool has one. In proxy mode, the edge that ran the call reported success: Deedglass did not run it and can’t tell a truthful edge from one that lies.
  • Checked ·Matches After the tool returned success, a read of the same target, with arguments taken from the request or the result, returned the values the action implied. For a Postgres row: the row named by its primary key was last written by the action’s own transaction, and each compared column holds the value the statement set.
  • Proven ·Matches The row changes Postgres committed in the action’s transaction, read from Postgres’s own change stream, equal the changes the action was expected to make: the same rows, the same counts, the same compared values.

What it rests on

Section titled “What it rests on”
  • An honest target for L1. A read-back sees what the target chooses to answer.
  • An honest Postgres for L2. Deedglass trusts the Postgres server, its owners and superusers, and an unmodified decoding path.
  • An uncompromised Deedglass host and seal key. The Witness runs inside Deedglass. A verdict is only as good as the process that decided it and the key that sealed it.
  • Sound primitives: Ed25519 and SHA-256.

What a deed never claims

Section titled “What a deed never claims”
  • That the action was wise. An in-policy action by a hijacked agent can be VERIFIED. Policies, budgets and approvals narrow this; they don’t close it.
  • Anything outside the watched system. L1 sees only the fields read back; L2 sees only the watched tables. Emails sent, files written and calls to other systems are outside both.
  • The state of the target now. A later change doesn’t alter the deed.
  • More than its level. L1 · VERIFIED says nothing about L2. Gaps at other levels are listed in the detail, never folded into the claim.

When the answer is UNVERIFIABLE

Section titled “When the answer is UNVERIFIABLE”

Claimed ·Can’t check means Deedglass could not observe enough: the tool timed out and may have run, a read-back failed, the change log was behind or lost, or the statement was too complex to predict. The reasons on the action name the gap. Unknown stays unknown.

What it doesn’t do

Section titled “What it doesn’t do”
  • A verdict is not a judgement of the agent, the model or the person who approved.
  • Deeds hold digests of the request and result, not the payloads. You need the original request to match a deed to it.
  • COSE output is a signed statement from your Deedglass instance, not a transparency-log entry. Deeds aren’t anchored in any external log in v1.

Next

Section titled “Next”