Mind Chill
    Good Proof™by Mind Chill®
    HomeHow It WorksSectorsNewsMind Chill GuardiansPricing
    Book Sprint
    Mind Chill
    Good Proof™by Mind Chill®

    Contract-referenceable verification for high-impact AI actions. Scope-bound, expiry-aware, and human-final when it matters.

    Sales: [email protected]Security: [email protected]Support: [email protected]

    UK

    Mind Chill Nootropics Ltd

    09667911

    Singapore

    Mindchill Research Pte. Ltd.

    202544340Z

    A division of

    Mind Chill — Department of Human Defense

    Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.

    Product

    • Good Proof Stamp
    • Stamp Spec
    • IDA Evidence Pack
    • How It Works
    • Verify API
    • Guardians
    • Pricing

    Solutions

    • Sectors
    • Specimens
    • Verify a Stamp
    • AI GOLD
    • Trust Metrics
    • RegTech
    • Security Automation

    Safeguards

    • Kill Switch
    • Agentic Security
    • Clause Pack
    • Coverage Reports
    • Portability & Data Rights

    Company

    • Book a Stamp Sprint
    • Advocate Partners
    • Partner Program
    • News
    • Leadership
    • Trust & Security
    • Official Domains

    © 2026 Good Proof by Mind Chill. All rights reserved.

    PrivacyTermsCookiesSecurityContactFAQStatusOfficial

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

    Back to Specimens
    Open Hardware Finality SpecimenBook a Stamp Sprint
    Hardware Finality

    Hardware Finality (How buyers use it)

    Signed verification responses backed by non-exportable keys (HSM/TPM) where programmes require it.

    When "a URL said VALID" isn't enough, hardware finality makes reliance tamper-evident and independently verifiable.

    HSM/TPM
    NON-EXPORTABLE
    SIGNED RESPONSE
    FAIL-CLOSED

    What this is

    • •A signed verify response for a specific stamp_id at a specific time
    • •Signature produced by a programme-configured signing authority
    • •Where configured, signing keys are non-exportable (HSM/TPM)
    • •Used to support insurer/auditor reliance, regulated assurance, and high-value controls
    • •Designed for independent verification without access to your internal stack

    What this is not

    • •Not a certification of compliance
    • •Not a guarantee the underlying outcome is "correct"
    • •Not a raw data dump (no prompts/logs/PII by default)
    • •Not a replacement for Status Link (it complements it)

    When programmes ask for this

    • •High-value actions and irreversible controls (money movement, custody, bans, safety overrides)
    • •Regulated or insurer-driven assurance requirements
    • •Third-party audit sampling where tamper-evidence matters
    • •Counterparties who require cryptographic proof of what was verified
    • •Environments where "portal screenshots" or "trust our API" is not acceptable evidence

    Default lanes can use Status Link + IDA Pack. Hardware Finality is for programmes that require stronger reliance semantics.

    What ships

    Status Link (authoritative now)

    • •Live state: VALID / NEEDS_REFRESH / WITHDRAWN / EXPIRED / NOT_VERIFIED
    • •Fail-closed: unreachable = NOT VERIFIED

    IDA Evidence Pack (snapshot then)

    • •Time-stamped PDF snapshot for filing and disputes

    Hardware Finality (signed verify response)

    • •Signed assertion that a verify response was produced at time T
    • •Verifiable signature and key identity (programme-scoped)
    • •Optional hardware-backed non-exportable key semantics

    One Stamp can produce all three (programme-scoped).

    Specimen Preview

    Redacted example (format only). Values and fields vary by programme and lane.

    Signed Verify Response (Hardware-Backed)

    {
      "stamp_id": "GP-STAMP-2026-████",
      "status": "VALID",
      "verified_at": "████-██-██T██:██:██Z",
      "signer_authority": {
        "type": "HARDWARE_BACKED",
        "key_id": "gp-hsm-prod-████",
        "key_status": "ACTIVE",
        "attestation": "NON_EXPORTABLE"
      },
      "signature": {
        "alg": "ES256",
        "kid": "gp-hsm-prod-████",
        "sig": "████████████████████..."
      }
    }

    Excluded by default

    • Prompts / model inputs
    • Raw logs / traces
    • PII / sensitive payloads

    Programme-gated access available when required (auditable trail).

    How a counterparty verifies hardware finality

    1. 1Fetch signed verify response — via Verify API or delivered artifact
    2. 2Confirm key identity — kid / key_id matches the programme trust chain
    3. 3Verify signature — ES256 or configured algorithm
    4. 4Confirm stamp_id + verified_at + status — match the reliance event
    5. 5Apply decision rule

    Decision rule

    VALIDProceed within scope
    NEEDS REFRESHDo not rely until re-verified
    WITHDRAWNStop relying immediately
    NOT VERIFIEDTreat as unverified (fail-closed)

    Fail-closed rule

    If signature verification fails, key is unknown, response is malformed, or verification cannot be performed → treat as NOT VERIFIED.

    Programme trust chain (what's being relied on)

    • •Signing authority is programme-scoped — each programme defines its signing configuration
    • •Key material is non-exportable where configured (HSM/TPM) — private key never leaves hardware
    • •Key identity is referenced in the response (kid/key_id) — verifiable against published trust chain
    • •Rotation and revocation are supported (programme rules) — key lifecycle is managed
    • •Signature proves the verify response was produced by the configured authority at time T

    Where this gets used

    A

    Insurers / Underwriters

    Pain:

    Need audit-grade reliance proof for high-value controls

    What they do:

    Verify signed response, file it with risk record

    Output:

    Insurer-acceptable artifact

    B

    Auditors / Assurance

    Pain:

    Sampling requires tamper-evident verification evidence

    What they do:

    Verify signature + log verified_at and key identity

    Output:

    Auditable sampling record

    C

    Regulated counterparties

    Pain:

    Need independent verification without portal access

    What they do:

    Verify signed response + check Status Link for current state

    Output:

    Reliance they can defend

    D

    High-value ops controls

    Pain:

    "Who verified what, when" must be provable

    What they do:

    Attach signed verify response to the change ticket / runbook event

    Output:

    Change-control proof bundle

    What can go wrong (and how we fail closed)

    • Wrong domain / lookalike verifier → treat as NOT VERIFIED
    • Signature invalid → NOT VERIFIED
    • Unknown key identity → NOT VERIFIED
    • Response missing fields → NOT VERIFIED
    • Verify service unreachable → NOT VERIFIED
    • Status is NEEDS REFRESH / WITHDRAWN → stop relying

    Procurement-ready clause (template)

    "For high-assurance programmes, Provider shall supply a hardware-backed signed verify response for defined high-impact actions. Any failure to verify signature or key identity shall be treated as NOT VERIFIED. Actions with NOT VERIFIED, NEEDS REFRESH, or WITHDRAWN shall be treated as unverified."

    Not legal advice. Template language for legal review.

    FAQs

    High-assurance reliance. No portal access required.

    Hardware finality for programmes that need cryptographic proof of verification.

    Book a Stamp SprintBack to Specimens
    Status Link specimen →Verify API specimen →Stamp Spec →Evidence Vault →

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