This repository has been archived on 2026-07-08. You can view files and clone it. You cannot open issues or pull requests or push a commit.
Files
identity-canon/research/commercial-identity/reputation-assurance-gradient.md
tegwick 08361f6fb7 Settle commercial identity nuances with consolidated enums and linking rules
Add commercial-identity-nuance-settlement.md resolving control_basis,
binding_trigger, cross-registry Synonymity strengths, OPI branch modeling,
escrow commitment type, reputation portability, payment edge cases, CRM renewal
rules, Person Account adapters, and eIDAS wallet scope. Update canon, OpenQuestions,
and all commercial-identity source notes.
2026-06-21 23:21:21 +02:00

242 lines
11 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Reputation and Counterparty Assurance Gradient
## Source Type
Cross-domain synthesis. Online reputation systems, credit reporting, contract
bonding theory, payment dispute automation, and alternative dispute resolution
(ADR) / litigation practice.
## Domain
How counterparties move from weak social proof to enforceable commercial reliance
— and how identity-canon should model that journey without collapsing tiers.
## Why This Source Matters
"Reputation" is overloaded: a five-star Yelp review, a D&B PAYDEX score, a
performance bond, and a court judgment all influence whether a counterparty is
trusted — but they differ radically in **evidence quality**, **gaming risk**,
**attribution strength**, and **enforceability**. Software often stores them in
one "rating" field. Canon must preserve the gradient so downstream systems do not
treat gamable opinion as legal fact or ignore contractual stakes already modeled
elsewhere.
## The Assurance Gradient (Journey)
Counterparty assurance typically escalates through four tiers. Higher tiers do
not replace lower ones; they **constrain** how much weight lower tiers may carry
for a given decision.
```text
Tier 1 OPINION Star ratings, reviews, karma, badges
(weak/gamable) Low cost to fake; Sybil-prone; scope-local
Tier 2 OBSERVED PAYDEX, on-time %, chargeback rate, audit logs,
(evidence) verified transaction history, KYC outcome
Tier 3 COMMITTED Contract, bond, escrow, guarantee, insurance,
(financial) SLA penalties, payment mandate, subscription lock-in
Tier 4 ADJUDICATED Arbitration award, court judgment, regulator action,
(legal) enforced settlement, lien, bankruptcy filing
```
### Tier 1 — Opinion signals (weak, gamable)
**Examples:** Amazon/Yelp star ratings, eBay feedback scores, Stack Overflow
reputation, Uber driver rating, Trustpilot reviews, Airbnb host score.
**Properties:**
- **Low cost of manipulation** — fake reviews, review bombing, sock puppets,
Sybil accounts (Jøsang reputation attack taxonomy).
- **Scope-local** — reputation on eBay does not transfer to Etsy without
explicit portability (reputation bank problem).
- **Voluntary participation bias** — satisfied and angry customers over-represent;
silent majority absent.
- **Identity attribution weak** — reviewer may be unverified persona; linkage to
Natural Person or Organization often absent.
- **Economic effect real but bounded** — eBay seller ratings correlate with price
premium, but platforms add escrow and buyer protection because ratings alone
insufficient.
**Canon mapping:** **Reputation Signal** — an **Evidence Source** with
`assurance_tier: opinion`. Attach to **Profile**, **Commercial Record**, or
**Actor** with explicit **Scope** (platform namespace). Default synonymity and
trust strength: **weak**. Do not promote to Commercial Commitment.
**Gaming defenses (downstream):** verified-purchase flags, rate limits, graph
analysis, moderation — model as separate Evidence Source metadata, not as tier
upgrade by itself.
### Tier 2 — Observed metrics (evidence-based)
**Examples:** D&B PAYDEX, business credit scores, platform completion rate,
on-time delivery statistics, SLA attainment dashboards, chargeback ratio,
sanctions-screen clear result, KYC pass, LEI renewal status.
**Properties:**
- **Grounded in observable events** — payment dates, shipment scans, registry
lookups, transaction logs.
- **Stronger attribution** — usually tied to **Registry Identifier**, **Commercial
Record**, or verified **Account** history.
- **Third-party or platform issuer** — D&B, credit bureaus, marketplace operator,
KYC vendor acts as **Evidence Source** issuer.
- **Still revisable** — metrics update; disputes may correct; not legally
conclusive.
- **Monitoring lifecycle** — ongoing CDD and PAYDEX refresh mirror **Lifecycle
State** on evidence, not one-time truth.
**Canon mapping:** **Performance Evidence****Evidence Source** with
`assurance_tier: observed`. Link to **Commercial Record** / **Organization** via
**Registry Identifier** or **Commercial Relationship**. Supports **Trust
Relationship** with medium-to-strong confidence when issuer is authoritative.
### Tier 3 — Committed stakes (contractual / financial)
**Examples:** Performance bonds, surety bonds, letters of credit, escrow deposits,
service-level agreements with liquidated damages, signed MSAs, active subscription
with payment mandate, insurance certificates, qualified electronic seals on
contracts (eIDAS).
**Properties:**
- **Costly to breach** — Klein-Leffler bonding: quality assurance through
market forces when reputation alone insufficient; hostages and penalties.
- **Explicit parties** — **Legal Person** / **Organization** actors bound via
**Commercial Commitment** and **Representation** chains.
- **Automated enforcement partial** — smart-contract escrow, Stripe retention,
auto-renewal billing, SLA breach triggers — automation executes **committed**
rules without yet reaching court.
- **Identity stakes rise** — counterparties need stable **Registry Identifier**,
**Commercial Record**, and often **Beneficial Ownership Relationship** because
liability is real.
**Canon mapping:** **Commercial Commitment** (contract, subscription, payment
mandate, bond) with **Evidence Source** attesting execution. Assurance tier:
`committed`. **Trust Relationship** here should cite the commitment ID, not
opinion aggregates.
**Distinction:** A five-star rating is not a bond. A bond is not a review.
Model separately; combine only in downstream risk engines with explicit weighting.
### Tier 4 — Adjudicated outcomes (automated dispute → legal resolution)
**Escalation path:**
1. **Platform automation** — chargeback dispute rules, marketplace arbitration
(eBay Money Back Guarantee), payment processor outcome.
2. **Contractual ADR** — mandatory arbitration clause (AAA, ICC, JAMS); neutral
award binding per contract and statute.
3. **Courts** — breach of contract, fraud, collections, judgment lien, bankruptcy.
**Properties:**
- **Third-party or state authority** — arbitrator, court, regulator issues outcome.
- **High attribution** — parties identified in proceeding; ties to **Legal Entity**.
- **Enforceable beyond platform** — judgments attach to legal persons; credit
reporting may follow.
- **Lifecycle durable** — satisfied, appealed, vacated, enforced — explicit
**Lifecycle State**.
**Canon mapping:** **Adjudication Outcome****Evidence Source** with
`assurance_tier: adjudicated`. May trigger **Commercial Commitment** state change
(breached, fulfilled), **Trust Relationship** revocation, or **Lifecycle State**
on **Commercial Record**. Do not model as "bad review."
## Cross-Tier Dynamics
| Transition | What changes | Canon event |
| --- | --- | --- |
| Opinion → Observed | Platform verifies purchase; metric computed from logs | New Performance Evidence; optional Synonymity link reviewer Account to transaction |
| Observed → Committed | Parties sign contract / post bond | Commercial Commitment created; Trust Relationship cites commitment |
| Committed → Adjudicated | Breach → ADR/court | Adjudication Outcome Evidence; commitment lifecycle update |
| Adjudicated → Observed | Judgment paid; credit file updated | Performance Evidence refresh (credit bureau) |
**De-escalation:** Adjudicated fraud finding may **invalidate** opinion signals
(moderation) but should not silently delete Evidence — supersede with lifecycle.
**Identity coupling:** Higher tiers require stronger **actor attribution**.
Opinion may attach to **Persona**; adjudication attaches to **Legal Entity** +
**Registry Identifier**.
## Relationship to Existing Canon
| Concept | Role in assurance gradient |
| --- | --- |
| Evidence Source | Carrier for all tiers; use `assurance_tier` metadata |
| Trust Relationship | Counterparty reliance; must cite tier basis |
| Commercial Commitment | Tier 3 anchor |
| Commercial Relationship | Scope for which assurance applies |
| Registry Identifier | Attribution for tiers 24 |
| Beneficial Ownership Relationship | Liability chain for tier 34 entity customers |
| Assurance Level (NIST) | Orthogonal — identity/auth proofing, not commercial performance |
| Synonymity Assertion | Link platform persona to legal entity when tiers mix |
## Reputation Systems Literature (Practical)
Jøsang survey and Resnick criteria for effective reputation systems:
1. Long-lived entities with predictable future interaction.
2. Capture and distribute feedback from prior interactions.
3. Use feedback to guide trust.
**Implication for canon:** Tier 1 only works when **Scope** is stable and
interaction history is modeled as Evidence with temporal bounds. Reputation
**capital** (economic value of good history) is aggregate **Performance Evidence**
over time — not a separate ontological root.
**Attacks:** self-promotion, Sybil, slandering, whitewashing — map to
`integrity_risk` metadata on opinion-tier Evidence; downstream concern, but canon
should flag tier-1 default weakness.
## Candidate Canonical Mappings
| Source artifact | Canonical mapping |
| --- | --- |
| Star rating / review | Reputation Signal (Evidence Source, tier: opinion) |
| Verified purchase review | Reputation Signal + Performance Evidence link |
| PAYDEX / credit score | Performance Evidence (tier: observed) |
| SLA dashboard | Performance Evidence on Commercial Relationship |
| Signed MSA / bond | Commercial Commitment + Evidence Source (tier: committed) |
| Escrow release | Commercial Commitment lifecycle event |
| Arbitration award | Adjudication Outcome (tier: adjudicated) |
| Court judgment | Adjudication Outcome + may affect Legal Entity lifecycle |
| "Trust score" UI | Downstream projection — not canonical root |
## Resolved Canon Question
**Do not add Reputation as a first-class entity.**
Instead:
1. **Counterparty Assurance Gradient** — modeling pattern (four tiers).
2. **Evidence Source** specializations by tier: **Reputation Signal** (opinion),
**Performance Evidence** (observed), **Adjudication Outcome** (adjudicated);
tier 3 uses existing **Commercial Commitment**.
3. **Trust Relationship** carries `assurance_basis` referencing tier + evidence IDs.
**Convenience term only:** "Reputation" in prose — resolve to specific tier and
Evidence Source before modeling.
## Open Questions
*(none — settled in `commercial-identity-nuance-settlement.md`)*
## Settled
- `assurance_tier` primary; optional `numeric_score` + `score_scale` downstream.
- Segregated escrow → Commercial Commitment `commitment_type: escrow`.
- Reputation portability → Synonymity `linked_to`, weak default.
- Oracle release → observed; ADR/court → adjudicated.
## References
- Josang, "A survey of trust and reputation systems for online service provision" — https://doi.org/10.1016/j.dss.2005.05.019
- Hoffman et al., "A survey of attack and defense techniques for reputation systems" — ACM Computing Surveys
- Klein and Leffler (1981), quality assurance through bonding / price premiums
- RFC 7070, An Architecture for Reputation Reporting — https://www.rfc-editor.org/rfc/rfc7070
- Wikipedia, Reputation system — https://en.wikipedia.org/wiki/Reputation_system
- Internal: `commercial-trust-binding-theory.md`, `duns-commercial-credit-identity.md`,
`legal-person-agency-contract.md`, `kyc-aml-commercial-identity-binding.md`