START HERE

Quickstart

This guide takes you from zero to a cryptographically verified Decision Receipt in about five minutes. Every step uses a real, public endpoint on https://decrec.summitcognitive.ai — you can run the commands as written.

A Decision Receipt records the evaluation of an autonomous agent's proposed action (a claim) against a policy: it captures the submitted evidence, policy verdict, replay result, and an Ed25519 attestation. By the end of this page you will have created one and run the issuer-operated verification checks. Those checks do not prove source truth, execution, key ownership, or unsigned legacy chain position.

You need curl and, for readable output, jq. Nothing else.

1. Get an API key

Request a key by sending your email to POST /v1/signup. No authentication is required for this call.

REQUEST

curl -s https://decrec.summitcognitive.ai/v1/signup \
  -H "Content-Type: application/json" \
  -d '{"email": "dev@example.com"}' | jq .

RESPONSE

{
  "api_key": "sk_decrec_<uuid>",
  "message": "API key issued. Include as X-API-Key header on requests."
}

Keys follow the format sk_decrec_<uuid>. New signups start on the free tier, which allows 100 requests per hour on a one-hour sliding window. If the email already has a key, the existing key is returned rather than a new one.

Pass the key on every authenticated request via the X-API-Key header. It is also accepted as a Bearer token in the Authorization header (Authorization: Bearer sk_decrec_<your-key>), whichever is more convenient.

Note

Export the key into your shell so the remaining steps can reuse it: export API_KEY="sk_decrec_<your-key>".

2. Submit a claim for evaluation

Send a claim to POST /v1/evaluate. At minimum you provide a claim_id, an entity, a human-readable claim, and at least one evidence source. The example below supplies two sources, which is enough to satisfy a typical two-source policy.

REQUEST

curl -s https://decrec.summitcognitive.ai/v1/evaluate \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $API_KEY" \
  -d '{
    "claim_id": "demo-claim-001",
    "entity": "acme-corp/widget-api",
    "claim": "PR #42: Add input validation",
    "sources": [
      {
        "id": "evd_test_1",
        "type": "test_result",
        "uri": "https://github.com/acme-corp/widget-api/actions/runs/99",
        "confidence": 0.9,
        "content": "All tests passing"
      },
      {
        "id": "evd_review_1",
        "type": "code_review",
        "uri": "https://github.com/acme-corp/widget-api/pull/42",
        "confidence": 0.85,
        "content": "Approved by two reviewers"
      }
    ]
  }' | jq .

The response is a single object with several parts. The fields you care about first:

policy.verdict — the decision: ALLOWED, BLOCKED, or ESCALATED, with a reason and the list of rules that were checked.
receipt — the signed record itself, including receipt.admissibility.status (ACCEPTED, NON_DETERMINISTIC, or REJECTED), the evidence summary, the replay result, the Ed25519 attestations, and the chain position that links this receipt to the previous one.

The three possible verdicts:

ALLOWED BLOCKED ESCALATED

RESPONSE (abridged)

{
  "policy": {
    "verdict": "ALLOWED",
    "reason": "All policy checks passed",
    "rules": [
      { "rule": "min_sources", "passed": true, "reason": "2 sources >= 2 required" },
      { "rule": "min_source_types", "passed": true, "reason": "2 types >= 2 required" }
    ]
  },
  "replay": { "passed": true, "replay_hash": "sha256:..." },
  "receipt": {
    "receipt_id": "dr-...",
    "admissibility": { "status": "ACCEPTED" },
    "evidence": {
      "inputs_hash": "sha256:...",
      "source_count": 2,
      "source_types": ["test_result", "code_review"]
    },
    "replay": { "deterministic": true, "replay_hash": "sha256:..." },
    "attestations": [
      {
        "signer": "decrec-server",
        "algorithm": "Ed25519",
        "signature": "base64-encoded-signature...",
        "timestamp": "2026-05-30T10:35:00.000Z"
      }
    ],
    "chain": { "sequence": 1, "previous_receipt_hash": null }
  }
}

Note

You can tune the policy per request with an optional policyConfig object (for example minSources, minConfidence, or requireHumanApproval). See the API reference for the full field list.

3. Verify the receipt

Anyone can request the issuer-operated POST /v1/verify checks without an API key. This is convenient, not independent: the same service operates issuance, ledger lookup, and verification. Submit the full receipt object as the request body.

REQUEST

# Save just the receipt from an evaluate call
curl -s https://decrec.summitcognitive.ai/v1/evaluate \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $API_KEY" \
  -d @claim.json | jq '.receipt' > receipt.json

# Verify it
curl -s https://decrec.summitcognitive.ai/v1/verify \
  -H "Content-Type: application/json" \
  -d @receipt.json | jq .

RESPONSE

{
  "valid": true,
  "receipt_id": "dr-...",
  "admissibility": "ACCEPTED",
  "verification_depth": "cryptographic",
  "checks": [
    { "name": "hash_integrity", "status": "PASS", "detail": "Hash abc123... matches ledger" },
    { "name": "signature_valid", "status": "PASS", "detail": "Ed25519 verified" }
  ]
}

The endpoint reports field-presence, service-side commitment consistency, and signature checks. The top-level valid field is true only when its named checks pass. Treat the result within that printed scope; use the verification guide for independent key pinning and current offline-verifier limitations.

4. Verify offline (optional)

You do not have to call the API to run the receipt's signature check. Obtain the server's Ed25519 public key, authenticate its fingerprint through a trust channel separate from the receipt service, and pin that authenticated key before relying on an offline result. A key fetched from the same service as the receipt does not establish signer identity by itself.

REQUEST

curl -s https://decrec.summitcognitive.ai/v1/keys/server > server-key.pem

The response is the public key in PEM (text/plain) format. After separately authenticating and pinning that key, you can validate the Ed25519 attestation's defined signed content without contacting the server. That result does not authenticate unsigned receipt fields, action execution, or issuance completeness. For the full offline procedure, see the Verifying receipts guide.

Where to go next

That is the whole loop: sign up, evaluate a claim, and verify the receipt it produces. From here, read the full API reference for every endpoint, field, header, and status code, or try requests interactively in the live playground.

← PreviousOverview Next →FAQ