HomeStamp Spec

Technical reference — the schema that ships.

Book a Stamp Sprint →

Technical Reference

Good Proof Stamp Specification

The schema, fields, and semantics that make a Stamp contract-referenceable, machine-checkable, and dispute-ready.

Fail-closedMinimal disclosureAppend-only history

Book a Stamp Sprint View Specimens

Reliance Rule

Rely only if status = VALID. Anything else = block / escalate / stop rely.

Fail-closed: unreachable = NOT VERIFIED

Minimal disclosure: no prompts/logs/PII by default

Default Verify Fields

Every Status Link response includes the 13 binding fields the Stamp cryptographically commits to, plus a transport envelope of response metadata. Additional programme-scoped fields may be available.

Good Proof proves whether a high-impact action was authorised, scoped, evidenced, current, revocable, and safe enough to rely on at the point of consequence. Below is the schema that makes that machine-checkable.

13 binding fields — what the Stamp commits to

action_classCategory of high-impact action this Stamp authorisestool_execution:high_impact

scope_summaryBoundaries — what is in scope and what is nothardship_determination

policy_versionPolicy version at issuance; changes trigger NEEDS_REFRESH2026.01.19.1

workflow_hashHash of workflow definition (or prompt template, for AI lanes)sha256:9f86d0...

model_versionModel snapshot bound at issuance (AI-assisted lanes)claude-opus-4-7@2026-01-15

tool_permission_manifestFull tool + permission set the action class is authorised to usemanifest_v3:tools=[a,b,c]

evidence_pack_hashHash of the IDA Evidence Pack snapshot bound to this Stampsha256:7f3a...

signer_referenceProgramme-scoped signing authority (HSM key or Guardian panel)policy_signer_v3

verification_modeAuto-stamp, Guardian-sealed, or hybridguardian_sealed

expiryISO 8601 validity window end2026-06-15T00:00:00Z

revocation_statusLive, revoked, or pending withdrawal (append-only)live

escalation_ruleWhat happens when status is not VALID — block, escalate, fail-closedblock_and_route_to_guardian

jurisdiction_scopeProgramme / regulatory regime defining acceptance criteriauk:fca:programme_x

response envelope (transport)

stamp_idUnique identifier (e.g., GP-2026-0142-XK9)GP-2026-0142-XK9

statusCurrent validity stateVALID | NEEDS_REFRESH | WITHDRAWN | EXPIRED | NOT_VERIFIED

verified_atIssuer's last verification timestamp2026-01-19T14:32:00Z

versionAppend-only version number2026.01.19.1

verify_urlCanonical verification endpointverify.goodproof.mindchill.ai/GP-2026-0142-XK9

official_verifierCanonical domain for anti-spoofingverify.goodproof.mindchill.ai

Excluded by default: prompts, logs, PII, internal identifiers. Programme-gated access available for authorised verifiers.

verified_at vs checked_at

verified_at = when Good Proof last verified the decision (issuer timestamp). checked_at = when you checked the Status Link (your system's clock). Both matter for audit trails.

Minimum Logging Requirements

Store these fields with each verification event to enable audit reconstruction.

Field	Purpose	Required
`stamp_id`	Unique identifier for the stamp	Yes
`checked_at`	Timestamp when your system performed verification	Yes
`status`	Result of verification check	Yes
`scope_version`	Version of scope at check time	Yes
`scope_hash`	Integrity hash of scope definition	Recommended
`expires_at`	Expiry timestamp at check time	Yes
`signer`	Authority reference	Recommended
`verifier_domain`	Domain that returned the response	Recommended
`signature_present`	Whether response was signed	Programme-scoped

Logging recommendation: Store these fields for every verification event. This enables audit reconstruction without requiring Good Proof access.

Canonical Domain + Anti-Spoofing

Official verifier domain

verify.goodproof.mindchill.ai

If the domain does not match, treat as NOT VERIFIED.

Don't trust links. Type mindchill.ai/official to verify.

Counterparties may verify TLS certificate + issuer per security policy.

Status Semantics

VALID

Valid within scope under lane rules. Proceed.

Execute within scope boundaries.

NEEDS REFRESH

Evidence window expired or material-change trigger fired.

Re-verify before relying. Do not assume validity.

WITHDRAWN

Current validity revoked. Stop relying immediately.

Block execution. History remains append-only.

NOT VERIFIED

Treat as unverified. Also returned on fail-closed (unreachable, timeout, error).

Block or escalate. Never assume validity.

Machine token → UI label: NEEDS_REFRESH → "NEEDS REFRESH" ·NOT_VERIFIED → "NOT VERIFIED"

Fail-closed rule: If verification cannot be performed (network unreachable, timeout, error), the response is NOT_VERIFIED. Systems should block or escalate—never assume validity.

if (status !== "VALID") { block(); }

Status Link vs IDA Evidence Pack

Status Link

Authoritative now
Live validity check
For contracts, gates, automation
Changes with status transitions

IDA Evidence Pack

Defensible then
Time-stamped snapshot
For filing, disputes, audit
Frozen at issuance

PDFs are great for filing. Status Links keep them current.

HTTP + Error Handling + Caching

Error handling rules

• Timeout (>5s default) → NOT VERIFIED
• HTTP 4xx/5xx → NOT VERIFIED
• Network unreachable → NOT VERIFIED
• Malformed response → NOT VERIFIED

Caching guidance

• Do not cache VALID beyond programme-defined TTL
• Never cache NOT VERIFIED, NEEDS REFRESH, or WITHDRAWN
• Always re-verify before high-impact execution

Response codes

`200`	Success — parse status field
`404`	Stamp not found → NOT VERIFIED
`429`	Rate limited → retry with backoff
`5xx`	Server error → NOT VERIFIED

Material Change Triggers

When any of these occur, the Stamp status transitions to NEEDS REFRESH until re-verified.

Model version change (for AI-assisted lanes)

Policy version change

Scope boundary modification

Signing authority rotation

Security incident detection

Regulatory requirement change

Counterparty status change

Evidence Windows

Time-bounded validity

Every Stamp has an expires_at field. After expiry, status becomes NEEDS REFRESH automatically.

Append-only history

Withdrawal changes current validity but does not erase history. The audit trail remains for disputes, regulators, and counterparty review.

Scope hash integrity

scope_hash allows integrity verification without exposing sensitive scope details.

Procurement-Ready Contract Clause

Template clause

"For any defined high-impact action, Provider shall obtain and maintain a Good Proof Stamp with an active Status Link. Actions taken with a status of NOT VERIFIED, NEEDS REFRESH, or WITHDRAWN shall be treated as unverified."

Not legal advice. Template language for legal review.

Issuer & Signer Model

Issuer (Good Proof)

Operates the verification infrastructure, maintains the Status Link, and enforces programme rules.

Signer (Programme-scoped)

The authority that signs the verification decision. Can be automated (policy engine) or human (Guardian).

Build vs Buy

You could build a status endpoint. But a Good Proof Stamp is more than an endpoint—it's a portable proof object + operating system:

•Contract-ready clauses and verification workflow
•Versioned semantics with append-only history
•Auditable access and dispute operations
•Guardian infrastructure (when human finality is required)

Building the endpoint is 10% of the work; operating defensible verification is the rest.

Ready to implement?

Book a Stamp Sprint View Specimens

Specimens are redacted, format-only exemplars. Not client data. Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.