GUIDE

GitHub integration

Wire the Decision Receipt API into your GitHub workflow so that pull-request merges produce signed receipts. You have two paths: point a GitHub webhook at the inbound receiver and let it auto-evaluate PRs, or call POST /v1/evaluate yourself from a GitHub Actions job where you control exactly what evidence goes in.

Both paths produce the same artifact: an Ed25519-attested Decision Receipt recording the evidence, the policy result, the replay result, and the attestation. This guide covers wiring, reading results back, and posting verdicts to the PR. It documents API behavior only — the exact GitHub App installation screens are configured per account, so treat the steps below as the contract you build against, not a fixed UI.

Path A: the inbound webhook receiver

The fastest way to start is to point a GitHub webhook at the receiver. It auto-evaluates pull requests as they arrive.

Configure a webhook in your repository (or org) settings to deliver pull-request events to this endpoint. The receiver authenticates each delivery by signature: a request with a missing or invalid webhook signature returns 401 Unauthorized, the same status the API uses for a missing or invalid API key. Configure the shared secret on both sides so deliveries verify.

Path B: evaluate from a GitHub Actions job

When you want to choose precisely which evidence is admitted — CI results, code review state, test results — call POST /v1/evaluate from a CI step. This is the manual path, and it gives you full control over the action object and the sources array.

For a merge, set the action's action_type to merge and target_system to github, then fill in the GitHub coordinates: repository, pull_request, commit, and branch. Attribute the actor with agent, agent_model, and the responsible human_operator. Build the sources from whatever your pipeline already knows — a ci source for the run, a code_review source for the approval, a test_result source for the suite.

Authenticate with your API key in the X-API-Key header. The following drops into a CI step (the example assumes API_KEY and the usual GitHub Actions context values are available as environment variables):

CI STEP

curl -s https://decrec.summitcognitive.ai/v1/evaluate \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $API_KEY" \
  -d '{
    "claim_id": "merge-acme-widget-api-42",
    "entity": "acme-corp/widget-api",
    "claim": "PR #42: Add rate limiting to /api/orders",
    "expected_replay_match": true,
    "action": {
      "action_type": "merge",
      "target_system": "github",
      "repository": "acme-corp/widget-api",
      "pull_request": 42,
      "commit": "abc1234def5678",
      "branch": "feat/rate-limit",
      "agent": "claude-code",
      "agent_model": "claude-sonnet-4-20250514",
      "human_operator": "jdoe"
    },
    "sources": [
      {
        "id": "evd_ci_42",
        "type": "ci",
        "uri": "https://github.com/acme-corp/widget-api/actions/runs/123",
        "confidence": 0.9,
        "content": "All 47 tests passing, 0 failures"
      },
      {
        "id": "evd_review_42",
        "type": "code_review",
        "uri": "https://github.com/acme-corp/widget-api/pull/42#pullrequestreview-1",
        "confidence": 0.85,
        "content": "Approved by senior engineer with no blocking comments"
      },
      {
        "id": "evd_test_42",
        "type": "test_result",
        "uri": "https://github.com/acme-corp/widget-api/actions/runs/123",
        "confidence": 0.92,
        "content": "Integration suite green on merge commit"
      }
    ]
  }' | jq .

The response carries a policy.verdict of ALLOWED, ESCALATED, or BLOCKED, and a signed receipt with an admissibility.status of ACCEPTED, NON_DETERMINISTIC, or REJECTED. Persist or gate on the verdict as your policy requires.

Posting the verdict back: outbound webhooks

To act on a receipt the moment it is created — comment on the PR, post to a channel, gate a deploy — register an outbound webhook for receipt.created events.

Register a receiver once; from then on each new receipt is delivered to your endpoint. A small relay can read the verdict and admissibility status off the payload and post a comment on the originating pull request, or fan it out to your team's chat.

Reading results

Several read endpoints turn the receipt ledger into something you can dashboard or query from CI.

The diff view is the one most worth wiring into review: it shows whether a PR that was once ESCALATED became ALLOWED after the contributor added tests or secured an approval, with each push leaving its own receipt in the chain.

Every receipt remains independently verifiable. Anyone holding a receipt can confirm its signature and hash with POST /v1/verify, or check it offline against the server's published Ed25519 public key from GET /v1/keys/server — no access to your CI or your API key required.