Contribution and Reputation Graph

Draft 0.1 — 2 August 2026
ANUKA reputation is evidence about contribution in context. It is not a permanent judgment of human worth, a credit score, or permission for automated exclusion.

Objective

The ANUKA reputation layer should answer questions such as:

What has this participant contributed?
Under what conditions?
Who reviewed it?
What result was observed?
How similar is that context to the current opportunity?
Is the evidence current, disputed, corrected, or incomplete?

It should not answer the meaningless universal question:

How good is this person from zero to one hundred?

The governing rule is:

Store evidence as a graph; compute summaries only for a declared purpose and audience.

Why a graph

Contribution is relational.

A pull request connects a contributor, repository, issue, reviewer, release, product, and outcome. A growth experiment connects a hypothesis, audience, variant, metric, company, analyst, data source, and result. A stewardship role connects authority, time, budget, decisions, and handover.

Flattening these relationships into one profile score destroys context and invites gaming.

Core node types

Subject nodes

person;
organization;
product;
AI agent;
team;
pseudonymous identity.

Work nodes

opportunity;
bounty;
assignment;
contribution;
pull request;
design;
test report;
customer introduction;
funded feature;
operational change;
governance proposal.

Evidence nodes

source event;
credential;
attestation;
review;
metric observation;
experiment result;
payment confirmation;
audit record;
dispute;
correction.

Context nodes

domain;
capability;
product stage;
technology;
market;
language;
geography where relevant and lawful;
risk class;
evidence method.

Core relationship types

Examples include:

PROPOSED;
ASSIGNED_TO;
CONTRIBUTED_TO;
REVIEWED_BY;
ACCEPTED_BY;
REJECTED_BY;
DEPLOYED_IN;
MEASURED_BY;
RESULTED_IN;
PAID_BY;
ENDORSED_BY;
DISPUTED_BY;
CORRECTED_BY;
SUPERSEDES;
ACTED_FOR;
STEWARD_OF;
DEPENDS_ON;
SIMILAR_TO.

Relationship vocabulary must be versioned. Product teams must not invent ambiguous synonyms for core events.

Contribution record

A contribution record should contain:

contribution ID;
contributor or contributors;
principal when an agent contributed;
opportunity or originating signal;
product and organization;
contribution type;
scope and acceptance criteria;
timestamps;
evidence references;
reviewer and review method;
acceptance state;
release or delivery state;
payment or reward state;
observed outcomes;
disputes, corrections, and supersession;
visibility and disclosure policy.

Contribution stages

A contribution may progress through:

proposed;
eligible;
assigned or self-started;
submitted;
under review;
accepted, rejected, or needs revision;
released or operationalized;
measured;
rewarded;
archived, corrected, or disputed.

Acceptance, deployment, and outcome are separate events. A merged change is not automatically a successful business improvement.

Attribution

Real work often has multiple contributors.

ANUKA should support:

primary contributor;
co-contributor;
reviewer;
qualifier;
sponsor;
steward;
data analyst;
AI agent and accountable principal;
source community or prior work.

Attribution rules must be declared before reward where possible. Retroactive attribution changes require a visible record.

Capability model

Capabilities should be represented as contextual concepts rather than free-form profile tags alone.

A capability record may include:

capability identifier;
human-readable name;
description;
broader and narrower capabilities;
required evidence types;
domain and product-stage context;
version;
mapping to external frameworks where useful.

Examples:

SaaS onboarding diagnosis;
activation experiment design;
checkout usability testing;
Stripe Connect integration review;
accessibility testing;
investor data-room preparation;
incident-response coordination.

Capability evidence

Evidence strength depends on what it actually demonstrates.

Self-assertion

Useful for discovery, but not proof of demonstrated capability.

Participation evidence

Shows involvement, not necessarily quality or ownership of the result.

Accepted contribution

Shows that work met declared acceptance criteria.

Reviewed outcome

Shows that a reviewer evaluated the contribution and linked it to an observed result.

Repeated outcome

Shows performance across more than one project or context.

Independent credential or endorsement

Adds evidence from a qualified or recognized third party.

These classes should remain visible instead of being collapsed into one badge.

Reputation dimensions

ANUKA may compute dimensions such as:

delivery reliability;
review quality;
hypothesis precision;
experiment safety;
documentation quality;
collaboration;
response time;
measurable impact;
domain depth;
stewardship continuity;
dispute rate and resolution quality.

Each dimension requires a documented method and context. Dimensions are not personality labels.

Contextual matching

Opportunity matching should compare relevant evidence rather than global rank.

A match may consider:

demonstrated capabilities;
similar product stage;
similar metric or problem;
evidence freshness;
role and permission eligibility;
availability;
language and time-zone constraints where voluntarily provided;
risk tolerance;
compensation expectations;
conflicts of interest.

Protected traits and proxies must not be used unlawfully in employment or opportunity decisions.

Reputation summaries

A summary is a query result over the graph.

Examples:

12 accepted onboarding contributions across 5 SaaS products;
4 independently reviewed experiments with positive activation impact;
92% on-time completion for fixed-scope bounties in the last 12 months;
3 disputes, 2 resolved in the contributor's favor, 1 pending;
qualified reviewer for accessibility testing through 2027-03-01.

These are more useful than Reputation: 87.

Confidence and uncertainty

Every derived summary should include:

sample size;
evidence classes;
time range;
context similarity;
missing data;
confidence or uncertainty method;
known disputes;
whether the summary is descriptive or predictive.

Small sample sizes should not be hidden behind precise-looking percentages.

Recency

Older evidence may remain historically true while becoming less relevant to a current task.

ANUKA should model recency as a query parameter, not delete old contribution history automatically.

Examples:

security practices may age quickly;
foundational writing may remain relevant longer;
product knowledge may decay after major architecture changes;
a completed contribution remains part of history even when its predictive relevance declines.

Negative evidence

Reputation cannot be credible if only positive events exist.

The graph may include:

rejected submissions;
missed milestones;
rollback events;
quality incidents;
unresolved disputes;
revoked credentials;
policy violations;
fraud findings.

Negative evidence requires proportionality, access control, source quality, correction rights, retention rules, and protection against retaliation.

ANUKA must not create a permanent public shame ledger.

Disputes and correction

A participant can challenge:

factual accuracy;
attribution;
review method;
metric interpretation;
identity linkage;
public visibility;
score or match output;
conflict of interest.

The graph should append dispute and resolution records rather than silently rewrite relied-upon history.

Anti-gaming controls

Threats include:

sybil accounts;
reciprocal review rings;
self-funded trivial bounties;
duplicated contributions;
fake organizations;
metric manipulation;
suppressing negative outcomes;
reviewer bribery;
copying prior work;
AI-generated volume without accountability.

Controls may include:

identity and organization assurance appropriate to reward size;
reviewer independence signals;
evidence-source verification;
duplicate detection;
graph anomaly detection;
reward caps for related parties;
challenge periods;
random or risk-based audits;
disclosed conflicts;
reputation impact for fraudulent attestations;
human review for high-impact enforcement.

Review reputation

Reviewers and qualifiers also need evidence.

Review quality may include:

agreement with later outcomes;
clarity of acceptance rationale;
false-positive and false-negative patterns;
turnaround time;
conflict disclosure;
overturned decisions;
subject-matter credentials;
participant feedback.

A reviewer cannot become trusted merely by issuing many reviews.

AI contribution attribution

AI assistance should be recorded at an appropriate level.

Possible labels:

human-authored;
AI-assisted;
agent-produced under human review;
agent-executed automatically;
mixed team contribution.

The participant remains responsible according to the applicable role and contract. AI usage alone should not reduce or increase reputation without evidence of outcome and review.

Public versus permissioned graph

The graph may contain:

public nodes and edges;
participant-controlled presentations;
organization-confidential work records;
restricted reviewer evidence;
legally retained payment or security records.

A public profile is a filtered view. The underlying graph must enforce authorization per record and edge.

Portability

Participants should be able to export:

their own contribution records;
credentials and attestations they hold;
public graph relationships;
machine-readable capability mappings;
dispute and correction records relevant to them;
provenance metadata necessary for independent verification.

Export does not grant rights to third-party confidential data.

Open Badges alignment

Open Badges 3.0 may represent discrete achievements or capabilities where criteria and evidence are sufficiently defined.

ANUKA should not issue decorative badges for every click. A portable achievement credential should correspond to a meaningful, reviewable accomplishment.

Graph API sketch

{
  "query": {
    "subject": "anuka:person:01J...",
    "capability": "anuka:capability:saas-onboarding",
    "timeRange": "P24M",
    "audience": "anuka:project:01J..."
  },
  "summary": {
    "acceptedContributions": 12,
    "reviewedOutcomes": 7,
    "independentReviewCount": 4,
    "disputes": {
      "resolved": 2,
      "pending": 1
    },
    "confidence": "moderate"
  },
  "evidence": [
    "anuka:contribution:01J...",
    "urn:uuid:credential-id"
  ],
  "limitations": [
    "Only 3 records are from products at the same stage",
    "No evidence newer than 6 months"
  ]
}

Employment and eligibility boundary

If ANUKA compiles or supplies dossiers or algorithmic scores about people for employment decisions, the service may fall within the Fair Credit Reporting Act depending on facts and use.

The CFPB has stated that third-party background dossiers and algorithmic worker scores used for hiring, promotion, reassignment, or retention are often governed by the FCRA. FTC and EEOC guidance also requires attention to accuracy, authorization, adverse-action procedures, and discrimination.

Therefore the initial product must:

emphasize participant-controlled portfolios and opportunity matching;
avoid selling opaque worker scores;
provide accuracy, dispute, and correction mechanisms from the start;
require a dedicated legal and compliance design before offering employment-screening reports;
prohibit automated adverse action based solely on an ANUKA summary.

Prohibited reputation patterns

ANUKA must not:

publish one universal score for a person;
rank people globally across unrelated contexts;
infer protected traits;
hide score inputs or material disputes;
reward volume without quality;
let companies delete unfavorable verified outcomes selectively;
expose private work records by default;
equate payment amount with social worth;
treat blockchain permanence as a reason to retain harmful personal data forever;
allow AI-generated reputation events without an accountable principal.

MVP acceptance criteria

The first graph release is ready when:

contribution, review, release, outcome, payment, dispute, and correction are separate event types;
participant, organization, product, agent, and evidence nodes are distinct;
summaries are capability- and context-specific;
every summary exposes sample size and evidence links;
public profiles are filtered views, not the raw graph;
participants can dispute attribution and factual accuracy;
related-party and reviewer conflicts can be disclosed;
accepted work does not automatically imply positive metric impact;
export is available for participant-controlled records;
no universal score exists in the schema or UI.

Sources

Verification record

Sources opened and checked: 2 August 2026
Reputation model status: Draft
Employment-screening legal review required before launch: Yes
Fairness, accuracy, dispute, and privacy testing required: Yes