Irreversible Actions — Platforms
Platform decisions that survive appeals, audits, and press months later.
No Stamp → No Ship for defined high-impact lanes.
Bans, closures, and payout holds aren't "content decisions." They're access, income, and reputation decisions. If AI changes someone's life on your platform, it should ship with verifiable proof: a scope-bound, expiry-aware Status Link that's revocable by link.
- Bans / closures that survive appeals, audits, and press scrutiny
- Payout holds with a verifiable status partners and reviewers can check
- Reason-codes + scope that don't require exposing internals
Fail-closed•Append-only•Scope-bounded
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.
Why platform buyers are moving now
Appeals pressure, livelihood disputes, and third-party scrutiny are converging.
Appeals and reversals under policy drift
High-impact actions are challenged under new policies months later. Portable decision-time proof reduces repeat reviews and arbitrary-reversal accusations.
Payout holds become livelihood disputes
Creator/seller payout holds escalate fast. External reviewers need defensible records with scope, signer, and validity state — not internal screenshots.
Partner/bank/app-store scrutiny without system access
Banks, app stores, and enterprise customers demand portable records they can verify without portal access or NDAs.
Press and regulator scrutiny months after decision
High-profile enforcement actions attract retrospective scrutiny. Append-only verification history is harder to dispute than narrative summaries.
Fragmented evidence across tools/vendors/policy versions
Evidence lives in tickets, CMS queues, policy dashboards, and internal comms. Portable proof bundles it at decision time.
Need for revocable reliance states, not static screenshots
When evidence changes: refresh or withdraw returned wherever the Status Link is checked. No silent drift.
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)
- Decision class + outcome
- Decision-time timestamp
- Signer/authority reference
- Scope boundaries + expiry window
- Validity state (VALID / NEEDS_REFRESH / WITHDRAWN / NOT_VERIFIED)
- Evidence window for appeals/review
Does NOT prove
- Underlying truth of the claim/allegation
- Outcome correctness
- Certification or legal/regulatory compliance
- Raw PII or sensitive evidence by default
In disputes: Status Link = reliance state now. IDA Evidence Pack = fileable decision-time snapshot.
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.
Integration in 3 touchpoints
1
Issue
At ban/hold/delist/restrict issuance → require a Stamp.
2
Notify
In user notices, partner/bank/app-store reviews, and enterprise escalations → include the Status Link.
3
Rely
At enforcement, payout release, reinstatement, or continued restriction → verify Status Link (fail-closed).
High-impact gating only. Everything else runs normally.
What gets stamped in Platforms
If it can trigger a complaint, an appeal, a regulator touch, or litigation—stamp it.
Account enforcement
- Account bans / permanent suspensions (with appeal route)
- Marketplace delistings / restrictions affecting livelihood
- Reinstatements + appeal outcomes (so reversals are provable, not political)
Financial actions
- Creator/seller payout holds (and release decisions)
- Revenue-impacting visibility restrictions
Content governance
- Content takedowns where 'statement of reasons' matters
- Material content restrictions requiring defensible records
Appeals & review
- Appeal outcomes and complaint closure decisions
- Policy-change-driven re-evaluations
Why this exists
These aren't "content decisions." They're access, income, and reputation decisions.
Evidence is fragmented across tools, vendors, and policy versions. Appeals arrive weeks later under new rules, with no durable proof of what was true then.
External parties need defensible records without portal access. Reversals require proving what changed without rewriting history.
Why now
Three forces are converging—and platforms without decision-time proof are exposed.
1
Disputes + appeals + press scrutiny
High-impact actions are challenged later under new policies/tools. Portable decision-time proof reduces repeat reviews and arbitrary-reversal accusations.
2
AI governance + accountability expectations
Across EU, UK, US, Canada, Australia, and Asia hubs, platforms are expected to govern high-impact automated decisions with accountable records and change control.
3
Operational resilience + third-party scrutiny
Banks, app stores, enterprise customers, insurers, and regulators increasingly expect defensible records without portal access.
Good Proof doesn't claim compliance. It makes irreversible actions verifiable, refreshable, and withdrawable by link.
What you get (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.
- Built for disputes, audits, appeals, and procurement
- Minimal disclosure by default (proof ≠ payloads)
- Programme-configured redaction matrix
PDFs are great for filing. Status Links keep them current.
Live Status States
If it's not VALID, block or escalate per lane rules.
VALID
Rely within scope under lane rules (not a guarantee of outcome correctness).
NEEDS REFRESH
A material-change trigger fired—re-verify before relying.
WITHDRAWN
Stop relying; returned wherever the Status Link is checked.
NOT VERIFIED
Treat as unverified; also returned when verification can't be performed (fail-closed).
Fail-closed: timeout/unreachable = NOT_VERIFIED. Block or escalate—never assume validity.
When status changes — and what it means
Status triggers define when a Status Link moves to NEEDS_REFRESH or WITHDRAWN. Understanding these ensures fail-closed enforcement at decision time.
NEEDS_REFRESH
When any of these occur, re-verify before you rely.
Policy version change affecting decision class
Model/tool version or configuration change
New rule or threshold affecting enforcement posture
Vendor/partner/tooling change in decision pipeline
Material change in user/creator account status or eligibility
Evidence window expiry
NEEDS_REFRESH means "re-verify before you rely," not "schedule a meeting."
WITHDRAWN
Stop-rely signal. Action must not proceed.
Confirmed enforcement error or misapplication of policy
Material misstatement discovered post-decision
Appeal outcome requiring immediate stop-rely
Court/regulator order requiring stop-rely
Integrity breach affecting decision pipeline
Fail-closed: Wherever the Status Link is checked, if WITHDRAWN → block or escalate.
What's inside the IDA Evidence Pack
Decision-time snapshot for disputes, audits, appeals, and filing.
Decision summary + lane scope boundary
Decision-time timestamp + evidence window
Policy/tool surface identifiers + version references
Reason-code + authority reference
Verification transcript + timestamps
Redaction matrix (what is intentionally excluded)
Proof ≠ payloads. Raw claim files/PII are not required by default. Programme-scoped access when required, with auditable access trails.
Global Coverage
Regulatory reality
No hype, no compliance claims — portable proof that survives cross-border review.
EU
Statements of reasons + transparency/traceability expectations for moderation decisions.
UK
Safety regimes pushing risk assessment + record-keeping duties.
US
Procurement, insurers, and governance frameworks increasing accountability expectations.
Canada
Online harms direction emphasises baseline safety + transparency expectations.
Australia
Online safety regulator has strong powers + transparency expectations.
Asia
AI governance frameworks emphasising bounded risk, traceability, and controllability.
Middle East
Third-party reliance and cyber/operational resilience expectations tightening across major hubs.
Africa
Market-conduct/complaints handling and record-keeping pressure increasing alongside data-protection obligations.
Good Proof doesn't certify compliance. It makes outputs verifiable, refreshable, 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.
AI-Agent Era
AI-agent era controls
Prompts can drift. Reliance controls must not.
Material change in policy/tool/vendor/configNEEDS_REFRESH
Integrity or enforcement 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.
How Good Proof reduces blast radius
(without pretending prompts are sacred)
Prompts can be hijacked. Status can't.
We don't "trust the model." We gate the action.
No Stamp → block or escalate for defined high-impact actions
Material change triggers → NEEDS_REFRESH (no silent drift)
WITHDRAWN → stop-rely returned wherever the Status Link is checked
Guardians are programme-scoped human finality for exception lanes only.
What counterparties can verify without logging into your perimeter
Current validity state: VALID / NEEDS_REFRESH / WITHDRAWN / NOT_VERIFIED
Scope boundaries and expiry window
Signer authority reference (system or Guardian panel when required)
Change triggers fired (refresh reason code) — without exposing payloads
Verification route and optional signed verify response (programme scoped)
How it works (simple)
1
Define the high-impact decision class
Scope boundaries, evidence window, and what triggers refresh or withdrawal.
2
Require a Stamp
No Stamp, NOT_VERIFIED, or NEEDS_REFRESH → block or escalate (per programme runbooks).
3
Ship portable proof
Issue the Status Link and generate the Evidence Pack automatically.
4
Humans step in only when required
Guardians handle exceptions and disputes inside defined scope, with anti-rubber-stamp controls.
Who uses this in Platforms
Commercial and external buyers with high-impact decision accountability.
Platform buyers
Trust & Safety
Pain: Bans get appealed with no durable proof trail.
Outcome: Each high-impact action has a verifiable Status Link + snapshot IDA.
Book a Platforms Stamp SprintCreator / Marketplace Ops
Pain: Payout holds become livelihood disputes.
Outcome: Verifiers can check live status and see when it changed — without your dashboards.
Book a Platforms Stamp SprintPayments / Risk / Fraud Ops
Pain: Payout-risk decisions are challenged across teams with no single source of truth.
Outcome: Status-linked decisions with fail-closed enforcement and withdrawal propagation.
Book a Platforms Stamp SprintLegal / Policy / Compliance
Pain: Transparency + record-keeping pressure rises; reversals look arbitrary.
Outcome: Scope-bound artefacts you can cite, refresh, and withdraw.
Book a Platforms Stamp SprintProcurement / Enterprise Trust
Pain: Enterprise customers and partners demand defensible governance evidence.
Outcome: Procurement-ready clause template with machine-checkable verification semantics.
Book a Platforms Stamp SprintPartner Operations
Pain: Bank/app-store/regulator queries require manual evidence reconstruction.
Outcome: Portable verification link partners can check independently without portal access.
Book a Platforms Stamp SprintExternal verifiers
Users / Creators / Sellers
Pain: Appeals arrive with no verifiable record of what was decided and when.
Outcome: Status Link provides current validity; Evidence Pack provides the decision-time snapshot.
Appeal bodies / Regulators / Auditors
Pain: Reviewing enforcement decisions requires system access or static exports.
Outcome: Counterparty-verifiable status with scope, expiry, and signer — no portal required.
Banks / App Stores / Enterprise Customers
Pain: Third-party scrutiny without portable, verifiable evidence is slow and fragile.
Outcome: Minimal-disclosure verification by link with fail-closed semantics.
Where budget comes from
Usually funded from existing governance, risk, and compliance lines.
Trust & Safety governance budget
Trigger: Appeal/reversal friction, press scrutiny, or regulatory query
Why it fits: Portable proof + fail-closed reliance control reduce repeat reviews and defensibility gaps.
Payout-risk / payments budget
Trigger: Payout hold disputes, creator/seller escalations, or bank inquiries
Why it fits: Status-linked hold/release decisions with withdrawal propagation and verifier access.
Legal / compliance budget
Trigger: Transparency/record-keeping obligations or regulatory direction
Why it fits: Decision-time snapshots with append-only history and redaction matrix.
Partner / enterprise assurance budget
Trigger: Enterprise customer requirement or app-store/bank governance query
Why it fits: Procurement-ready clause + counterparty verification route without system access.
Audit / procurement readiness budget
Trigger: Internal or external audit finding, or procurement qualification requirement
Why it fits: Fileable Evidence Pack snapshots with verification transcripts for review workflows.
Appeals operations budget
Trigger: Appeals backlog, repeat review costs, or decision-quality improvement initiative
Why it fits: Machine-checkable gate reduces re-review volume; portable proof supports faster resolution.
Start with one high-impact lane and prove dispute/appeal friction reduction before expansion.
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: exception approvals, disputes, high-risk overrides, or post-incident outcomes with human liability.
Mind Chill Guardians provide programme-scoped human finality for exception lanes only, minimising sensitive payload handling, 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.
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.
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 appeals, disputes, procurement)
Minimal disclosure by default (proof, not payloads)
Procurement-ready clause
Template language for your legal team.
"For [High-Impact Decision Classes], Supplier shall issue a Good Proof Stamp prior to action. Buyer may verify status via the Status Link. Stamps returning NOT_VERIFIED, NEEDS_REFRESH, or WITHDRAWN shall block or escalate per programme runbooks."
Anti-spoof controls
- verify_url host MUST exactly match the official verifier
- HTTPS/TLS required; no insecure overrides
- Redirects strictly forbidden
Schedule A (template — programme terms)
Definitions + operating rules procurement teams can copy/paste.
1. Definitions
- High-Impact Decision Class: a decision type designated for Stamp gating (e.g., account ban, payout hold, marketplace delisting).
- 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
- 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 / stop-rely semantics
- WITHDRAWN is returned wherever the Status Link is checked.
- No execution may proceed on WITHDRAWN.
- Optional: programme hooks/notifications for stop-rely distribution.
4. SLA placeholders (complete per programme)
Verifier availability target: [___]%. p99 latency: [___] ms. Pack export window: [___] hours. Withdraw propagation: [___] seconds. Retention default: [___] years.
Not legal advice. Template language for your legal team.
Sprint outcome (Platforms)
What you get in 30 days
1One high-impact decision class defined (clear scope + evidence window)
2Stamp issuance wired to your workflow (or a wrapper gate)
3Status Link route usable by external verifiers
4Refresh + withdraw triggers configured
5Dispute-ready verifier checklist
6Optional Guardian exception path (lane-scoped)
7Go/no-go expansion recommendation
Due Diligence FAQs
Make platform decisions shippable.
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.