Evidence schema by format
Offsets use baseline proof, receipt or audit links, match ratio, surplus rule, and destination checks. Pledge swaps use logs, attestations, timestamps, and agreed check-ins.
Validation and evidence
The pilot should not rely on vague trust. Every visible proof claim needs a scope, evidence schema, challenge lane, and completion state.
Validator scope
Reviewers certify narrow evidence claims, not broad moral worth, legal enforceability, tax treatment, escrow status, or final real-world impact.
Offsets use baseline proof, receipt or audit links, match ratio, surplus rule, and destination checks. Pledge swaps use logs, attestations, timestamps, and agreed check-ins.
The same receipt, audit, or public log should not create multiple verified-completion claims unless the record explicitly explains why reuse is valid.
Reviewers should not validate offers where they are a party, beneficiary, close counterparty, or institutional sponsor.
Participants can challenge a completion state, duplicate proof, coercive baseline, or factual error before a badge becomes durable.
Track turnaround time, challenge rate, appeal overturn rate, duplicate-proof misses, and unresolved dispute share.
Publish real counts only: submitted records, reviewed completions, blocked proposals, disputes, and appeal outcomes.
Public validator
The validator publishes required proposal fields, status values, factor codes, evidence schemas, and provenance objects so the core feature is inspectable like MPGF.
Core profile
11 check(s), 0 blocker(s), status pass.
Status taxonomy
State 1
Terms are being written and are not visible as live liquidity.
No reviewer action yet.
State 2
The participant has stated the action, reciprocal request, baseline, duration, exit condition, and evidence rule.
Completeness and safety screen.
State 3
The claim depends on receipts, public logs, third-party records, or prior-donation proof.
Request missing proof or keep the record paused.
State 4
Counterparties or reviewers can flag duplicate proof, coercive framing, or factual gaps.
Hold completion until the challenge lane closes.
State 5
Evidence supports the specific claim being displayed, without implying legal, tax, custody, or outcome guarantees.
Publish only the verified claim and reviewer confidence band.
State 6
The record remains visible as a problem state, not a completed trade.
Publish a short reasoning summary when disclosure is safe.
Reviewer roles
Each role certifies a narrow operational question so users can tell whether a record is complete, evidenced, appealed, or still unresolved.
Checks completeness, prohibited categories, baseline clarity, evidence method, and whether the proposal belongs in the public launch wedge.
Publishes: A submitted, paused, or blocked intake state with the narrow reason safe to disclose.
Checks receipts, public logs, attestations, provider records, proof uniqueness, and challenge-window readiness.
Publishes: A needs-evidence, challenge-window, completion-reviewed, or disputed/unresolved state.
Reviews challenged decisions when new evidence, conflict concerns, duplicate proof, or coercive-baseline claims are raised.
Publishes: A short reasoning summary, outcome, and any changed evidence state when disclosure is safe.
Operating targets
These targets turn the trust problem from a site-wide disclaimer into a visible operating promise that can be audited over time.
Before assignment
Reviewers should not validate records where they are a party, beneficiary, funder, close counterparty, or institutional sponsor.
2 business days
New public offers should receive a completeness and safety screen before they are treated as live marketplace supply.
5 business days
Submitted evidence should be marked as missing, in challenge window, review-cleared, or unresolved within a visible timeframe.
7 business days
Appeals should preserve the original decision, challenger claim, reviewer response, and final state in the audit log.
Challenge and appeal contract
Challenges can target a specific claim, evidence row, baseline concern, disclosure decision, externality trigger, completion state, or policy flag. They do not mutate live state by themselves; they route a human review lane with redacted provenance.
Appeal contract moral-trade-challenge-appeal-v0.2
9 check(s), 0 blocker(s), 8 trigger(s).
claim, evidence row, baseline concern, disclosure decision, externality trigger, completion state, policy flag.
participant, counterparty, affected party, reviewer, admin safety, external verifier.
duplicate proof, coercive baseline, wrong scope evidence, material factual error, privacy disclosure error, externality remedy gap, reviewer conflict, policy misapplied.
uphold decision, request evidence, route human review, open challenge window, block reliance, record remedy, close unresolved, correct record.
Requested outcomes are advisory and must match the appeal trigger before reviewer routing.
Reviewer quality
The pilot should track reviewer performance and failure modes before expanding reputation or paid-action volume.
Trust ladder
Show this badge only when the underlying record and review scope support it.
Show this badge only when the underlying record and review scope support it.
Only provider-linked receipts or webhooks should create this badge.
Show this badge only when the underlying record and review scope support it.
Show this badge only when the underlying record and review scope support it.
Governance
The next operating model is founder-led moderation with a public rulebook, an appeal path, external reviewer panel, and real transparency numbers.
No threats, coercive baselines, hidden platform fees, unsupported jurisdictions, or campaign-contribution offsets.
Hard cases should leave an internal audit log and, when safe, a short publishable reasoning summary.
The pilot stays centralized for safety and compliance while preserving exportable records for future interoperability.