Protocols & Rails
Agentic Commerce & Payments that stays authorised.
UCP makes autonomous buying real. Good Proof makes it operable: verifiable, scope-bound execution with live revocation by link.
No Stamp → No Ship for defined agentic commerce actions.
- Checkout, refunds, payout holds, merchant bans, dispute closure — gated by Status Link
- Counterparties verify scope, expiry, signer, status without logging into your stack
- Stamped delegation + permission scopes with expiry + revocation
- Evidence Pack (IDA format): time-stamped snapshot for disputes, audit, and procurement
Fail-closed•Append-only•Scope-bounded
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.
Why agentic commerce buyers are moving now
Autonomous execution, policy drift, and counterparty scrutiny are converging.
Disputes are authority disputes
"Was it permitted then, and is it valid now?" becomes the core question. Screenshots and internal exports don't survive scrutiny.
Policy drift invalidates prior approvals silently
Refund thresholds, risk limits, and dispute rules change. Execution continues without re-verification unless a gate catches it.
Payout holds and merchant bans escalate fast
These are livelihood and reputation decisions. Counter-parties demand portable proof, not portal access.
Acquirer/scheme/audit review requires portable evidence
External parties need defensible records without logging into your stack or waiting for internal exports.
Screenshot-driven dispute handling is expensive
Fragmented evidence across tools, vendors, and policy versions creates reconstruction cost and legal risk.
Revocation must propagate immediately
When compromise is detected, stop-rely must reach every enforcement point — not wait for a meeting.
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
- Transaction correctness or best price
- Underlying payment data truth
- Model correctness
- Raw PII/payloads 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
In agentic commerce, the dispute is rarely "did it happen."
It's: was it permitted, under what limits, using which policy/version, and can reliance be revoked when risk changes.
UCP expands the execution surface: agents can buy, refund, hold payouts, and close disputes. Without a portable proof object, every dispute becomes screenshots, internal exports, or "trust us."
Good Proof turns high-impact commerce execution into a contract-referenceable gate.
Cross-rail agent transactions need two controls
Identity portability + execution validity
What portability gives
- Reusable agent identity/reputation context
- Faster counterpart onboarding
- Less repetitive KYC/KYB evidence exchange
What Good Proof adds
- Action-level authorization at execution time
- Revocation propagation (WITHDRAWN) across enforcement points
- Dispute-ready snapshot (IDA Evidence Pack)
⚠️ Identity/reputation portability does not equal permission to execute.
Execution requires VALID Status Link in scope.
Global Coverage
Regulatory reality
No hype, no compliance claims — portable proof that survives cross-border review.
EU
PSD2/PSD3 scrutiny + DORA resilience; verifiable evidence for payment disputes.
UK
PSR enforcement + operational resilience; portable proof for high-impact commerce.
US
CFPB scrutiny + FTC enforcement; defensible records for disputes and complaints.
Canada
Payment codes of conduct + OSFI scrutiny; portable proof reduces friction.
Australia
ePayments Code + ASIC enforcement; verifiable execution for marketplace disputes.
Asia
Growing payment regulation across hubs; portable proof for cross-border commerce.
Middle East
Digital payment regulation expanding; portable verification supports cross-border reliance.
Africa
Mobile-money and fintech regulation strengthening; verifiable proof across regional bodies.
Good Proof doesn't certify compliance. It makes high-impact commerce controls verifiable, refreshable, and withdrawable by link.
Jurisdictional Configuration
Country overlays can be configured per programme
Examples include programme-specific mapping for UAE, Saudi Arabia, South Africa, Kenya, Nigeria, and other jurisdictions where disclosure, retention, appeal handling, language support, and verifier-access requirements differ.
Configure scope boundaries, evidence windows, redaction matrix, and verifier checklist per jurisdiction.
Not legal advice. Final legal mapping is owned by programme counsel.
The Agentic Commerce Surface
What gets stamped before execution is allowed — the capability surface:
Merchant capability set (what the agent is allowed to do)
Payment handler configuration + rails (PSP/acquirer/processor context)
Refund/chargeback policy version + thresholds
Risk controls + limit envelope (amounts, velocity, categories, geography)
Dispute closure authority + appeal rules
Delegation object: scopes, expiry, and revocation conditions
Material surface change → NEEDS_REFRESH. Compromise/integrity failure → WITHDRAWN.
What gets stamped
(decision classes — define per programme)
Transaction Execution
- Checkout execution above threshold / risky category / new device
- Refund approval/denial and reversal rules
Financial Controls
- Payout holds/reserves and releases (livelihood-impact)
- Merchant bans/delistings and reinstatements
Dispute Governance
- Dispute/chargeback closure outcomes + evidence window reference
- Appeal outcomes and reinstatement decisions
Delegation & Authority
- Agent delegation (who/what can act, within what scope, for how long)
- Delegation scope renewal, change, or revocation
Integration in 3 touchpoints
1
Issue
At action creation (checkout, refund, payout hold, ban) → require a Stamp.
2
Communicate
Include Status Link in API/webhook/counterparty notifications.
3
Rely
At execute/release/settlement → verify Status Link (fail-closed).
High-impact gating only. Everything else runs normally.
Live status states (what gates execution)
Every Status Link returns one of four states:
VALID
Proceed within scope
NEEDS REFRESH
Re-verify before relying
WITHDRAWN
Stop relying immediately
NOT VERIFIED
Treat as unverified (fail-closed)
If it's not VALID, the action does not execute.
Fail-closed: unreachable verification returns NOT_VERIFIED → block or escalate.
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. Understanding these ensures fail-closed enforcement at execution time.
NEEDS_REFRESH
When any of these occur, re-verify before you rely.
Refund policy / dispute rule pack version changes
Risk thresholds change (velocity, amount, geo, MCC/category)
Payment rail / processor configuration change
Merchant capability set changes (new actions allowed)
Delegation scope changed or renewed
Model retrain affecting risk classification used in gating
Evidence window expired for a dispute-sensitive decision class
New payment method added to scope
Acquirer/scheme rules update affecting this decision class
NEEDS_REFRESH means "re-verify before you rely," not "defer."
WITHDRAWN
Stop-rely signal. Execution must not proceed.
Suspected account takeover / agent credential compromise
Payment handler or webhook integrity breach suspected
Abuse pattern discovered (refund abuse, friendly fraud spike)
Merchant integrity event (sanctions hit, prohibited goods, severe policy breach)
Delegation object invalidated (revoked authority)
Critical misconfiguration discovered in payment routing
Regulatory stop-order or payment freeze issued
Incident declares prior approval unsafe to rely on pending review
Fail-closed: Wherever the Status Link is checked, if WITHDRAWN → block or escalate.
How it works in Agentic Commerce
1
Stamp the surface
Approve merchant config + policy version + limits + delegation scope.
2
Gate high-impact execution
Pre-execution Status Link check at checkout/refund/payout hold/ban/dispute closure. Not VALID → block or escalate.
3
Revoke fast
Set WITHDRAWN on compromise/invalidation; stop-rely propagates wherever checked.
Make the gate machine-checkable, not meeting-checkable.
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, and procurement
- Append-only: withdrawal ≠ erasure
- Minimal disclosure default; programme-scoped access when required
PDFs are great for filing. Status Links keep them current.
What's inside the IDA Evidence Pack
Decision-time snapshot for disputes, audit, and filing.
Decision summary + lane scope boundary
Decision-time timestamp + evidence window
Policy/rule-pack identifier + version references
Payment handler/tool surface identifier + version references
Signer/authority reference
Verification transcript + timestamps
Redaction matrix (what is intentionally excluded)
Proof ≠ payloads. Raw PII/logs are not required by default. Programme-scoped if required, with auditable access trails.
What counterparties can verify
No login. No portal. Just a link that fails closed.
Current validity: VALID / NEEDS_REFRESH / WITHDRAWN / NOT_VERIFIED
Scope boundaries: which action class + limits + expiry
Signer reference (system / programme authority)
Verification timestamp (verified_at)
Forwardable IDA Evidence Pack for disputes and audit
Optional: signed verify responses (programme-scoped)
Minimal disclosure by default: no prompts/logs/PII. Programme-gated access when required with auditable trail.
AI-Agent Era
AI-agent era controls
Prompts can drift. Reliance controls must not.
Material change in policy/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.
Who buys this in Agentic Commerce
Commercial buyers with high-impact execution accountability.
PSP / Payments Ops
Pain: Disputes require proof of what policy + limits were live when the agent executed.
Outcome: Status Link is the portable verifier; IDA snapshot is the dispute file.
Book a Stamp SprintRisk / Fraud
Pain: Policy/threshold changes invalidate prior approvals but execution continues.
Outcome: Material change triggers flip NEEDS_REFRESH so execution stops until refreshed.
Book a Stamp SprintMarketplace Integrity / Merchant Risk
Pain: Bans/holds create counterparty escalation and reputational pressure.
Outcome: Verifiable status by link; withdrawal enables immediate stop-rely.
Book a Stamp SprintLegal / Disputes
Pain: "Prove what was authorised then" becomes discovery.
Outcome: IDA Evidence Pack is time-stamped and citable; status stays live.
Book a Stamp SprintProcurement / Vendor Risk
Pain: Contract clauses lack machine-checkable verification semantics.
Outcome: Procurement-ready clause template + Schedule A with status-linked operating rules.
Book a Stamp SprintCompliance / Audit
Pain: Evidence retrieval for audits is slow and system-bound.
Outcome: Fileable Evidence Pack snapshots with append-only history and redaction matrix.
Book a Stamp SprintExternal verifiers (verify by link, not by portal access)
AcquirersScheme partners
Merchants
Auditors
Regulators
Dispute counsel
Enterprise customers
Where budget comes from
Usually funded from existing risk and operations lines, not new category spend.
Payment disputes / chargeback ops
Trigger: Rising dispute volume, scheme scrutiny, or costly manual evidence reconstruction
Why it fits: Portable evidence + fail-closed reliance control reduce reconstruction effort and repeat findings.
Fraud / risk governance
Trigger: Policy drift causing stale approvals, threshold breach, or abuse pattern discovery
Why it fits: Material change triggers flip status; execution stops until refreshed or re-verified.
Legal defensibility / complaints
Trigger: Regulatory complaint, press scrutiny, or dispute requiring decision-time proof
Why it fits: Decision-time snapshot + live status make authorisation outcomes defensible.
Merchant integrity / payout controls
Trigger: Ban or hold challenge, reinstatement dispute, or payout release scrutiny
Why it fits: Status-linked decisions with withdrawal propagation and verifier access.
Procurement / vendor risk assurance
Trigger: Enterprise buyer requirement, partner audit, or scheme compliance expectation
Why it fits: Contract-ready clauses with machine-checkable verification semantics.
Audit readiness / partner assurance
Trigger: Acquirer review, scheme audit, or partner due-diligence request
Why it fits: Append-only verification history with Evidence Pack snapshots for review workflows.
Start with one high-impact lane and prove dispute/audit friction reduction before expansion.
Procurement-ready clause
Template language for your legal team.
"For defined agentic commerce and payment actions, Provider shall maintain a Good Proof Stamp with an active Status Link. Actions attempted with NOT_VERIFIED, NEEDS_REFRESH, or WITHDRAWN shall be treated as unverified and must block or escalate."
Schedule A (template — programme terms)
Definitions + operating rules procurement teams can copy/paste.
1. Definitions
- High-Impact Action Class: the defined action lane (e.g., refund approval, payout hold, merchant ban) requiring verification.
- Status Link: the verification endpoint returning validity state + scope boundaries.
- Scope Boundary: the merchant/policy/limits configuration covered by the Stamp.
- Evidence Window: the programme-defined period and inputs considered for decision-time verification.
- Evidence Pack: the fileable, programme-configured snapshot for disputes/audit/procurement.
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. Support turnaround: [___] hours.
5. Retention defaults
Stamps and event logs: 7 years. Evidence windows: configurable 30–365 days (default 90). Jurisdictional overlays define retention per region.
Anti-spoof controls
- • verify_url host MUST match the official verifier
- • HTTPS/TLS required; no insecure overrides
- • Redirects forbidden; any violation → NOT_VERIFIED
Not legal advice. Template language for your legal team. Adapt to programme requirements and jurisdiction.
Procurement pack available: architecture summary, data handling overview, subprocessors, retention options.
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, minimizing 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. 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)
What you get in 30 days
One decision class, production-ready.
One decision class defined (e.g., refund approval or payout hold)
Capability surface documented (merchant config + policy version + limits)
Gate integrated (pre-execution Status Link check)
Refresh and withdrawal triggers configured
Counterparty verification route tested end-to-end
One redacted IDA Evidence Pack specimen generated from your system
Go/no-go rollout recommendation for expansion
Due Diligence FAQs
Make agentic commerce shippable.
Start with one decision class. Gate it end-to-end. Expand once counterparties rely on the Status Link.
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.