Skip to main content
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.
Verify is a planned Act component. The current public Action contract does not expose a verification_required state or a dedicated verification operation yet.
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.

​
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 or Approve when a verified claim still needs an explicit user decision.
Last modified on September 22, 2026