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 Link to this section

What each determination means
Value	Meaning	Caller implication
`met`	The rubric requirements were satisfied.	Eligible for automation only when not flagged, 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`	Acretix 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 Link to this section

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 Link to this section

What each trust tier warrants
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 Link to this section

{
  "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 the jwks_uri in the envelope. 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 Link to this section

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 Link to this section

{
  "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.

For the full proof check, step by step, see Verify a proof.