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 action (a claim) against a policy: it captures the evidence you submitted, the policy verdict, the replay result, and an Ed25519 attestation, all in a hash-chained, independently verifiable record. By the end of this page you will have created one and confirmed its integrity.

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 confirm a receipt independently with POST /v1/verify — no API key needed. Submit the full receipt object as the request body. The fastest way is to capture the .receipt from the previous call and pipe it straight into verify.

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" }
  ]
}

Verification runs three families of checks: that the required fields are present, that the canonical hash recomputes and matches the ledger, and that the Ed25519 signature validates against the server's public key. The top-level valid field is true only when every check passes — any failure makes it false.

4. Verify offline (optional)

You do not have to call the API to trust a receipt. Fetch the server's Ed25519 public key once from GET /v1/keys/server and verify signatures yourself.

REQUEST

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

The response is the public key in PEM (text/plain) format. With it in hand you can validate the Ed25519 attestation on any receipt without contacting the server. 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