# Contributor Schema

Contributors are people who have engaged with the knowledge base. A contributor profile is computed from attribution data across claims — not stored separately. This schema defines the profile structure and tier system.

## Contributor Tiers

Tiers determine how agents engage with a contributor. Tier is computed from contribution history, not self-declared.

| Tier | Criteria | Agent Behavior |
|------|----------|----------------|
| **visitor** | No contributions. First interaction. | Orientation mode: "What are you working on?" → match to agent → surface provocative claims → invite engagement. |
| **contributor** | ≥1 merged contribution (source, challenge, or claim) | Skip orientation. Reference their history. Engage with their specific expertise. "You challenged Rio's claim about Dutch auctions — that challenge is still standing. What are you working on now?" |
| **veteran** | ≥10 merged contributions AND ≥1 surviving challenge or belief influence | Peer engagement. Reference shared history. Invite to specific KB gaps matching their expertise. Ask for their take on open questions. Deeper context per interaction. |

**Tier transitions are automatic.** The system computes tier from contribution data. No manual promotion. No application process. Contribute, and the agents notice.

## Profile Structure

```yaml
handle: "@naval"                    # primary identity (X handle preferred)
tier: contributor                   # computed: visitor | contributor | veteran
linked_identities:                  # other identities for the same person
  - type: x
    handle: "@naval"
  - type: github
    handle: "naval"
  - type: email
    handle: "naval@example.com"
first_contribution: 2026-02-15
latest_contribution: 2026-03-11

# Role counts (from attribution frontmatter across all claims)
roles:
  sourcer: 12
  extractor: 0
  challenger: 3
  synthesizer: 1
  reviewer: 0

# Weighted score (role_counts × contribution-weights.yaml)
weighted_score: 5.4

# CI components (from reward-mechanism.md)
ci:
  belief_movers: 0.0
  challenge_champions: 2.1
  connection_finders: 0.8
  total: 1.22    # weighted sum per ci_weights

# Domain footprint
domains:
  internet-finance: 8
  grand-strategy: 5
  ai-alignment: 3

# Contribution highlights (for agent context loading)
highlights:
  - "Challenged futarchy redistribution claim — challenge survived 2 counter-attempts"
  - "Sourced 5 Theia Research pieces that produced 12 claims"
  - "Connected prediction market volume claim to AI alignment belief"

# Contribution timeline (monthly granularity)
timeline:
  - month: "2026-02"
    count: 3
    domains: ["internet-finance"]
  - month: "2026-03"
    count: 13
    domains: ["internet-finance", "grand-strategy"]
```

## Identity Resolution

**Primary identity: X handle.** X is the most likely first intake channel (people replying to claim tweets). The X handle is the canonical contributor identity.

**Linked identities:** A contributor may have multiple identities across platforms (X, GitHub, email, wallet). These link to a single profile. Identity linking happens:
- Automatically: same X handle appears in `proposed_by` (source) and git commits
- Manually: contributor requests linking via the website or direct engagement

**Pseudonymous-first.** Contributors use handles, not legal names. A handle persists across all contributions and is the public-facing identity.

## How Profiles Are Computed

Profiles are **derived, not stored** as primary data. The primary data is attribution frontmatter on claims and sources.

### Computation steps

1. **Scan all claims** for `attribution` blocks (see `schemas/attribution.md`)
2. **Scan all sources** for `proposed_by` field
3. **Group by handle** — aggregate role counts, domains, dates
4. **Apply weights** from `schemas/contribution-weights.yaml`
5. **Compute tier** from criteria above
6. **Generate highlights** — top 3 contributions by impact (belief changes, surviving challenges, cross-domain connections)

### Build artifact

The build pipeline produces `contributors.json` — a static file rebuilt on every merge to main. Agents and the website read this file. No runtime queries needed.

For agent session loading, a **contributor card** (compact summary) is extracted:

```
@naval | contributor | 16 contributions across internet-finance, grand-strategy
Highlights: challenged futarchy redistribution (survived), sourced 12 Theia claims
Last active: 2026-03-11
```

This card is injected into the agent's context at session start. ~50 tokens per contributor — cheap enough to load for any known contributor.

## Agent Context Loading

When a known contributor engages:

1. **Lookup:** Match their identity (X handle, email, etc.) against `contributors.json`
2. **Load card:** Inject contributor card into agent system prompt
3. **Adjust behavior:** Agent follows tier-appropriate engagement pattern (see tiers above)
4. **Reference history:** Agent can cite specific contributions, surviving challenges, domain expertise

When an unknown person engages:
1. **Default to visitor tier**
2. **Run orientation flow** (see CLAUDE.md visitor section)
3. **After first contribution:** profile is created, tier updates to contributor on next merge

## Person Entity Bridge

When a contributor has enough contributions to warrant tracking as an entity, their person entity (`entities/{domain}/{handle}.md`) gains `contributor: true`. The person entity tracks public information (role, organizations, influence). The contributor profile tracks KB-specific contribution data. Both link to each other.

## Governance

- Profiles are computed, not editable. To change your profile, change the underlying attribution data (via PR).
- Handle changes require updating attribution frontmatter across affected claims (PR review required).
- Disputes about attribution are resolved through the normal PR process.
- Contributor data is public. Contribution history is visible to all agents and users.