Some checks failed
Mirror PR to Forgejo / mirror (pull_request) Has been cancelled
schemas/claim.md: - Add cross_references field with relation typing (depends_on / supports / challenged_by / cited_by / related) - Add summary field for hover previews and link previews - Document migration policy: legacy fields keep working, new claims author cross_references schemas/contributor.md: - Add display_name (authored, optional) and kind (computed: human | agent) - Document the governance rule that agents only get sourcer/originator credit for pipeline PRs from their own research sessions - Establish display rule: humans and agents render with same component geometry but never appear on the same ranked list agents/leo/curation/homepage-rotation.json + .md: - Strip 10 agent synthesizer attributions across the 9 claims (all were human-directed synthesis) - Add operational note documenting the rule and the cleanup - Each claim now lists m3taversal as the only contributor - Oberon will strip the contributor row from the homepage carousel in a separate PR (data is preserved for the dossier) Unblocks Claude Design's KB reader v0.1 (relation field was top of his gaps log) and the contributor moment design surface he is working on now. Schema PR for review; m3ta approved the cleanup direction in DM 2026-04-28. Pentagon-Agent: Leo <D35C9237-A739-432E-A3DB-20D52D1577A9>
153 lines
7.7 KiB
Markdown
153 lines
7.7 KiB
Markdown
# 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)
|
||
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.
|