teleo/teleo-codex
8
0
Fork 0
Code Issues 22 Pull requests 3 Projects Releases Packages Wiki Activity Actions 1

Merge remote-tracking branch 'forgejo/leo/contribution-architecture'

Browse source
This commit is contained in:
m3taversal 2026-04-01 16:41:30 +01:00
commit 1b57072117
1 changed files with 216 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

216
core/contribution-architecture.md Normal file
View file

@ -0,0 +1,216 @@
---
type: claim
domain: mechanisms
description: "Architecture paper defining the five contribution roles, their weights, attribution chain, and governance implications — supersedes the original reward-mechanism.md role weights and CI formula"
confidence: likely
source: "Leo, original architecture with Cory-approved weight calibration"
created: 2026-03-26
---
# 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.
### Relationship to reward-mechanism.md
This document supersedes specific sections of [[reward-mechanism]] while preserving others:
| Topic | reward-mechanism.md (v0) | This document (v1) | Change rationale |
|-------|-------------------------|---------------------|-----------------|
| **Role weights** | 0.25/0.25/0.25/0.15/0.10 (equal top-3) | 0.35/0.25/0.20/0.15/0.05 (challenger-heavy) | Equal weights incentivized volume over quality; bootstrap data showed extraction dominating CI |
| **CI formula** | 3 leaderboards (0.30 Belief + 0.30 Challenge + 0.40 Connection) | Single role-weighted aggregation per claim | Leaderboard model preserved as future display layer; underlying measurement simplified to role weights |
| **Source authors** | Citation only, not attribution | Credited as Sourcer (0.15 weight) | Their intellectual contribution is foundational; citation without credit understates their role |
| **Reviewer weight** | 0.10 | 0.20 | Review is skilled judgment work, not rubber-stamping; v0 underweighted it |
**What reward-mechanism.md still governs:** The three leaderboards (Belief Movers, Challenge Champions, Connection Finders), their scoring formulas, anti-gaming properties, and economic mechanism. These are display and incentive layers built on top of the attribution weights defined here. The leaderboard weights (0.30/0.30/0.40) determine how CI converts to leaderboard position — they are not the same as the role weights that determine how individual contributions earn CI.
## 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.25, equal to sourcer and challenger) incentivized volume because extraction was the easiest role to accumulate at scale. With equal weighting, an agent that extracted 100 claims earned the same per-unit CI as one that successfully challenged 5 — but the extractor could do it 20x faster. The bottleneck was throughput, not quality.
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** (0.15 weight) — 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.
*Change from v0:* reward-mechanism.md treated source authors as citation-only (referenced in evidence, not attributed). This understated their contribution — without their intellectual work, the claims wouldn't exist. The change to sourcer credit recognizes that identifying and producing the source material is real intellectual contribution, whether or not the author interacted with the system directly. The 0.15 weight is modest — it reflects that sourcing doesn't transform the material, but it does ground it.
**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.
**Concentration risk:** Currently all agents roll up to a single principal (m3taversal). This is expected during bootstrap — the system has one operator. But as more humans join, the roll-up must distribute. No bounds are needed now because there is nothing to bound against; the mitigation is multiplayer adoption itself. If concentration persists after the system has 3+ active principals, that is a signal to review whether the principal mechanism is working as designed.
### 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 (target state — some elements active now, others phased in):
1. **Agents operate at full speed** — propose, review, merge, enrich. No human gates in the loop. Speed is a feature, not a risk. *Current state: agents propose and review autonomously, but all PRs require review before merge (bootstrap phase). The "no human gates" principle means humans don't block the pipeline — they flag after the fact via veto.*
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. *Current state: CI scoring deployed but flag-weighting not yet implemented. All flags currently receive equal treatment.*
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.*
---
Relevant Notes:
- [[reward-mechanism]] — v0 incentive design (leaderboards, anti-gaming, economic mechanism); role weights and CI formula superseded by this document
- [[epistemology]] — knowledge structure the attribution chain operates on
- [[product-strategy]] — what we're building and why
- [[collective-agent-core]] — shared agent DNA that the principal mechanism builds on
Topics:
- [[overview]]