teleo-codex/schemas/contributor.md

5.9 KiB
Raw Blame History

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)
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.