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.

Get API keyRequest Pilot

Developer Docs

Security Model

TrustSignal provides externally verifiable outputs while limiting public interfaces to an authenticated API boundary. Integrations can evaluate verification signals and receipt lifecycle state without exposing private verification engine internals.

Security reviewers and partner engineers

Security Controls in the Verification Lifecycle

The public surface is narrow by design so integrators can verify outcomes without needing internal engine access.

Step 1

Authenticate API client and scopes

Step 2

Submit verification request over TLS

Step 3

Receive signed verification receipt

Step 4

Check integrity status and verification signals

Public Security Controls

  • API authentication and scoped access for verification and lifecycle actions.
  • Signed verification receipts for durable integrity records.
  • Receipt lifecycle validation and status checks before downstream reliance.
  • Authorized revocation controls tied to lifecycle governance.
  • Rate limiting and abuse protection on public API boundaries.
  • Fail-closed behavior at the integration boundary when verification state is unavailable.

Verification Result Shape

Downstream systems should treat status and integrity checks as explicit decision inputs before relying on prior verification.

Receipt Verification Result
{
  "verified": true,
  "integrityVerified": true,
  "signatureVerified": true,
  "signatureStatus": "verified",
  "proofVerified": false,
  "proofNote": "Experimental ZKP proof verification pending",
  "recomputedHash": "0x4e7f2ce9d3f7a8d3b0e4c9f2aa17fd59d6b4fda2d7b7b7d1cce8124d7ee39d04",
  "storedHash": "0x4e7f2ce9d3f7a8d3b0e4c9f2aa17fd59d6b4fda2d7b7b7d1cce8124d7ee39d04",
  "inputsCommitment": "0x2dded9c1b5c4c6d91df58a1b1793cb527f2b0cf5ddaf447f5b7d9839f7ab7d01",
  "receiptSignature": {
    "alg": "EdDSA",
    "kid": "trustsignal-current"
  },
  "revoked": false
}

Intentionally Not Exposed

Public documentation does not disclose proof internals, circuit identifiers, witness data, signing infrastructure specifics, model internals, or internal service topology.

The public contract is designed to be verifier-friendly without revealing implementation details that would widen the attack surface.

Claims Boundary

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