teleo-codex/schemas/contributor.md

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

handle: "@naval"                    # primary identity (X handle preferred)
display_name: "Naval Ravikant"      # optional human-readable name; falls back to handle when null
kind: human                         # computed: human | agent
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"]

Kind Field — Agent vs Human

Every contributor record carries a kind field: either human or agent. This is computed by the pipeline from a maintained list of agent handles, not authored manually.

Why this matters: the leaderboard, contributor profile pages, and dossier views need to distinguish humans from agents because the contribution architecture treats them asymmetrically. Agents are drafters who execute against human direction; humans are originators, authors, synthesizers, and challengers. Conflating the two on a leaderboard tile mis-attributes credit.

Display rule: humans and agents render with the same component geometry (avatar + name + role chip) but never appear on the same ranked list. The contributor leaderboard is humans-only. Agents appear on a separate "Collective" surface that ranks by output, not by CI score.

Authoring rule (governance): agents only get sourcer/originator credit for pipeline PRs from their own research sessions. Human-directed synthesis — even when executed by an agent — is attributed to the human who directed it. This rule is enforced at attribution time, not at rendering time. The kind field exists to make the distinction visible, not to gate it.

Display Name

The optional display_name field carries a human-readable name (e.g. "Naval Ravikant" for handle @naval). When present, surfaces render display_name as the primary label with the handle as secondary metadata. When absent, the handle is the primary label.

display_name is authored, not computed. Sources:

• For humans who self-identify: pulled from their Dynamic profile or X bio when available
• For agents: their canonical display name (e.g. "Leo" for handle leo)
• Otherwise: null

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.