qbrinInside qbrin · 4 of 6
Evidence, verification, and authorization are three different gates
An agent can have excellent evidence for a claim and still be forbidden to act. It can also be authorized to call a tool while having no factual basis for the specific call.
Those are not edge cases. They are what happens when three separate questions—evidence, verification, and authorization—are compressed into a single confidence score or prompt instruction.
Gate one: do we have the evidence?
Evidence is the material available to the system: a policy clause, telemetry sample, maintenance record, signed approval, customer message, or sensor reading. The evidence gate checks whether the required sources exist, are accessible to this caller, are fresh enough, and refer to the right entity.
Retrieval relevance helps find candidates. It does not settle authority. A six-month-old runbook may be semantically perfect and operationally obsolete.
Gate two: does the evidence prove the claim?
Verification compares the proposed claim with the evidence. It asks whether the source entails the statement, contradicts it, or leaves it unresolved. “The customer discussed a refund” does not prove “the refund was approved.” “Pressure is within range” does not prove “opening valve V-17 is safe under the current mode.”
This is where citation quality matters. A citation should support the exact payload, not merely share its topic. qbrin's public contract—cited or abstains—puts this gate in the answer path.
Gate three: may this identity perform this action?
Authorization is a policy decision. It considers the agent's identity, credential scope, environment, requested tool, action parameters, risk class, and any required approval. A verified fact can inform the decision without granting the permission.
| Scenario | Verified fact | Authorization question |
|---|---|---|
| Finance | The invoice is overdue | May this agent issue credit or only notify? |
| Operations | The service is unhealthy | May it restart production, or request approval? |
| Manufacturing | Temperature is rising | May it change a setpoint in this operating mode? |
| Aerospace | Telemetry indicates a navigation fault | Which contingency actions are permitted now? |
The correct order matters
A safe action path is usually evidence first, claim verification second, and authorization third. There is little value in checking permission for an action whose premise is unsupported, and no amount of support should bypass the policy gate.
Evidence: “What records or signals do we have?”
Verification: “What do those records actually support?”
Authorization: “Given that support, may this identity take this specific action here and now?”
Log the boundary decision, not just the model text
An audit trail should record the evidence identifiers, claim checked, verification result, policy version, requesting identity, proposed action, final disposition, and human approval where applicable. This makes a HOLD or denial explainable and lets teams replay policy changes without guessing what the model meant.
Observability traces are valuable inputs to this record. The essential difference is that the gate must be able to change the outcome before execution, not only describe the execution afterward.
Designing failure states
Each gate should fail differently. Missing evidence asks for a source. Failed verification removes or corrects a claim. Failed authorization denies the action or requests an approver. A generic “low confidence” state collapses three remedies into one ambiguous warning.
This separation is also how teams expand safely. They can improve retrieval without loosening policy, change a model without changing identity scopes, and test a new action class in shadow mode before allowing it to execute.
Knowing is not proving. Proving is not permission. A dependable agent stack makes all three visible.
Comments
Sign in with GitHub to reply. Threads live in a public repository, so anyone can read them without an account.