World Standing Together™
Library
WST • PRIVATE • AUDITABLE • HUMAN-FIRST

Reputation & Trust

Modular Continuity Civilization Protocol Reader.

WST · Modular · Continuity · Human-First

Reputation & Trust

Signal layer built from delivery · Trust, Continuity & Stewardship

Continuity → Recognition → Stewardship → Execution → Settlement → Reconciliation → Verified Continuity
019 — Reputation & Trust Layer (v1.0).md
/library/_docs/10-governance/019 — Reputation & Trust Layer (v1.0).md

019 — Reputation & Trust Layer (v1.0)

WST • PRIVATE • AUDITABLE • HUMAN-FIRST

Purpose

Provide a lightweight, evidence-based signal about reliability and delivery quality to assist:

matching & recommendations

project awarding decisions

partner selection

…without creating rigid hierarchy, bias loops, or gatekeeping.

Reputation is a signal, not a title.

Trust is earned through fulfilled work, not declared status.

Core Doctrine

Reputation derives from recorded events (UTS), not opinions alone

Fulfillment + acceptance is the primary signal

No single score may dominate decisions

Signals decay over time (freshness matters)

Negative events are recorded, but proportionally weighted

Participants can recover from poor history

No global “rank” that overrides project choice

🧠 Signal Model

Declared Work

→ Executed

→ Fulfilled

→ Accepted

→ Signals Emitted

→ Aggregated Reputation

→ Used (lightly) in Matching

Signal Sources (Canonical)

All signals must originate from verifiable events:

transfer.executed

settlement.recorded (optional)

fulfillment.confirmed

fulfillment.accepted

fulfillment.rejected

fulfillment.disputed

project.unit.closed

No free-floating ratings without linkage.

Reputation Dimensions

Instead of one monolithic score, use dimensions:

  1. Completion Rate

% of accepted intents that reached fulfilled + accepted

  1. On-Time Reliability

deliveries completed within declared or expected timeframe

  1. Acceptance Quality

ratio of accepted vs rejected/disputed fulfillments

  1. Volume of Work

number of completed units (with decay weighting)

  1. Responsiveness (optional)

time from award → execution → fulfillment

  1. Peer Confirmation (optional, bounded)

lightweight acknowledgments tied to a specific fulfillment

Canonical Reputation Record

{

"member_id": "WST-M-000123",

"updated_utc": "2026-04-18T18:00:00Z",

"window_days": 180,

"metrics": {

"completed_units": 12,

"completion_rate": 0.92,

"on_time_rate": 0.88,

"acceptance_rate": 0.90,

"dispute_rate": 0.05

},

"signals": {

"recent_activity_score": 0.8,

"consistency_score": 0.85

},

"derived": {

"confidence_band": "HIGH"

}

}

Scoring Philosophy

No single “reputation score” should be absolute.

Instead:

Reputation Influence = small, bounded modifier

Recommended cap in matching:

≤ 10% of total score

This keeps:

merit first

history helpful

no permanent elite class

Time Decay (Critical)

Recent performance matters more than old history.

Example:

last 30 days → highest weight

30–90 days → medium

90–180 days → low

older → minimal

Fresh work outweighs ancient glory.

Confidence Bands (Human-Friendly)

Instead of raw numbers, expose:

HIGH

GOOD

EMERGING

LIMITED

UNKNOWN

These are summaries, not authority.

Positive Signal Generation

Increase signals when:

fulfillment.accepted

project.unit.closed without dispute

on-time delivery achieved

Negative Signal Handling

Decrease signals when:

fulfillment.rejected

fulfillment.disputed

repeated failure to complete accepted work

Doctrine

one failure ≠ permanent penalty

repeated patterns matter

Dispute Weighting

Disputes should:

reduce confidence temporarily

increase scrutiny

not permanently blacklist unless policy layer decides

Reputation Reset / Recovery

Participants must be able to recover.

Mechanisms:

time decay

new successful completions

dispute resolution outcomes

Peer Signal (Optional Layer)

Lightweight acknowledgment tied to fulfillment:

{

"fulfillment_id": "FUL-...",

"peer_signal": {

"rating": 4,

"note": "Delivered clearly and on time"

}

}

Rules

must attach to a real fulfillment

cannot exist standalone

low weight relative to objective signals

Matching Engine Integration

Reputation feeds into:

Delivery Confidence Score (max ~10%)

Example:

Score =

capability

+ availability

+ alignment

+ reputation (bounded)

Blind Phase Handling

During blind matching:

Project sees:

confidence band

summary metrics (optional)

Project does NOT see:

identity

detailed history

personal identifiers

Post-Reveal Visibility

After award/reveal:

Project may see:

detailed metrics

prior completed units (optional)

fulfillment history (filtered)

Anti-Gaming Protections

No self-rating

No rating without fulfillment linkage

Cap influence of reputation

Decay prevents hoarding

Duplicate identities prevented by identity system

Anomalies flagged (sudden spikes, repeated micro-units)

Reputation Storage

Suggested paths:

/portal/_data/reputation/by_member/{member_id}.json

/portal/_data/reputation/logs/

Minimal Functions

wst_rep_update_from_event(array $event): void

Update metrics based on UTS events

wst_rep_compute(string $memberId, int $windowDays = 180): array

Compute current reputation snapshot

wst_rep_get(string $memberId): array

Retrieve current reputation

wst_rep_confidence_band(array $metrics): string

Return HIGH / GOOD / etc

UI Responsibilities

Show:

confidence band

completed units count

simple reliability indicators

Do NOT show:

raw hidden scoring formulas

manipulable metrics

vanity rankings

City / Charter Use

Charter pages may display:

aggregate completion counts

overall delivery health

But must not:

rank individuals publicly by default

create internal hierarchy from reputation

Important Boundary

Reputation does NOT:

grant authority

override charter binding

override project permissions

override route guard

It only influences:

recommendations

human decision-making

Example (Jonesboro)

Operator completes:

5 units

4 accepted

1 disputed but resolved

Result:

Completion: strong

Consistency: improving

Confidence: GOOD

Matching engine gives:

small boost (not dominance)

Project still chooses.

Anti-Drift Rules

No global ranking leaderboard by default

No reputation-only selection

No permanent penalty without path to recovery

No hidden scoring manipulation

No replacement of human judgment

Final Principle

Trust is not declared.

It is observed, recorded, and earned—again and again.

🔥 What you now have

With this layer:

matching becomes smarter

awarding becomes more informed

participants are encouraged to deliver

system stays fair and recoverable

🚀 You’ve completed the full loop

You now have:

Identity

Authority

Charter structure

Project system

Units (contracts)

Capacity + bidding

Matching engine

Award & reveal

Execution

Fulfillment

Reputation

This is a complete human-centered coordination and economic system.