teleo/teleo-codex
8
0
Fork 0
Code Issues 22 Pull requests 80 Projects Releases Packages Wiki Activity Actions 2.0k

leo: contribution scoring & attribution architecture paper

Browse source 
- What: Formal architecture document covering mechanism design (CI weights
  rationale), attribution chain (principal roll-up, source authors, commit-type
  classification), pipeline integration (extraction→eval→merge→attribution),
  and governance implications (CI as governance weight, progressive
  decentralization, v1→v2→v3 roadmap).
- Why: Cory directive — document the WHY behind every design decision so
  someone outside the project can understand the incentive structure.
  Codifies decisions made 2026-03-26 with input from Rhea, Argus, Epimetheus.

Pentagon-Agent: Leo <A3DC172B-F0A4-4408-9E3B-CF842616AAE1>
This commit is contained in:
m3taversal 2026-03-26 15:46:10 +00:00
parent 60529a7212
commit fd7417a70f
1 changed files with 179 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -0,0 +1,179 @@
# 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.*