Foundation 03 · Verifier policy

Verification ends
where judgment begins.

A technical check can establish something about an artifact, credential, signature, or record. A verifier still decides whether that result is current, sufficient, proportionate, and appropriate for a particular decision.

Learning boundary. This lesson does not set policy for an organization, provide legal or compliance advice, verify a credential, authorize a transaction, or decide whether a particular source or system should be trusted.

Learning objective

Connect a technical check to a named local decision rule and a repairable record.

By the end of this lesson, you should be able to define the subject, relying party, verification result, decision threshold, exception owner, correction route, and review record that a trust-sensitive workflow needs.

01 · Policy

What result is sufficient for this decision?

State the decision, the permitted evidence types, freshness requirements, issuer or source criteria, and the outcome of a missing, expired, or conflicting record.

02 · Verifier

Who applies the rule?

Name the responsible person or system, its scope, and the record it produces. Avoid treating an automated check as self-authorizing when the decision affects another person or a meaningful resource.

03 · Exception

What pauses the normal path?

Define the hold state, accountable resolver, evidence packet, and expiry. The point of a policy is not to remove human judgment but to make its handoff visible.

04 · Correction

How can a wrong or outdated record be repaired?

Keep a public or internal route for challenge, review, correction, withdrawal, and a link to the superseding record. Correction is part of a trust surface, not an embarrassment to conceal.

Practice lab

Write a reliance rule for a public credential display.

A hiring team receives a credential that passes a cryptographic check and is not reported revoked. The credential identifies an issuer and holder, but the role requires a specific current qualification and a jurisdiction-specific approval that may not be encoded in the credential.

  1. State what the technical verification result establishes and what it does not.
  2. Write the additional evidence and freshness rule the hiring decision requires.
  3. Define the exception owner if information conflicts or the credential cannot be independently checked.
  4. Design a correction or withdrawal route if a public display of the credential is later challenged.

Source shelf

Study the line between verification and reliance.

  1. W3C Verifiable Credentials Data Model v2.0Read its treatment of issuer, holder, verifier, verification, validation, and verifier policies. It explicitly separates credential verification from evaluating whether included claims are fit for reliance.
  2. NIST AI Risk Management FrameworkUse the voluntary framework to organize accountable governance and ongoing risk-management questions; do not represent it as a certification of a local policy or workflow.