> ## Documentation Index
> Fetch the complete documentation index at: https://darwin.so/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Verify

> Establish whether a specific claim or requirement is supported without granting authority.

Verify establishes whether a bounded claim is supported by evidence or a trusted provider. Examples include email or phone ownership, identity or age, business status, account ownership, a credential, delivery, settlement, or completion of an external requirement.

<Note>
  Verify is a planned Act component. The current public Action contract does not expose a `verification_required` state
  or a dedicated verification operation yet.
</Note>

Verify should remain an out-of-band, verifier-confirmed flow rather than a caller-asserted endpoint. Darwin returns a bound first-party `webLink`; the verifier reports a result tied to the exact claim; then the caller reads the same `actionId`. A client message saying “verified” is never sufficient evidence.

## Bind the claim

A verification interaction should identify the exact subject, claim, verifier, method, required freshness, and expiry. If any of those changes, the previous result cannot silently satisfy the new interaction.

```text theme={null}
verification needed -> review claim and verifier -> collect or retrieve evidence
                    -> verifier returns a bounded result -> same Action resumes
```

## Keep verification separate from authority

* A verified identity does not approve an Action.
* Verified account ownership does not authenticate Darwin for future use.
* Verified payment settlement does not approve changed commercial terms.
* A message saying “verified” is not evidence that a typed verification completed.

Verification outcomes must preserve uncertainty. A provider timeout, censored response, or missing evidence remains unknown or inconclusive rather than becoming a failed claim.

## Protect evidence

Use a first-party `webLink` or provider flow for sensitive evidence. Return the minimum attestation needed by the Action, not raw identity documents, biometric material, one-time codes, or unrelated provider records. Keep sensitive evidence out of model context, logs, traces, analytics, and ranking data.

Continue with [Verify best practices](/docs/act/verify/best-practices) or [Approve](/docs/act/approvals) when a verified claim still needs an explicit user decision.