Protocols & Rails — Compute Integrity
Integrity gates that stay authorised even after everything changes.
No Stamp → No Ship for defined integrity-gated lanes.
When AI drives gates in production, integrity is a liability surface. If reliability claims can't travel, procurement re-audits everything. Partners can't rely on your approval. Insurers can't underwrite on your word.
- Stamp the operating envelope: thresholds, method, version, owner
- NEEDS_REFRESH when any boundary changes (no silent drift)
- WITHDRAWN when compromise or invalidation is declared (stop relying)
- Counterparties verify without logging into your perimeter
Fail-closed•Append-only•Scope-bounded
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.
Why compute integrity buyers are moving now
Silent drift, stale approvals, and non-portable evidence are converging into procurement and liability risk.
Drift detected, but counterparties still rely on stale approvals
Runtime/hardware/driver updates silently change the integrity envelope. Prior approvals circulate without reflecting current state.
Incident response lacks portable stop-rely proof
When compromise or invalidation is declared, there is no machine-checkable way to propagate stop-rely across all relying parties.
Procurement and audit rework from non-portable evidence
Screenshots and internal dashboards don't travel. Every counterparty re-audits because they can't verify what was approved.
Insurers require defensible reliance state
Coverage and underwriting require evidence that travels outside your perimeter — not portal access or narrative summaries.
External reviewers need verification without portal access
Auditors, partners, and regulators need to check validity without VPN, NDA, or system integration.
Version/method disputes consume engineering + legal time
When method, threshold, or runtime version changes, proving what was authorised at decision time is manual archaeology.
Good Proof provides scope-limited verification evidence and stop-rely semantics. It is not a certification.
What a Stamp proves (and what it doesn't)
Proves (within lane scope)
- Action class + outcome
- Decision/execution timestamp
- Signer/authority reference
- Scope boundaries + expiry window
- Validity state (VALID / NEEDS_REFRESH / WITHDRAWN / NOT_VERIFIED)
- Evidence window for disputes/audit
Does NOT prove
- Reliability/performance correctness
- Underlying model truth
- Outcome accuracy or safety guarantee
- Raw telemetry/logs/PII by default
- Certification or regulatory compliance
In disputes: Status Link = reliance state now. IDA Evidence Pack = fileable snapshot for decision-time record.
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.
Why this lane exists
Integrity is a reliance boundary, not a dashboard. The risk is silent drift + stale approvals.
Disputes are reliance disputes
Not "what did metrics show?" but "what was authorised, under which method/version/thresholds, and is reliance still valid now?"
Logs are not execution control
Good Proof turns integrity gates into contract-referenceable controls: machine-checkable, scope-bound, expiry-aware, and revocable by link.
Proof that travels
If reliability claims can't travel, procurement re-audits everything. Partners can't rely on your approval.
Reliability evidence vs permission to rely
What reliability evidence portability gives
- Reusable evidence context
- Faster review handoffs
- Lower repeat evidence collection
What Good Proof adds
- Execution-time authorisation gate
- WITHDRAWN stop-rely propagation
- Dispute-ready IDA snapshot
Portable reliability evidence does not equal permission to rely.
Execution and continued reliance require VALID Status Link in scope.
Operating Envelope
The compute integrity surface
What must be defined and stamped before execution/reliance can proceed.
Model artifact identifier/hash + version
Inference runtime/engine version (framework/compiler/adapters)
Hardware/accelerator class + firmware/driver/microcode boundary
Precision/quantization/settings envelope
Method/eval definition + threshold set + safety triggers
Policy/rule pack identifiers + owner authority
Environment scope (site/region/tenant/workload class)
Evidence window + expiry
Material surface change → NEEDS_REFRESH
Compromise/invalidation/integrity failure → WITHDRAWN
What gets stamped
Integrity-gated action classes (define per programme):
Production
- Promotion to production under defined envelope
- Threshold/safety envelope overrides
Operations
- Safe-stop / throttle / rollback authorisations
- Temporary exception approvals with expiry
Incident
- Incident closure outcomes + reliance restarts
- Cross-hardware migration approvals
Change
- Runtime/driver/toolchain changes affecting integrity envelope
- Red-team / eval outcomes that must remain current for reliance
Integration in 3 touchpoints
1
Issue
At envelope approval/change → require a Stamp.
2
Communicate
Include Status Link in counterparty communications, runbooks, tickets, procurement packets.
3
Rely
At integrity-gated execution/reliance → verify Status Link (fail-closed).
High-impact gating only. Everything else runs normally.
Live status + fail-closed enforcement
VALID
Proceed/rely within scope.
NEEDS_REFRESH
Re-verify before relying.
WITHDRAWN
Stop-rely immediately.
NOT VERIFIED
Unverified / fail-closed.
If it's not VALID, the action does not execute.
Fail-closed: unreachable verification returns NOT_VERIFIED.
Block or escalate, never assume validity.
VALID means valid within scope, not guaranteed correctness.
When status changes — and what it means
Status triggers define when a Status Link moves to NEEDS_REFRESH or WITHDRAWN.
NEEDS_REFRESH
When any of these occur, re-verify before you rely.
Method/version definition changed
Threshold or safety envelope updated
Model retrain or capability boundary change affecting assumptions
Runtime/engine/compiler/adapter change
Hardware/driver/firmware/microcode change
Data pipeline shift affecting integrity interpretation
Policy/rule-pack update
Evidence window expiry
New deployment surface (region/site/hardware class)
Related incident declares posture change requiring refresh
NEEDS_REFRESH means "re-verify before you rely," not "defer."
WITHDRAWN
Stop-rely signal. Execution must not proceed.
Confirmed integrity breach or signing/key compromise
Critical misconfiguration (wrong tenant/workspace/scope)
Catastrophic drift/collapse requiring stop-rely
Unauthorised boundary expansion detected
Incident declares boundary untrustworthy pending investigation
Regulatory/legal stop order
Fail-closed: Wherever the Status Link is checked, if WITHDRAWN → block or escalate.
How it works in integrity-gated execution
1
Stamp the operating envelope
Method + thresholds + version + owner + expiry.
2
Gate integrity-relevant execution/reliance
Pre-execution/pre-reliance Status Link check at defined high-impact gates.
If not VALID → block or escalate. This is No Stamp → No Ship for integrity gates.
3
Revoke fast when risk changes
Set WITHDRAWN on compromise/invalidation; stop-rely propagates wherever checked.
Make the gate machine-checkable, not meeting-checkable.
Example: integrity-gated inference
1. Check Status Link for method + version + thresholds + owner
VALID → execute
NEEDS_REFRESH → re-verify envelope before execution
WITHDRAWN / NOT_VERIFIED → block + incident path
Two artefacts, one standard
Status Link (authoritative now)
A counterparty-verifiable link that returns current validity within scope.
- Returns: status, scope, expiry, verified_at, signer, verify_url
- Fail-closed: unreachable = NOT_VERIFIED
- Built for contracts, runbooks, tickets, and automated gates
IDA Evidence Pack (snapshot then)
View full details →A time-stamped snapshot you can forward, file, and cite.
- Append-only history; withdrawal ≠ erasure
- Minimal disclosure by default; programme-gated access when required
- Built for committees, audits, disputes, and procurement
One Stamp produces both. PDFs are great for filing. Status Links keep them current.
What's inside the IDA Evidence Pack
Programme-configured. Minimal disclosure by default.
Decision summary + lane scope boundary
Decision-time timestamp + evidence window
Method/version identifiers + threshold references
Integrity envelope boundary definitions
Signer/authority reference
Verification transcript + timestamps
Redaction matrix (what is intentionally excluded)
Proof ≠ payloads. Raw telemetry/logs/PII are not required by default.
What counterparties can verify
No login. No portal. Just a link that fails closed.
Live validity state: VALID / NEEDS_REFRESH / WITHDRAWN / NOT_VERIFIED
Scope boundaries + thresholds + expiry window
Signer authority reference (system or Guardian panel)
verified_at timestamp
Forwardable IDA Evidence Pack
Optional signed verify responses (programme-scoped)
Optional Good Proof LIVE Ledger anchoring (high-assurance programmes)
Who uses this in Compute Integrity
Buyers with high-impact integrity accountability and external reliance chains.
Platform / ML Ops
Pain: Silent drift breaks reliance — monitoring shows drift, but procurement and partners still rely on stale approvals.
Outcome: Refresh triggers enforce re-approval. No silent drift allowed.
Book a Compute Integrity SprintInfrastructure / SRE / Runtime Engineering
Pain: Hardware/driver/runtime changes invalidate integrity assumptions without notifying downstream reliers.
Outcome: Material surface change triggers NEEDS_REFRESH; counterparties see updated state instantly.
Book a Compute Integrity SprintSecurity / Risk
Pain: Integrity incidents create liability gaps — proving what was authorised at decision time is a scramble.
Outcome: WITHDRAWN stops reliance fast. IDA snapshot is fileable for incident review.
Book a Compute Integrity SprintProcurement / Audit / Vendor Risk
Pain: Proof doesn't travel — every counterparty re-audits because they can't verify what you approved.
Outcome: Counterparty verification by link. Portable proof without portal access.
Book a Compute Integrity SprintInsurers / External Assessors
Pain: Need defensible reliance story — coverage and underwriting require evidence that travels.
Outcome: IDA snapshot is fileable/citable. Status Link is live and machine-checkable.
Book a Compute Integrity SprintLegal / Disputes / Incident Response
Pain: Version/method disputes require proving what was authorised without handing over internal stack.
Outcome: Scope-bounded verification with append-only history. Minimal disclosure by default.
Book a Compute Integrity SprintEnterprise Buyers / Regulated Customers
Pain: Third-party reliance on compute integrity lacks portable, revocable evidence.
Outcome: Status-linked verification with withdrawal propagation for regulated reliance chains.
Book a Compute Integrity SprintWhere budget comes from
Usually funded from existing risk and operations lines, not new category spend.
Incident response + reliability engineering
Trigger: Integrity breach, drift event, or post-incident reliance restart
Why it fits: Portable stop-rely + reliance restart evidence reduces response time and cross-party coordination.
Model risk governance / AI assurance
Trigger: Model retrain, capability boundary change, or eval threshold update
Why it fits: Scope-bounded verification makes method/version changes auditable and revocable.
Third-party / vendor assurance
Trigger: Counterparty audit, partner reliance review, or procurement challenge
Why it fits: Counterparty-verifiable Status Link replaces repeated portal-access requests.
Audit readiness and evidence operations
Trigger: Regulatory review, internal audit programme, or inspection preparation
Why it fits: Append-only Evidence Pack snapshots with redaction matrix for review workflows.
Legal defensibility / dispute operations
Trigger: Version/method dispute, liability challenge, or incident review
Why it fits: Decision-time snapshot + live status make authorisation history defensible.
Underwriting / insurance evidence
Trigger: Coverage review, renewal, or incident-triggered underwriting reassessment
Why it fits: Status-linked evidence travels to insurers without internal system exposure.
Procurement friction reduction
Trigger: Recurring re-audit requests, non-portable approval evidence, or supply chain scrutiny
Why it fits: Portable verification reduces repeated audit cycles and evidence collection.
Start with one integrity-gated lane and prove audit/procurement friction reduction before expansion.
AI-Agent Era
AI-agent era controls
Prompts can drift. Reliance controls must not.
Material change in method/tool/vendor/configNEEDS_REFRESH
Integrity or boundary breachWITHDRAWN
Timeout/unreachable verification routeNOT_VERIFIED (fail-closed)
Exception lane requiring human finalityGuardian path (optional)
Good Proof does not decide outcomes; it controls whether high-impact actions are safe to rely on.
Global Coverage
Regulatory reality
No hype, no compliance claims — portable proof that survives cross-border review.
EU
AI Act + operational resilience requirements; traceability and controllability expectations for high-risk systems.
UK
AI governance frameworks + operational resilience accountability; record-keeping defensibility.
US
NIST AI RMF + platform/firmware integrity guidance; emerging state-level AI accountability.
Canada
AI governance expectations + third-party risk; defensible record-keeping for automated decisions.
Australia
AI ethics principles + operational risk; defensible records for high-impact automated decisions.
Asia
Governance frameworks emphasise traceability, controllability, and bounded risk for AI-driven systems.
Middle East
AI governance and digital infrastructure expectations expanding; defensible records for cross-border reliance.
Africa
Digital infrastructure governance strengthening across regional bodies; portable verification supports cross-border reliance.
Good Proof doesn't certify compliance. It makes integrity-gated execution verifiable, refreshable, and withdrawable by link.
Jurisdictional Configuration
Country overlays can be configured per programme
Configure scope boundaries, evidence windows, redaction matrix, verifier checklist, disclosure/retention/appeal handling, language support, and verifier-access requirements per jurisdiction.
Not legal advice. Final legal mapping is owned by programme counsel.
A Global Human Layer
Our Mind Chill Guardian Story
A global human layer that software can't fake.
When liability lands on a person, the sign-off should too.
Conflict-checked · Rotation-based · Audit-traceable · Programme-scoped
When Guardians are used (only when required)
Most decisions remain automated. Humans step in only where human finality is required: disputed incident closures, high-risk overrides, contested withdrawals, or edge cases where liability lands on people.
Mind Chill Guardians provide programme-scoped human finality for exception lanes only, with anti-rubber-stamp controls: conflict checks, rotation, sampling audits, and multi-review thresholds for high-risk lanes.
From calming minds to defending outcomes
Mind Chill began in 2017 as immersive art built to reduce anxiety and create calm at scale. Then the same feeds that buried calm and rewarded outrage started training the systems that now make real decisions. We didn't want more rhetoric. We wanted receipts.
The moment it clicked
A message arrived: someone's child felt safer because of what they experienced. Around the same time, lived experience inside our own community made one thing obvious: the nuance that matters in high-impact decisions can't be reliably reduced to a prompt. So we designed a human layer for the edge cases—structured, scope-bound, and auditable.
Guardians are not a "panel." They're a network.
Mind Chill Guardians come from different countries, backgrounds, and lived realities. That diversity is not branding—it's risk reduction. It makes decisions harder to game, easier to challenge, and more credible under scrutiny. Guardians do not "run the system." They review only what the lane requires humans to own.
Receipts over rhetoric
Operational Guardians plug into Good Proof lanes as a controlled finality mechanism: conflict checks, rotation, multi-review where required, and an audit trace tied to a Status Link. Minimal disclosure by default. If a decision is appealed months later, you can show what happened, within scope, without dumping sensitive payloads.
Why buyers choose Guardians
Lived experience at the edge cases (not a generic helpdesk)
Conflict-checked + rotation-based (anti-rubber-stamp by design)
Multi-review on high-risk lanes (when the programme requires it)
Audit-traceable outcomes (defensible in disputes, audits, procurement)
Minimal disclosure by default (proof, not payloads)
Procurement-ready clause
Template language for your legal team.
"For any defined integrity-gated action, Provider shall maintain a Good Proof Stamp with an active Status Link. Actions taken with status NOT_VERIFIED, NEEDS_REFRESH, or WITHDRAWN shall be treated as unverified and must be blocked or escalated per programme rules."
Schedule A: Status-Link Reliance Terms (Compute Integrity)
Definitions + operating rules procurement teams can copy/paste.
1. Definitions
- High-Impact Decision Class: a decision type designated for Stamp gating (e.g., production promotion, envelope override, incident closure).
- Status Link: the verification endpoint returning validity state + scope boundaries.
- Evidence Window: the time period during which supporting materials are retained for review.
- Evidence Pack: time-stamped snapshot for filing/disputes (IDA format).
- Scope Boundary: the defined limits of what a Stamp covers (decision class, expiry, programme).
2. Required States for Execution
- VALID→ may proceed within scope.
- NEEDS_REFRESH/ NOT_VERIFIED / WITHDRAWN → must block or escalate per lane rules.
- Fail-closed:timeout/unreachable ⇒ NOT_VERIFIED.
3. Withdrawal Semantics
- WITHDRAWN is returned wherever the Status Link is checked.
- No execution may proceed on WITHDRAWN.
- History is append-only. Withdrawal does not erase.
4. Technical Safeguards
- HTTPS-only verifier endpoint.
- Official verifier host allowlist.
- Redirects forbidden.
- Timeout/unreachable ⇒ NOT_VERIFIED.
SLA placeholders (complete per programme)
Verifier availability target: [___]%. Response-time target: [___] ms. Evidence Pack export: [___] hours. Status propagation: [___] seconds.
5. Evidence Retention Defaults
Retention period: [___] months/years. Jurisdictional overrides apply per programme counsel.
Not legal advice. Template language for your legal team.
Procurement pack available: architecture summary, data handling overview, subprocessors, retention options.
What you get in 30 days
One integrity-gated decision class, production-ready controls.
One integrity-gated decision class defined
Capability surface documented
Pre-execution/pre-reliance gate integrated
Refresh/withdraw triggers configured
Counterparty verification route tested end-to-end
One redacted IDA specimen generated
Go/no-go rollout recommendation
Due Diligence FAQs
Make compute integrity operational.
Start with one integrity-gated decision class. Ship one verifiable gate in 30 days. Expand when counterparties rely on the Status Link.
Not a certification. Scope-limited verification. Acceptance depends on counterparty or programme requirements.