VERIFICATION RAILVerify API: verification at scale.
Signed, fail-closed verification for high-impact actions. Partners, auditors, procurement, and internal teams can verify by Stamp ID without accessing your systems.
VALID
→ proceed within scope
NEEDS REFRESH
→ block until re-verified
WITHDRAWN
→ stop relying
NOT VERIFIED
→ fail-closed (timeout/unreachable)
Fail-closed
Minimal disclosure
Append-only history
Response includes status (VALID / NEEDS REFRESH / WITHDRAWN / NOT VERIFIED), scope, expiry, verified_at, signer, verify_url. Evidence stays excluded by default.
Breaking
EUEU AI Act enforcement begins — high-risk AI systems now require conformity assessments (Feb 2025)│
UKUK publishes AI Safety Institute guidance on frontier model evaluations│
USANIST AI 600-1 released — GenAI risk profiles now standardised│
APACSingapore MAS issues advisory on AI-driven financial decision accountability│
AFRICASouth Africa POPIA enforcement targets automated decision-making systems│
MIDDLE EASTUAE ADGM publishes responsible AI framework for financial services│EUEU AI Act enforcement begins — high-risk AI systems now require conformity assessments (Feb 2025)│UKUK publishes AI Safety Institute guidance on frontier model evaluations│USANIST AI 600-1 released — GenAI risk profiles now standardised│APACSingapore MAS issues advisory on AI-driven financial decision accountability│AFRICASouth Africa POPIA enforcement targets automated decision-making systems│MIDDLE EASTUAE ADGM publishes responsible AI framework for financial services│Status lookups
Query a Stamp ID and receive current status, scope boundaries, expiry, and signer reference.
Webhooks
Subscribe to NEEDS REFRESH / WITHDRAWN events so downstream systems block or escalate automatically.
Access requests
Programme gated access requests with auditable trails for lanes that require deeper verification.
Drop in verification where decisions ship.
Standard REST with scoped authentication. Built for gates, partner portals, ticketing, audits, and procurement workflows.
Fast online lookups with signed responses available
Fail-closed semantics for automation safety
Programme-scoped access controls
Audit-ready logs for lookups and access requests
Enterprise SLA options
const response = await fetch(
"https://verify.goodproof.mindchill.ai/api/verify/stamp/h4qd9wb9spyw",
{ headers: { Accept: "application/ld+json" } }
);
const result = await response.json();
// {
// "@context": ["https://schema.org", "https://goodproof.mindchill.ai/vocab/v1"],
// "@type": ["Certificate", "mindchill:GoodProofArtifact"],
// "@id": "https://verify.goodproof.mindchill.ai/verify/stamp/h4qd9wb9spyw",
// "mindchill:artifactTier": "stamp",
// "mindchill:verifyToken": "h4qd9wb9spyw",
// "mindchill:vocabularyVersion": "v1",
// "mindchill:verificationStatus": "verified"
// // additional fields when verified: scopeSummary, expiresAt, verifiedAt, signer
// }
if (result["mindchill:verificationStatus"] === "verified") {
// proceed within scope
} else {
// block or escalate (fail-closed)
}Want to see it in action?
Watch a real gate check, try a prompt injection attack, and see why it fails.
See How It WorksCommon flows
Gate a high impact action
System checks status before execution. If not VALID, block or escalate.
Counterparty verification
Partners verify by Stamp ID and link without needing accounts by default.
Audit sampling
Audit teams sample decisions and validate history using signer, scope, and timestamps.
Trust primitives
Signed responses (programme-scoped)
Append-only version history
Fail-closed when unreachable
Self-contained Evidence Pack hash chain (downloadable per stamp)
Optional anchoring to Good Proof LIVE Ledger
Signed responses are programme scoped and can be verified cryptographically by authorised verifiers.
Technical specifications
Standards and interfaces for integration, interoperability, and audit confidence.
Common Evidence Schema (CES) (planned)
Purpose
Planned normalized structure for evidence regardless of source. Will enable consistent processing across standalone and integrated modes.
Inputs / Outputs
Input: Raw evidence from issuer or external engine.Output: status, scope, scope_hash, signer, expires_at, evidence_window, trace_ref.
Why buyers care
Portability across systems. Auditors see consistent fields. No vendor lock-in on evidence format.
Adapter Interface Spec (AIS) (planned)
Purpose
Planned stable contract for integrating external runtime accountability engines. Engines will push evidence; Good Proof normalizes and verifies.
Inputs / Outputs
Input: Engine-specific evidence payload + adapter config.Output: CES-normalized evidence with provenance metadata.
Why buyers care
Integrate existing accountability infrastructure without rip-and-replace. Evidence from multiple engines in one verification layer.
Signature normalization
Purpose
Canonical serialization before signing ensures signatures are verifiable across implementations and time.
Inputs / Outputs
Input: Evidence object with arbitrary field order.Output: Deterministic byte sequence + programme-scoped signature.
Why buyers care
Signatures remain valid for audit and dispute resolution years later. Independent verifiers can validate without contacting Good Proof.
Replay protection and webhook signing
Purpose
Prevent replay attacks on verification requests and webhook deliveries. Request correlation and clock-skew limits enforced.
Inputs / Outputs
Input: request_id, timestamp, max_clock_skew config.Output: Signed webhook payload with nonce and expiry.
Why buyers care
Automated gates cannot be fooled by replayed old VALID responses. Incident investigators can trace request lineage.
Conformance test suite (planned)
Purpose
Planned suite to verify that integrated engines and buyer implementations conform to CES, AIS, and fail-closed semantics before production reliance.
Inputs / Outputs
Input: Adapter config + test evidence set.Output: Pass/fail report with specific conformance violations.
Why buyers care
Confidence before go-live. Auditors can reference conformance reports. Reduces integration risk and support burden.
Deployment modes
Good Proof can run standalone or ingest evidence from external runtime accountability engines.
S
Standalone mode
Good Proof is your primary verification layer. Evidence is issued, managed, and verified entirely within Good Proof infrastructure.
- No external dependencies to start
- Full control over evidence lifecycle
- Expand to integrated mode later without migration
I
Integrated mode
Good Proof ingests evidence from external runtime accountability engines via the Adapter Interface. Evidence is normalized to CES before verification.
- Leverage existing accountability infrastructure
- Conformance tests verify consistency
- Multi-engine evidence in unified verification layer
Privacy
Minimal disclosure by default
Programme gated access when required
Auditable access trails
See the Privacy model accordion above for full details on layered disclosure and access grants.
Frequently asked questions
Request API Access
Start with one lane. Wire verification into gates and partner checks. Expand once counterparties rely on the Status Link.
Not a certification. Scope limited verification. Acceptance depends on counterparty or programme requirements.