Reading a verdict and proof

A completed verification gives you a categorical determination, review signals, per-criterion evidence, and an Ed25519-signed proof. The narrow automation gate is status === "succeeded", determination === "met", flagged === false, and a proof that verifies against the request you expected.

Determination semantics

Value	Meaning	Caller implication
`met`	The rubric requirements were satisfied.	Eligible for automation only when unflagged, proof-verified, and acceptable under your evidence policy.
`not_met`	A hard requirement failed.	Treat the rubric as failed; still honor review policy for flagged or adverse actions.
`cannot_determine`	AI Verify abstained because it could not honestly decide.	Human review or more evidence. Never auto-pass or auto-fail.
`partial`	Wire value for a graded shortfall without a hard failure.	Review or apply your product-specific threshold.

Roll-up is conservative: not_met > cannot_determine > partial > met.

ABSTAIN is a feature

cannot_determine is the ABSTAIN path. Abstaining is a feature, not a failure. It means the system refused to fabricate a pass or fail from missing, contradictory, below-trust, premature, or unavailable evidence. Treat it as substance-unknown: route to review, request more evidence, or retry a transient failure. Do not map an abstain to not_met.

Trust tiers

Tier	Warrants	Does not warrant
T0 `deterministic`	A system-computed primitive result over specific bytes.	Real-world truth beyond the input and primitive.
T1 `source_attested`	A registered source signed the payload and binding verified.	That the source is truthful or the rubric is satisfied.
T2 `third_party`	Independent or external material was cited.	Source attestation, freshness, or tamper resistance.
T3 `claimant`	The submitter supplied or asserted the evidence.	Independent truth or suitability for high-trust criteria.

Trust tiers are server-derived. A signed proof records the tier; it does not upgrade claimant evidence into source-attested evidence.

Strict proof verification

{
  "verification_id": "44444444-4444-4444-8444-444444444444",
  "format": "acretix-verify/proof/2",
  "signing_domain": "acretix-verify/proof-sig/2:",
  "jwks_uri": "/.well-known/acretix-verify/keys.json",
  "proof_head_hash": "<server-served terminal content_hash>",
  "entries": [
    {
      "seq": 0,
      "key_id": "ed25519-...",
      "algo": "ed25519",
      "format": "acretix-verify/proof/2",
      "prev_hash": null,
      "content_hash": "<sha256 hex>",
      "signature": "<base64 Ed25519 signature>",
      "envelope": "<canonical JSON bytes>"
    }
  ]
}

Anti-forgery warning: resolve proof keys only from your pinned or configured trust root, never from envelope.jwks_uri. Anchor the terminal head against the server-served trusted proof_head_hash, not a value read from a holder-supplied envelope.

Fetch trusted Ed25519 keys from the configured API origin, pinned JWKS, or pinned key set.
Get the trusted terminal proof_head_hash from the configured server or your own receipt log.
Bind expected verification_id and submission_hash from your request log.
Sort entries by seq; require contiguous order starting at 0.
Recompute SHA-256 over each exact entry.envelope byte string.
Require signed format acretix-verify/proof/2 and signed algo ed25519.
Bind side-channel key_id, algo, format, seq, and prev_hash to the signed body.
Verify Ed25519 over acretix-verify/proof-sig/2: plus the recomputed content hash.
Verify chain continuity: every prev_hash equals the previous recomputed content hash.
Require the final recomputed content hash to equal the trusted server-served proof_head_hash.
Reject a valid but unrelated proof if the signed subject does not match your expected request.

Fail closed on unknown key, unsupported format, content-hash mismatch, envelope mismatch, broken chain, signature failure, missing trusted terminal head, terminal-head mismatch, or subject mismatch.

Errors and edges

queued and running are lifecycle states with no verdict yet. A bounded-sync wait_ms timeout returns 202 and should be polled.failed is operational failure with no substance call. A succeeded cannot_determine result is a completed abstain. flagged and route holds are review signals, not separate determinations.

Worked example

{
  "status": "succeeded",
  "determination": "cannot_determine",
  "score": null,
  "confidence": 0,
  "flagged": true,
  "flag_reason": "needs_review: source_attested evidence required",
  "submission_hash": "0e16249f94b2fd33c91495704c6b992fa8d70e5ca84dfc058ff2f9a05f46757c",
  "proof_ref": "/v1/verifications/44444444-4444-4444-8444-444444444444/proof",
  "verdict": {
    "results": [
      {
        "primitive": "llm_judge@1",
        "determination": "cannot_determine",
        "rationale": "Required source-attested evidence was not available.",
        "evidence_spans": [{ "trust_tier": "claimant" }],
        "flagged": true
      }
    ]
  }
}

This result is not a rejection. It is a completed ABSTAIN because the cited evidence is only claimant-tier while source-attested evidence was required. Review it or request stronger evidence, and verify the proof before treating the abstain itself as signed.

Full markdown guide: docs/result-interpretation.md.