teleo-codex/core/contribution-architecture.md

Contribution Scoring & Attribution Architecture

How LivingIP measures, attributes, and rewards contributions to collective intelligence. This paper explains the why behind every design decision — the incentive structure, the attribution chain, and the governance implications of meritocratic contribution scoring.

1. Mechanism Design

The core problem

Collective intelligence systems need to answer: who made us smarter, and by how much? Get this wrong and you either reward volume over quality (producing noise), reward incumbency over contribution (producing stagnation), or fail to attribute at all (producing free-rider collapse).

Five contribution roles

Every piece of knowledge in the system traces back to people who played specific roles in producing it. We identify five, because the knowledge production pipeline has exactly five distinct bottlenecks:

Role	What they do	Why it matters
Sourcer	Identifies the source material or research direction	Without sourcers, agents have nothing to work with. The quality of inputs bounds the quality of outputs.
Extractor	Separates signal from noise, writes the atomic claim	Necessary but increasingly mechanical. LLMs do heavy lifting. The skill is judgment about what's worth extracting, not the extraction itself.
Challenger	Tests claims through counter-evidence or boundary conditions	The hardest and most valuable role. Challengers make existing knowledge better. A successful challenge that survives counter-attempts is the highest-value contribution because it improves what the collective already believes.
Synthesizer	Connects claims across domains, producing insight neither domain could see alone	Cross-domain connections are the unique output of collective intelligence. No single specialist produces these. Synthesis is where the system generates value that no individual contributor could.
Reviewer	Evaluates claim quality, enforces standards, approves or rejects	The quality gate. Without reviewers, the knowledge base degrades toward noise. Reviewing is undervalued in most systems — we weight it explicitly.

Why these weights

Challenger:   0.35
Synthesizer:  0.25
Reviewer:     0.20
Sourcer:      0.15
Extractor:    0.05

Challenger at 0.35 (highest): Improving existing knowledge is harder and more valuable than adding new knowledge. A challenge requires understanding the existing claim well enough to identify its weakest point, finding counter-evidence, and constructing an argument that survives adversarial review. Most challenges fail — the ones that succeed materially improve the knowledge base. The high weight incentivizes the behavior we want most: rigorous testing of what we believe.

Synthesizer at 0.25: Cross-domain insight is the collective's unique competitive advantage. No individual specialist sees the connection between GLP-1 persistence economics and futarchy governance design. A synthesizer who identifies a real cross-domain mechanism (not just analogy) creates knowledge that couldn't exist without the collective. This is the system's core value proposition, weighted accordingly.

Reviewer at 0.20: Quality gates are load-bearing infrastructure. Every claim that enters the knowledge base was approved by a reviewer. Bad claims that slip through degrade collective beliefs. The reviewer role was historically underweighted (0.10 in v0) because it's invisible — good reviewing looks like nothing happening. The increase to 0.20 reflects that review is skilled judgment work, not rubber-stamping.

Sourcer at 0.15: Finding the right material to analyze is real work with a skill ceiling — knowing where to look, what's worth reading, which research directions are productive. But sourcing doesn't transform the material. The sourcer identifies the ore; others refine it. 0.15 reflects genuine contribution without overweighting the input relative to the processing.

Extractor at 0.05 (lowest): Extraction — reading a source and producing claims from it — is increasingly mechanical. LLMs do the heavy lifting. The human/agent skill is in judgment about what to extract, which is captured by the sourcer role (directing the research mission) and reviewer role (evaluating what was extracted). The extraction itself is low-skill-ceiling work that scales with compute, not with expertise.

What the weights incentivize

The old weights (extractor at 0.40) incentivized: produce volume → high CI. This rewarded agents and contributors who processed the most sources regardless of whether the extracted claims were novel, accurate, or useful.

The new weights incentivize: challenge existing claims, synthesize across domains, review carefully → high CI. This rewards the behaviors that make the knowledge base better, not just bigger. A contributor who challenges one claim and wins contributes more CI than one who extracts twenty claims from a source.

This is deliberate: the system should reward quality over volume, depth over breadth, and improvement over accumulation.

2. Attribution Architecture

The knowledge chain

Every position traces back through a chain of evidence:

Source material → Claim → Belief → Position
     ↑               ↑        ↑         ↑
  sourcer        extractor  synthesizer  agent judgment
                 reviewer   challenger

Attribution records who contributed at each link. A claim's source: field traces to the original author. Its attribution block records who extracted, reviewed, challenged, and synthesized it. Beliefs cite claims. Positions cite beliefs. The entire chain is traversable — from a public position back to the original evidence and every contributor who shaped it along the way.

Three types of contributors

1. Source authors (external): The thinkers whose ideas the KB is built on. Nick Bostrom, Robin Hanson, metaproph3t, Dario Amodei, Matthew Ball. They contributed the raw intellectual material. Credited as sourcer — their work is the foundation even though they didn't interact with the system directly. Identified by parsing claim source: fields and matching against entity records.

2. Human operators (internal): People who direct agents, review outputs, set research missions, and exercise governance authority. Credited across all five roles depending on their activity. Their agents' work rolls up to them via the principal mechanism (see below).

3. Agents (infrastructure): AI agents that extract, synthesize, review, and evaluate. Credited individually for operational tracking, but their contributions attribute to their human principal for governance purposes.

Principal-agent attribution

A local agent (Rio, Clay, Theseus, etc.) operates on behalf of a human. The human directs research missions, sets priorities, and exercises judgment through the agent. The agent is an instrument of the human's intellectual contribution.

The principal field records this relationship:

Agent: rio    → Principal: m3taversal
Agent: clay   → Principal: m3taversal
Agent: theseus → Principal: m3taversal

Governance CI rolls up: m3taversal's CI = direct contributions + all agent contributions where principal = m3taversal.

VPS infrastructure agents (Epimetheus, Argus) have principal = null. They run autonomously on pipeline and monitoring tasks. Their work is infrastructure — it keeps the system running but doesn't produce knowledge. Infrastructure contributions are tracked separately and do not count toward governance CI.

Why this matters for multiplayer: When a second user joins with their own agents, their agents attribute to them. The principal mechanism scales without schema changes. Each human sees their full intellectual impact regardless of how many agents they employ.

Commit-type classification

Not all repository activity is knowledge contribution. The system distinguishes:

Type	Examples	CI weight
Knowledge	New claims, enrichments, challenges, synthesis, belief updates	Full weight (per role)
Pipeline	Source archival, auto-fix, entity batches, ingestion, queue management	Zero CI weight

Classification happens at merge time by checking which directories the PR touched. Files in domains/, core/, foundations/, decisions/ = knowledge. Files in inbox/, entities/ only = pipeline.

This prevents CI inflation from mechanical work. An agent that archives 100 sources earns zero CI. An agent that extracts 5 claims from those sources earns CI proportional to its role.

3. Pipeline Integration

The extraction → eval → merge → attribution chain

1. Source identified (sourcer credit)
2. Agent extracts claims on a branch (extractor credit)
3. PR opened against main
4. Tier-0 mechanical validation (schema, wiki links)
5. LLM evaluation (cross-domain + domain peer + self-review)
6. Reviewer approves or requests changes (reviewer credit)
7. PR merges
8. Post-merge: contributor table updated with role credits
9. Post-merge: claim embedded in Qdrant for semantic retrieval
10. Post-merge: source archive status updated

Where attribution data lives

• Git trailers (Pentagon-Agent: Rio <UUID>): who committed the change to the repository
• Claim YAML (attribution: block): who contributed what in which role on this specific claim
• Claim YAML (source: field): human-readable reference to the original source author
• Pipeline DB (contributors table): aggregated role counts, CI scores, principal relationships
• Pentagon agent config: principal mapping (which agents work for which humans)

These are complementary, not redundant. Git trailers answer "who made this commit." YAML attribution answers "who produced this knowledge." The contributors table answers "what is this person's total contribution." Pentagon config answers "who does this agent work for."

Forgejo as source of truth

The git repository is the canonical record. Pipeline DB is derived state — it can always be reconstructed from git history. If pipeline DB is lost, a backfill from git + Forgejo API restores all contributor data. This is deliberate: the source of truth is the one thing that survives platform migration.

4. Governance Implications

CI as governance weight

Contribution Index determines governance authority in a meritocratic system. Contributors who made the KB smarter have more influence over its direction. This is not democracy (one person, one vote) and not plutocracy (one dollar, one vote). It is epistocracy weighted by demonstrated contribution quality.

The governance model:

1. Agents operate at full speed — propose, review, merge, enrich. No human gates in the loop. Speed is a feature, not a risk.
2. Humans review asynchronously — browse diagnostics, read weekly reports, spot-check claims. When something looks wrong, flag it.
3. Flags carry weight based on CI — a veteran contributor's flag gets immediate attention. A new contributor's flag gets evaluated. High CI = earned authority.
4. Veto = rollback, not block — a human veto reverts a merged change rather than preventing it. The KB stays fast, corrections happen in the next cycle.

Progressive decentralization

Agents are under human control now. This is appropriate — the system is 20 days old. As agents demonstrate reliability (measured by error rate, flag frequency, and the ratio of accepted to rejected work), they earn increasing autonomy:

• Current: Agents integrate autonomously, humans can flag and veto after the fact.
• Near-term: Agents with clean track records earn reduced review requirements on routine work.
• Long-term: The principal relationship loosens for agents that consistently produce high-quality work. Eventually, some agents may operate without a principal.

The progression is not time-based ("after 6 months") but performance-based ("after N consecutive clean reviews"). The criteria for decentralization are themselves claims in the KB, subject to the same adversarial review as everything else.

The principal field supports this transition by being nullable. Setting principal = null removes the roll-up — the agent's contributions stand on their own. This is a human decision, not an algorithmic one. The data informs it; the human makes the call.

CI evolution roadmap

v1 (current): Role-weighted CI. Contribution scored by which roles you played. Incentivizes challenging, synthesizing, and reviewing over extracting.

v2 (next): Outcome-weighted CI. Did the challenge survive counter-attempts? Did the synthesis get cited by other claims? Did the extraction produce claims that passed review? Outcomes weight more than activity. Greater complexity earned, not designed.

v3 (future): Usage-weighted CI. Which claims actually get used in agent reasoning? How often? Contributions that produce frequently-referenced knowledge score higher than contributions that sit unread. This requires usage instrumentation infrastructure (claim_usage telemetry) currently being built.

Each layer adds a more accurate signal of real contribution value. The progression is: input → outcome → impact.

Connection to LivingIP

Contribution-weighted ownership is the core thesis of LivingIP. The CI system is the measurement layer that makes this possible. When contribution translates to governance authority, and governance authority translates to economic participation, the incentive loop closes: contribute knowledge → earn authority → direct capital → fund research → produce more knowledge.

The attribution architecture ensures this loop is traceable. Every dollar of economic value traces back through positions → beliefs → claims → sources → contributors. No contribution is invisible. No authority is unearned.

---

Architecture designed by Leo with input from Rhea (system architecture), Argus (data infrastructure), Epimetheus (pipeline integration), and Cory (governance direction). 2026-03-26.