ProblemIntegrity ModelIntegration FitPartner DemosClaims BoundaryPilot Request

Developer Docs

Developer Overview

Start at the main docs hub.

Verification Lifecycle

Artifact submission, receipts, and later comparison.

API Overview

Public request and response model.

Security Model

Claims boundary and public-safe controls.

Architecture

Workflow fit and trust-boundary framing.

Threat Model

Threat assumptions and review posture.

Request Pilot

Verification Lifecycle

This page shows the public verification lifecycle from artifact submission through signed verification receipts, later verification, and tamper detection.

Partner Engineers

Problem / Context

Verification should remain understandable during audit review, not only at the moment of initial submission.

The evaluator path focuses on workflows where artifact tampering, provenance loss, and stale evidence matter after collection.

Integrity Model

TrustSignal accepts a verification request, returns verification signals, issues signed verification receipts, and supports later verification.

Want the full technical evaluation path? Start with the repo-side evaluator entry point.
Start with verification

How It Works

The lifecycle stays explicit so downstream teams can store the receipt and re-run later verification when needed.

Verification Lifecycle

The active step progresses as you scroll so evaluators can read the full flow without losing the current lifecycle state.

Stage 1

Submit Artifact

The external workflow sends an artifact-derived verification request through the TrustSignal API boundary.

Stage 2

Verification Result

TrustSignal returns verification signals that summarize the verification outcome for downstream workflow logic.

Stage 3

Signed Receipt

The system issues a signed verification receipt that binds the verification outcome and verifiable provenance.

Stage 4

Store Receipt

The workflow stores the receipt with its own record so the system of record retains the integrity-layer output.

Stage 5

Later Verification

Before audit review or another high-trust step, the workflow can request later verification against stored receipt state.

Stage 6

Tamper Detection

If the artifact or stored state has drifted, later verification returns a mismatch signal instead of silently reusing the earlier result.

Example / Diagram

Start with the repo-side evaluator entry point for the problem framing, verification lifecycle, public API contract, example payloads, and security / claims boundary.

Example Request
curl -X POST "https://api.trustsignal.dev/api/v1/verify" \
  -H "Content-Type: application/json" \
  -H "x-api-key: $TRUSTSIGNAL_API_KEY" \
  --data @examples/verification-request.json
Example Response
{
  "receiptVersion": "2.0",
  "receiptId": "623e0b54-87b3-42b7-bc89-65fae0ad8d5e",
  "createdAt": "2026-03-12T15:24:01.000Z",
  "policyProfile": "CONTROL_CC_001",
  "inputsCommitment": "0x2dded9c1b5c4c6d91df58a1b1793cb527f2b0cf5ddaf447f5b7d9839f7ab7d01",
  "checks": [
    {
      "checkId": "registry.status",
      "status": "PASS",
      "details": "Source responded with a current record"
    }
  ],
  "decision": "ALLOW",
  "reasons": ["receipt issued"],
  "receiptHash": "0x4e7f2ce9d3f7a8d3b0e4c9f2aa17fd59d6b4fda2d7b7b7d1cce8124d7ee39d04"
}

receiptId

Unique receipt reference for retrieval, status checks, and lifecycle actions.

receiptHash

Stable hash of the canonical receipt payload used for later verification.

receiptSignature

Signed receipt metadata returned with the verification response.

inputsCommitment

Canonical commitment to the verified request inputs.

Production Considerations

Production environments should treat later verification as a distinct operational step before relying on an earlier result.

Use scoped authentication, environment-specific configuration, lifecycle monitoring, and explicit verification checks before relying on prior results.
Later Verification Status
{
  "verified": true,
  "integrityVerified": true,
  "signatureVerified": true,
  "signatureStatus": "verified",
  "proofVerified": false,
  "recomputedHash": "0x4e7f2ce9d3f7a8d3b0e4c9f2aa17fd59d6b4fda2d7b7b7d1cce8124d7ee39d04",
  "storedHash": "0x4e7f2ce9d3f7a8d3b0e4c9f2aa17fd59d6b4fda2d7b7b7d1cce8124d7ee39d04",
  "inputsCommitment": "0x2dded9c1b5c4c6d91df58a1b1793cb527f2b0cf5ddaf447f5b7d9839f7ab7d01",
  "receiptSignature": {
    "alg": "EdDSA",
    "kid": "trustsignal-current"
  },
  "revoked": false
}
Tamper Detection Example
{
  "verified": false,
  "integrityVerified": false,
  "signatureVerified": true,
  "signatureStatus": "verified",
  "recomputedHash": "0x7d02a6e4f5cbfd616cb50cbeeaec4d37c78f5fc0bd385b0ecff7af9afbd4ab11",
  "storedHash": "0x4e7f2ce9d3f7a8d3b0e4c9f2aa17fd59d6b4fda2d7b7b7d1cce8124d7ee39d04",
  "revoked": false,
  "error": "artifact_mismatch"
}

Security and Claims Boundary

This evaluator path is public-safe and intentionally excludes internal verification implementation details.

Later verification returns status and integrity signals, not internal proof-system detail, witness data, or signing infrastructure specifics.

Claims Boundary

  • • TrustSignal provides signed verification receipts.
  • • Returns verification signals and lifecycle status.
  • • Enables later verification of previously checked artifacts.
  • • Integrates with existing compliance workflows.

Not Provided

  • • Legal determinations
  • • Fraud guarantees
  • • Compliance certification
  • • Replacement for system-of-record platforms

Related Docs

APISecurity ModelArchitecture