Evidence, selectors and verification

Evidence has two parts: a preserved capture and a precise selection within it. A citation URL identifies a location; it does not guarantee that the bytes seen during the decision remain available or unchanged.

Captures

A capture records acquisition start/finish, requested/final URL where relevant, collector/version, media type, completeness, limitations, integrity and storage identity. Byte captures require a verified object version/hash. Pending, partial and failed captures retain their acquisition state rather than pretending to be complete.

Examples include an original HTTP response, rendered page, screenshot, provider payload, uploaded file or metadata-only capture. Two acquisition attempts remain distinct even when content hashes match. Access and retention policies apply to the evidence itself.

Select exactly what supports the statement

Links state whether the evidence supports, contradicts or repeats the claim. Preserve contradictory evidence rather than hiding it to improve a confidence score. Repeated claims from dependent sources do not establish independent confirmation.

Example: one receipt supports delivered

Suppose the supported collector/upload workflow has preserved a JSON receipt {"order_id":"O-001","delivered":true} in this project. Use its real accessible capture UUID and calculate the selector hash using the collector/runtime's selected-value serialization. Verify the bytes before creating an extracted claim for subject https://example.com/orders/1, predicate https://example.com/operations#delivered, value boolean true.

{
  "captureId": "<REAL_CAPTURE_UUID>",
  "relation": "supports",
  "selector": {
    "kind": "structured_path",
    "jsonPointer": "/delivered",
    "valueSha256": "<SHA256_OF_SELECTED_VALUE>"
  },
  "sourceReliability": 0.9
}

This structure is a contract example, not a public HTTP endpoint or an MCP create tool. Replace the capture/hash placeholders with real verified values. Extracted and derived claims require evidence; inventing a UUID or writing true in a free-form evidence object does not satisfy that requirement.

MCP capture_get inspects the private capture manifest and custody information without returning raw bytes to the prompt. claim_get inspects actual claim links. Neither tool creates missing evidence.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "capture_get",
    "arguments": {
      "projectId": "<PROJECT_UUID>",
      "captureId": "<REAL_CAPTURE_UUID>"
    }
  }
}

Verification tasks and findings

A verification task records a method, instructions and limitations for a claim. A finding records AI/reviewer origin, supports/contradicts/inconclusive/unverifiable result, rationale, limitations and evidence links. An AI finding cannot review another finding as a human. The contract separates checking from approving the original claim.

For the receipt, the task can ask “Does this receipt identify O-001 and record completed delivery?” A receipt for O-002 contradicts the association even if its delivered value is true. An unreadable receipt is inconclusive/unverifiable, not false.

The task/finding contracts are available in the governed runtime. The currently documented public API/MCP surface does not expose generic task/finding creation calls; do not substitute internal routes as workspace-key APIs. Inspection is available through claim detail.

Derivations and downstream impact

A derivation records input/output resources, execution identity, transform/version, model and prompt provenance where applicable, parameters and recorded usage/cost. It explains how a source capture or claim produced another claim/artifact. Corrections and retractions can mark dependent outputs stale or requiring review; they do not automatically recompute every downstream asset.

Inspect the impacted records and rerun/review the relevant consumers. Evidence history explains a past decision; it does not make that decision eternally valid.