مهندسی سامانههای یادگیری و مَکنو · فصل ۵ — Governance، Notification، Tutor، Portfolio و Trust · 318
Reputation Anti-gaming and Trust Signals
Design a reputation/trust-signal contract that keeps signals decomposed by source, evidence class, independence, provenance, freshness and conflict state; distinguishes verified achievements and authenticated endorsements from self-assertions or activity volume; caps or excludes weak/correlated signals; detects review-required anomalies without auto-accusing users; and produces an explainable bounded trust state rather than an opaque prestige score. میتواند «Reputation Anti-gaming و Trust Signals» را در یک سامانهی یادگیری محدود با state/evidence/governance و QA مناسب طراحی کند.
Lesson summary
Design a reputation/trust-signal contract that keeps signals decomposed by source, evidence class, independence, provenance, freshness and conflict state; distinguishes verified achievements and authenticated endorsements from self-assertions or activity volume; caps or excludes weak/correlated signals; detects review-required anomalies without auto-accusing users; and produces an explainable bounded trust state rather than an opaque prestige score.
میتواند «Reputation Anti-gaming و Trust Signals» را در یک سامانهی یادگیری محدود با state/evidence/governance و QA مناسب طراحی کند.
This lesson produces
میتواند «Reputation Anti-gaming و Trust Signals» را در یک سامانهی یادگیری محدود با state/evidence/governance و QA مناسب طراحی کند.
Who it is for
Foundation
Use a field map, one worked scenario and explicit state vocabulary before independent construction.
Repair
Identify the failed evidence dimension, use the smallest mutated fixture and rerun only the affected gate.
Experienced
Compress definitions; require trade-off defense, counterexample analysis and changed-context transfer.
Prerequisites
When a bigger reputation number means less than it looks
A learner has one verified badge, one recently reviewed high-quality artifact, several endorsements from accounts tied to the same project, and hundreds of low-value activity events. A naive reputation formula turns every event into another positive vote. The result looks precise, yet the evidence is correlated, duplicated, partly self-asserted, and unevenly fresh.
In this lesson you build Reputation Trust-Signal Provenance & Anti-gaming Review Ledger v1. The contract keeps each signal decomposed by signal_type, source_ref, evidence_ref, provenance_ref, verification_state, endorsement_ref, independence_class, correlation_group, freshness_timestamp, expiry_state, duplicate_signal, reciprocity_flag, anomaly_flag, manual_review_state, cap_rule, exclusion_reason, trust_state, reason_code, and appeal_state.
Core rule: reputation is not raw volume and an anomaly is not guilt. Verified evidence may contribute; duplicates, correlated endorsements, reciprocal patterns, stale or revoked signals must be capped, excluded, or routed to neutral review. Missing evidence remains UNKNOWN, UNVERIFIED, STALE, REVOKED, REVIEW_REQUIRED, HOLD, or INSUFFICIENT_EVIDENCE instead of being converted into prestige.
For: learning-platform engineers, credential/reputation architects, trust-and-safety reviewers, QA, and data-product engineers. Not for: public accusation, behavioral profiling beyond the bounded fixture, automated punishment, social-credit scoring, or treating engagement volume as mastery.
Route orientation and ownership boundary
MKN-025 owns only Reputation Anti-gaming and Trust Signals. Its authorized prerequisites are hard prerequisite MKN-021 and soft prerequisite MKN-024. MKN-024 owns the professional portfolio/profile compiler; MKN-026 owns digital-commerce compliance boundaries. This lesson does not absorb either outcome.
Foundation learners receive a field map and one traceable baseline. Repair learners isolate the first broken evidence dimension—duplicate identity, correlation, expiry, provenance, or appeal handling—and rerun only the affected gate. Experienced learners defend signal weighting/capping and review routing without hiding them in a single score.
Three checkpoints: F1 state the owned boundary and a non-goal; F2 diagnose one anti-gaming shortcut by exact field/state; F3 recompute the transfer after expiration, revocation, and appeal evidence without copying the baseline decision.
Mental model: trust is an explainable ledger state, not an opaque prestige score
Reference flow:
raw signals → provenance + verification typing → freshness/expiry → independence + correlation → duplicate/reciprocity/cap rules → neutral anomaly review → bounded trust state + reasons → appeal/recompute
Keep four layers separate:
- Observed signals: achievement credential, endorsement, reviewed artifact, activity event, self-assertion, reviewer evidence.
- Evidence quality: provenance, verification, freshness, expiry/revocation, independence/correlation, duplicate/reciprocity state.
- Defensive controls: cap, exclusion, anomaly routing, manual review, appeal, and versioned policy.
- Bounded decision: an explainable state plus reason codes. It must be reconstructable from visible evidence without hidden model reasoning.
The system may say “review required because three endorsements share one correlation group.” It must not say “the learner cheated” merely because a pattern is unusual.
Foundation contract: typed signals, provenance, independence, and non-success states
For each signal preserve at least:
- identity:
subject_ref,signal_id,signal_type,source_ref; - evidence:
evidence_ref,provenance_ref,issuer_or_actor_ref,verification_state,endorsement_ref; - independence:
independence_class,correlation_group,conflict_state,duplicate_signal,reciprocity_flag; - time:
freshness_timestamp,expiry_state; - quality:
activity_count,quality_evidence_ref,anomaly_flag; - control:
weight_policy_version,cap_rule,exclusion_reason,manual_review_state; - decision:
trust_state,reason_code,appeal_state,audit_event_id.
Seven invariants:
- A copied/imported copy of the same achievement is not a new independent achievement.
- Authenticated provenance is necessary evidence, but does not prove endorser independence or competence by itself.
- Expired or revoked credentials cannot remain active contributors.
- Correlated or reciprocal endorsements cannot silently add as independent votes.
- Activity count never substitutes for quality evidence.
- Anomaly flags route to review; they do not auto-prove misconduct.
- Appeals add versioned evidence and trigger recomputation; prior decisions remain history.
Deep explanation: what standards prove—and what they do not
Provenance. W3C PROV models provenance around entities, activities, and agents, and explicitly frames provenance as information that can support assessments of quality, reliability, or trustworthiness. That supports storing traceable origin and transformation history. PROV does not specify a reputation score, trust threshold, anti-gaming cap, or review policy.
Authenticated achievements and endorsements. 1EdTech Open Badges 3.0 represents verifiable achievements with rich metadata. Its endorsement model can express support for an issuer, program, achievement credential, or a validated self-asserted claim, and endorsement credentials can carry issuance/expiration information. Authentication proves the credential/proof relationship; it does not establish universal competence or independence between endorsers.
Independence and correlation are system-design concerns. If four endorsers are accounts controlled by one project group, cryptographic validity does not make the signals independent. correlation_group and independence_class therefore remain explicit local evidence fields. The exact cap and anomaly thresholds are MAKNOW design authority, not a claim about PROV or Open Badges.
Freshness matters. Expiration and revocation are state transitions, not metadata decorations. A trust state built yesterday must be recomputed when a contributing credential expires or is revoked.
Neutral review. Anti-gaming controls must detect evidence inconsistencies without converting them into moral accusation. “Reciprocity + correlation detected” can be a reason code for human review. It is not a misconduct verdict.
FACT / INFERENCE / DESIGN. PROV and Open Badges provide bounded external facts. The inference is that explainable trust needs provenance, independence/correlation, freshness, and typed uncertainty. The precise MAKNOW ledger, cap rules, anomaly workflow, trust-state vocabulary, and appeal policy are local design.
Worked example: a verified badge, a strong artifact, and a correlated endorsement cluster
Baseline subject LEARNER-DEMO-17 has:
SIG-BADGE-01: a verified Open Badge achievement, current and unique;SIG-ARTIFACT-01: a recent human-reviewed artifact with explicit quality evidence;SIG-END-01..03: authenticated endorsements, but all belong to correlation groupPROJECT-GROUP-A;- 420 low-value activity events with no independent quality evidence.
A naive score would count 425 positive events. The ledger does not. The badge and reviewed artifact remain eligible. The endorsement cluster is authenticated but correlated, so contribution is capped and routed to REVIEW_REQUIRED. Activity volume remains context only. The bounded result is REVIEW_REQUIRED with reason codes CORRELATED_ENDORSEMENT_CLUSTER and ACTIVITY_VOLUME_NOT_TRUST_EVIDENCE—not an accusation.
Table MKN-025-T1 compares baseline, a duplicate-import mutation, and the transfer. The table never hides the decision in one prestige number.
Run the deterministic fixture at lab://MKN-025/MKN-025-LAB1.
Failure modes that create false confidence
Duplicate import inflation. The same verified achievement arrives from two import paths and is counted twice. Same achievement/evidence identity means duplicate, not independence.
Expired endorsement stays active. expiry_state=EXPIRED but contribution remains current. Recompute is mandatory.
Correlation erased. Several related endorsers are marked INDEPENDENT even though they share the same project/organization control context. This needs review, not silent additive weighting.
Reciprocity treated as proof. Two people endorse each other and both endorsements increase trust without any independent evidence. Route to review/cap.
Activity-volume shortcut. Hundreds of clicks, posts, or submissions become the dominant trust input despite absent quality evidence. Engagement is not mastery or trust.
Anomaly → accusation. A model flags a pattern and the system writes MISCONDUCT_CONFIRMED. Forbidden. Anomaly evidence is a review trigger only.
Revoked credential retained. A credential changes to revoked but the trust state is not recomputed.
Appeal ignored. New independent reviewer evidence arrives during appeal, yet the system keeps the prior result as oracle. The decision must be rebuilt and history preserved.
Experienced architecture bridge: event ingestion is not reputation authority
In a production architecture, raw events may arrive from activity streams, credential wallets, review systems, portfolios, identity services, and moderation queues. Do not aggregate them directly into a number. Normalize them first into a versioned signal ledger.
A safer pipeline has three computational stages:
- Normalize evidence: stable signal/evidence identity, provenance, issuer/actor, verification, freshness, revocation/expiry.
- Analyze dependence: duplicate detection, correlation groups, reciprocal relationships, conflict, cap/exclusion policy.
- Decide and explain: reason-coded bounded trust state, review owner/state, appeal state, audit event.
The policy engine may deterministically detect “same credential evidence imported twice” or “expired endorsement still included.” Correlation detection can be partly rule-based and partly review-assisted, but an ML anomaly score must remain evidence—not authority. Store weight_policy_version so every decision can be replayed after policy changes.
For appeals, append evidence and produce a new decision event. Never overwrite the previous trust decision; otherwise the reviewer cannot reconstruct why the system changed.
Alternatives and trade-offs
Single reputation score: simple to sort and cache, but hides provenance, uncertainty, correlation, and policy version. Not sufficient as the owned decision artifact.
Raw count badges/endorsements: easy to explain superficially, but highly gameable by duplication, reciprocal exchange, and correlated issuers.
Only verified credentials: stronger provenance but too narrow; it can ignore current high-quality reviewed work and still cannot infer independence automatically.
Black-box anomaly model: catches complex patterns, but an unexplained risk score must not be converted into punishment or trust state. Use it only as review evidence with bounded reason codes.
Typed ledger + caps/exclusions + human review: more schema and operational work, but it keeps the decision explainable and appealable. This is the reference design.
Stop/pivot condition: if the system cannot show which signals were included, capped, excluded, stale/revoked, or routed to review—and under which policy version—the trust state is too opaque to promote.
Guided and independent practice
Guided. Open the baseline fixture. For each signal identify source, evidence, provenance, verification, freshness/expiry, independence/correlation, duplicate/reciprocity, cap/exclusion, and review state. Then derive the bounded trust state. Do not use activity count as a substitute for quality evidence.
Repair. Run duplicate_verified_achievement.json. Name the smallest invalid field set: duplicate evidence identity + independence contribution. Repair by grouping the copies under one canonical evidence identity and preventing additional independent contribution.
Independent. Run the correlation and reciprocity fixtures without looking at the baseline decision. Explain why authentication is compatible with REVIEW_REQUIRED: the credential can be authentic while its independence is still unresolved.
Experienced. Run the transfer: one endorsement expires, the verified credential is revoked, and an appeal adds independent reviewer evidence. Recompute from the current ledger, explain every include/exclude decision, and preserve the baseline decision as historical evidence.
Verification: what the offline lab actually proves
The lab uses synthetic JSON/CSV only—no network, production account, live learner profile, credential issuer key, or moderation action. Producer tests prove the deterministic evidence-contract rules: baseline routes the correlated cluster to review; duplicate achievement inflation, expired endorsement retention, correlation mismatch, anomaly-to-accusation, activity-volume-as-trust, reciprocity without review, missing provenance, revoked credential retention, ignored appeal evidence, and stale freshness all fail closed. Transfer must recompute under changed evidence and must reject baseline decision reuse.
These tests do not prove that a real person is trustworthy or untrustworthy, that any real endorsement relationship is abusive, or that a platform has detected misconduct. They prove only that the bounded synthetic contract preserves provenance, uncertainty, review, and appeal rules.
Human review must reproduce the decision from visible files and reason codes. Hidden chain-of-thought is not evidence.
Assessment and transfer
S1 Retrieval: explain the owned boundary of MKN-025 and name one adjacent non-goal. S2 Application: construct the complete Reputation Trust-Signal Provenance & Anti-gaming Review Ledger for the baseline. S3 Diagnosis: the same verified achievement is imported from multiple sources and counted as independent. Identify the invalidated identity/independence state, consequence, and minimal repair. S4 Transfer: an endorsement expires, a verified credential is revoked, and an appeal adds independent reviewer evidence. Recompute the current trust state, justify each inclusion/exclusion, and preserve the previous decision as history.
Blocking rubric dimensions are identity/contract, exact evidence binding, negative evidence, bounded decision, and transfer. A response fails if it turns raw volume into trust, treats authentication as independence, turns anomaly into guilt, discards appeal evidence, or copies the baseline state after evidence changed.
References, freshness, and claim boundaries
W3C — PROV-Overview https://www.w3.org/TR/prov-overview/ Bounded FACT: provenance describes entities, activities, and agents/people involved in producing data or things and can support assessments of quality, reliability, or trustworthiness. Boundary: PROV does not define reputation scores, anti-gaming thresholds, correlation rules, or MAKNOW review policy.
1EdTech — Open Badges 3.0 https://www.1edtech.org/standards/open-badges Bounded FACT: Open Badges packages verifiable achievement metadata; Open Badges 3.0 endorsements can support an issuer, credential program, achievement credential, or validated self-assertion and can include issuance/expiration information. Boundary: authentication does not prove endorser independence or assign a reputation value.
Both official sources were rechecked on 2026-09-13. PROV is foundational/stable. Open Badges practice semantics should be rechecked by 2027-01-15 or earlier after material specification change. MAKNOW correlation groups, caps, anomaly-review routing, trust-state labels, reason codes, and appeal workflow are DESIGN, not external facts.
Closing question: which shortcut creates the strongest false confidence in your trust system—duplicate credentials, correlated endorsements, reciprocal exchange, activity volume, stale evidence, or anomaly-as-guilt—and which exact ledger field exposes it?
Assessment
There is no answer key in this lesson pack; answer it yourself and mark honestly. "Needs review" sends the lesson to your review queue.
Assessment rubric
- Identity and contract — owns reputation anti-gaming/trust-signal evidence only.
- Exact evidence binding — FACT/INFERENCE/DESIGN boundaries and source/provenance identities remain explicit.
- Negative evidence — duplicate/correlation/expiry/revocation/reciprocity/anomaly/appeal defects are preserved and fail closed.
- Bounded decision — no opaque prestige score, no auto-accusation, and no state stronger than evidence.
- Transfer — changed evidence is recomputed; baseline decision is never reused as oracle.
References & freshness
Case studies
Lab files
Offline synthetic fixtures only. Run python run_checks.py. Build/review the signal ledger; do not infer real-person misconduct or trustworthiness. Baseline is intentionally REVIEW_REQUIRED because a correlated endorsement cluster needs neutral review.