Compare commits

...

5 commits

Author SHA1 Message Date
91557d3bca clay: Project Hail Mary challenge to three-body oligopoly thesis
Some checks are pending
Sync Graph Data to teleo-app / sync (push) Waiting to run
Scope challenge — prestige adaptations with A-list talent may be a viable
fourth risk category that consolidation doesn't eliminate. Two resolutions
proposed: exception-that-proves-the-rule or scope-refinement needed.

First challenge filed using the new schemas/challenge.md from PR #2239.

Schema change: none. Additive — new challenge file + challenged_by update.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-01 22:44:48 +01:00
89c8e652f2 clay: ontology simplification — challenge schema + contributor guide
Some checks are pending
Sync Graph Data to teleo-app / sync (push) Waiting to run
Two-layer ontology: contributor-facing (3 concepts: claims, challenges,
connections) vs agent-internal (11 concepts). From 2026-03-26 ontology audit.

New files:
- schemas/challenge.md — first-class challenge type with strength rating,
  evidence chains, resolution tracking, and attribution
- core/contributor-guide.md — 3-concept contributor view (no frontmatter,
  pure documentation)

Modified files:
- schemas/claim.md — importance: null field (pipeline-computed, not manual),
  challenged_by accepts challenge filenames, structural importance section
  clarified as aspirational until pipeline ships
- ops/schema-change-protocol.md — challenge added to producer/consumer map

Schema Change:
Format affected: claim (modified), challenge (new)
Backward compatible: yes
Migration: none needed

Pentagon-Agent: Clay <3D549D4C-0129-4008-BF4F-FDD367C1D184>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-01 22:27:21 +01:00
1c40e07e0a clay: dashboard implementation spec for Oberon (#2237)
Co-authored-by: Clay <clay@agents.livingip.xyz>
Co-committed-by: Clay <clay@agents.livingip.xyz>
2026-04-01 21:02:26 +00:00
b5e0389de4 fix: add sources_verified to Paramount source archive (#2236)
Co-authored-by: Clay <clay@agents.livingip.xyz>
Co-committed-by: Clay <clay@agents.livingip.xyz>
2026-04-01 20:50:26 +00:00
2a0af07ca9 clay: Paramount/Skydance/WBD deal specifics — comprehensive source archive (#2235)
Co-authored-by: Clay <clay@agents.livingip.xyz>
Co-committed-by: Clay <clay@agents.livingip.xyz>
2026-04-01 20:42:23 +00:00
9 changed files with 1101 additions and 15 deletions

View file

@ -0,0 +1,428 @@
---
type: musing
agent: clay
title: "Dashboard implementation spec — build contract for Oberon"
status: developing
created: 2026-04-01
updated: 2026-04-01
tags: [design, dashboard, implementation, oberon, visual]
---
# Dashboard Implementation Spec
Build contract for Oberon. Everything here is implementation-ready — copy-pasteable tokens, measurable specs, named components with data shapes. Design rationale is in the diagnostics-dashboard-visual-direction musing (git history, commit 29096deb); this file is the what, not the why.
---
## 1. Design Tokens (CSS Custom Properties)
```css
:root {
/* ── Background ── */
--bg-primary: #0D1117;
--bg-surface: #161B22;
--bg-elevated: #1C2128;
--bg-overlay: rgba(13, 17, 23, 0.85);
/* ── Text ── */
--text-primary: #E6EDF3;
--text-secondary: #8B949E;
--text-muted: #484F58;
--text-link: #58A6FF;
/* ── Borders ── */
--border-default: #21262D;
--border-subtle: #30363D;
/* ── Activity type colors (semantic — never use these for decoration) ── */
--color-extract: #58D5E3; /* Cyan — pulling knowledge IN */
--color-new: #3FB950; /* Green — new claims */
--color-enrich: #D4A72C; /* Amber — strengthening existing */
--color-challenge: #F85149; /* Red-orange — adversarial */
--color-decision: #A371F7; /* Violet — governance */
--color-community: #6E7681; /* Muted blue — external input */
--color-infra: #30363D; /* Dark grey — ops */
/* ── Brand ── */
--color-brand: #6E46E5;
--color-brand-muted: rgba(110, 70, 229, 0.15);
/* ── Agent colors (for sparklines, attribution dots) ── */
--agent-leo: #D4AF37;
--agent-rio: #4A90D9;
--agent-clay: #9B59B6;
--agent-theseus: #E74C3C;
--agent-vida: #2ECC71;
--agent-astra: #F39C12;
/* ── Typography ── */
--font-mono: 'JetBrains Mono', 'IBM Plex Mono', 'Fira Code', monospace;
--font-size-xs: 10px;
--font-size-sm: 12px;
--font-size-base: 14px;
--font-size-lg: 18px;
--font-size-hero: 28px;
--line-height-tight: 1.2;
--line-height-normal: 1.5;
/* ── Spacing ── */
--space-1: 4px;
--space-2: 8px;
--space-3: 12px;
--space-4: 16px;
--space-5: 24px;
--space-6: 32px;
--space-8: 48px;
/* ── Layout ── */
--panel-radius: 6px;
--panel-padding: var(--space-5);
--gap-panels: var(--space-4);
}
```
---
## 2. Layout Grid
```
┌─────────────────────────────────────────────────────────────────────┐
│ HEADER BAR (48px fixed) │
│ [Teleo Codex] [7d | 30d | 90d | all] [last sync] │
├───────────────────────────────────────┬─────────────────────────────┤
│ │ │
│ TIMELINE PANEL (60%) │ SIDEBAR (40%) │
│ Stacked bar chart │ │
│ X: days, Y: activity count │ ┌─────────────────────┐ │
│ Color: activity type │ │ AGENT ACTIVITY (60%) │ │
│ │ │ Sparklines per agent │ │
│ Phase overlay (thin strip above) │ │ │ │
│ │ └─────────────────────┘ │
│ │ │
│ │ ┌─────────────────────┐ │
│ │ │ HEALTH METRICS (40%)│ │
│ │ │ 4 key numbers │ │
│ │ └─────────────────────┘ │
│ │ │
├───────────────────────────────────────┴─────────────────────────────┤
│ EVENT LOG (collapsible, 200px default height) │
│ Recent PR merges, challenges, milestones — reverse chronological │
└─────────────────────────────────────────────────────────────────────┘
```
### CSS Grid Structure
```css
.dashboard {
display: grid;
grid-template-rows: 48px 1fr auto;
grid-template-columns: 60fr 40fr;
gap: var(--gap-panels);
height: 100vh;
padding: var(--space-4);
background: var(--bg-primary);
font-family: var(--font-mono);
color: var(--text-primary);
}
.header {
grid-column: 1 / -1;
display: flex;
align-items: center;
justify-content: space-between;
padding: 0 var(--space-4);
border-bottom: 1px solid var(--border-default);
}
.timeline-panel {
grid-column: 1;
grid-row: 2;
background: var(--bg-surface);
border-radius: var(--panel-radius);
padding: var(--panel-padding);
overflow: hidden;
}
.sidebar {
grid-column: 2;
grid-row: 2;
display: flex;
flex-direction: column;
gap: var(--gap-panels);
}
.event-log {
grid-column: 1 / -1;
grid-row: 3;
background: var(--bg-surface);
border-radius: var(--panel-radius);
padding: var(--panel-padding);
max-height: 200px;
overflow-y: auto;
}
```
### Responsive Breakpoints
| Viewport | Layout |
|----------|--------|
| >= 1200px | 2-column grid as shown above |
| 768-1199px | Single column: timeline full-width, agent panel below, health metrics inline row |
| < 768px | Skip this is an ops tool, not designed for mobile |
---
## 3. Component Specs
### 3.1 Timeline Panel (stacked bar chart)
**Renders:** One bar per day. Segments stacked by activity type. Height proportional to daily activity count.
**Data shape:**
```typescript
interface TimelineDay {
date: string; // "2026-04-01"
extract: number; // count of extraction commits
new_claims: number; // new claim files added
enrich: number; // existing claims modified
challenge: number; // challenge claims or counter-evidence
decision: number; // governance/evaluation events
community: number; // external contributions
infra: number; // ops/config changes
}
```
**Bar rendering:**
- Width: `(panel_width - padding) / days_shown` with 2px gap between bars
- Height: proportional to sum of all segments, max bar = panel height - 40px (reserve for x-axis labels)
- Stack order (bottom to top): infra, community, extract, new_claims, enrich, challenge, decision
- Colors: corresponding `--color-*` tokens
- Hover: tooltip showing date + breakdown
**Phase overlay:** 8px tall strip above the bars. Color = phase. Phase 1 (bootstrap): `var(--color-brand-muted)`. Future phases TBD.
**Time range selector:** 4 buttons in header area — 7d | 30d | 90d | all. Default: 30d. Active button: `border-bottom: 2px solid var(--color-brand)`.
**Annotations:** Vertical dashed line at key events (e.g., "first external contribution"). Label rotated 90deg, `var(--text-muted)`, `var(--font-size-xs)`.
### 3.2 Agent Activity Panel
**Renders:** One row per agent, sorted by total activity last 7 days (most active first).
**Data shape:**
```typescript
interface AgentActivity {
name: string; // "rio"
display_name: string; // "Rio"
color: string; // var(--agent-rio) resolved hex
status: "active" | "idle"; // active if any commits in last 24h
sparkline: number[]; // 7 values, one per day (last 7 days)
total_claims: number; // lifetime claim count
recent_claims: number; // claims this week
}
```
**Row layout:**
```
┌───────────────────────────────────────────────────────┐
│ ● Rio ▁▂▅█▃▁▂ 42 (+3) │
└───────────────────────────────────────────────────────┘
```
- Status dot: 8px circle, `var(--agent-*)` color if active, `var(--text-muted)` if idle
- Name: `var(--font-size-base)`, `var(--text-primary)`
- Sparkline: 7 bars, each 4px wide, 2px gap, max height 20px. Color: agent color
- Claim count: `var(--font-size-sm)`, `var(--text-secondary)`. Delta in parentheses, green if positive
**Row styling:**
```css
.agent-row {
display: flex;
align-items: center;
gap: var(--space-3);
padding: var(--space-2) var(--space-3);
border-radius: 4px;
}
.agent-row:hover {
background: var(--bg-elevated);
}
```
### 3.3 Health Metrics Panel
**Renders:** 4 metric cards in a 2x2 grid.
**Data shape:**
```typescript
interface HealthMetrics {
total_claims: number;
claims_delta_week: number; // change this week (+/-)
active_domains: number;
total_domains: number;
open_challenges: number;
unique_contributors_month: number;
}
```
**Card layout:**
```
┌──────────────────┐
│ Claims │
│ 412 +12 │
└──────────────────┘
```
- Label: `var(--font-size-xs)`, `var(--text-muted)`, uppercase, `letter-spacing: 0.05em`
- Value: `var(--font-size-hero)`, `var(--text-primary)`, `font-weight: 600`
- Delta: `var(--font-size-sm)`, green if positive, red if negative, muted if zero
**Card styling:**
```css
.metric-card {
background: var(--bg-surface);
border: 1px solid var(--border-default);
border-radius: var(--panel-radius);
padding: var(--space-4);
}
```
**The 4 metrics:**
1. **Claims**`total_claims` + `claims_delta_week`
2. **Domains**`active_domains / total_domains` (e.g., "4/14")
3. **Challenges**`open_challenges` (red accent if > 0)
4. **Contributors**`unique_contributors_month`
### 3.4 Event Log
**Renders:** Reverse-chronological list of significant events (PR merges, challenges filed, milestones).
**Data shape (reuse from extract-graph-data.py `events`):**
```typescript
interface Event {
type: "pr-merge" | "challenge" | "milestone";
number?: number; // PR number
agent: string;
claims_added: number;
date: string;
}
```
**Row layout:**
```
2026-04-01 ● rio PR #2234 merged — 3 new claims (entertainment)
2026-03-31 ● clay Challenge filed — AI acceptance scope boundary
```
- Date: `var(--font-size-xs)`, `var(--text-muted)`, fixed width 80px
- Agent dot: 6px, agent color
- Description: `var(--font-size-sm)`, `var(--text-secondary)`
- Activity type indicator: left border 3px solid, activity type color
---
## 4. Data Pipeline
### Source
The dashboard reads from **two JSON files** already produced by `ops/extract-graph-data.py`:
1. **`graph-data.json`** — nodes (claims), edges (wiki-links), events (PR merges), domain_colors
2. **`claims-context.json`** — lightweight claim index with domain/agent/confidence
### Additional data needed (new script or extend existing)
A new `ops/extract-dashboard-data.py` (or extend `extract-graph-data.py --dashboard`) that produces `dashboard-data.json`:
```typescript
interface DashboardData {
generated: string; // ISO timestamp
timeline: TimelineDay[]; // last 90 days
agents: AgentActivity[]; // per-agent summaries
health: HealthMetrics; // 4 key numbers
events: Event[]; // last 50 events
phase: { current: string; since: string; };
}
```
**How to derive timeline data from git history:**
- Parse `git log --format="%H|%s|%ai" --since="90 days ago"`
- Classify each commit by activity type using commit message prefix patterns:
- `{agent}: add N claims``new_claims`
- `{agent}: enrich` / `{agent}: update``enrich`
- `{agent}: challenge``challenge`
- `{agent}: extract``extract`
- Merge commits with `#N``decision`
- Other → `infra`
- Bucket by date
- This extends the existing `extract_events()` function in extract-graph-data.py
### Deployment
Static JSON files generated on push to main (same GitHub Actions workflow that already syncs graph-data.json to teleo-app). Dashboard page reads JSON on load. No API, no websockets.
---
## 5. Tech Stack
| Choice | Rationale |
|--------|-----------|
| **Static HTML + vanilla JS** | Single page, no routing, no state management needed. Zero build step. |
| **CSS Grid + custom properties** | Layout and theming covered by the tokens above. No CSS framework. |
| **Chart rendering** | Two options: (a) CSS-only bars (div heights via `style="height: ${pct}%"`) for the stacked bars and sparklines — zero dependencies. (b) Chart.js if we want tooltips and animations without manual DOM work. Oberon's call — CSS-only is simpler, Chart.js is faster to iterate. |
| **Font** | JetBrains Mono via Google Fonts CDN. Fallback: system monospace. |
| **Dark mode only** | No toggle. `background: var(--bg-primary)` on body. |
---
## 6. File Structure
```
dashboard/
├── index.html # Single page
├── style.css # All styles (tokens + layout + components)
├── dashboard.js # Data loading + rendering
└── data/ # Symlink to or copy of generated JSON
├── dashboard-data.json
└── graph-data.json
```
Or integrate into teleo-app if Oberon prefers — the tokens and components work in any context.
---
## 7. Screenshot/Export Mode
For social media use (the dual-use case from the visual direction musing):
- A `?export=timeline` query param renders ONLY the timeline panel at 1200x630px (Twitter card size)
- A `?export=agents` query param renders ONLY the agent sparklines at 800x400px
- White-on-dark, no chrome, no header — just the data visualization
- These URLs can be screenshotted by a cron job for automated social posts
---
## 8. What This Does NOT Cover
- **Homepage graph + chat** — separate spec (homepage-visual-design.md), separate build
- **Claim network visualization** — force-directed graph for storytelling, separate from ops dashboard
- **Real-time updates** — static JSON is sufficient for current update frequency (~hourly)
- **Authentication** — ops dashboard is internal, served behind VPN or localhost
---
## 9. Acceptance Criteria
Oberon ships this when:
1. Dashboard loads from static JSON and renders all 4 panels
2. Time range selector switches between 7d/30d/90d/all
3. Agent sparklines render and sort by activity
4. Health metrics show current counts with weekly deltas
5. Event log shows last 50 events reverse-chronologically
6. Passes WCAG AA contrast ratios on all text (the token values above are pre-checked)
7. Screenshot export mode produces clean 1200x630 timeline images
---
→ FLAG @oberon: This is the build contract. Everything above is implementation-ready. Questions about design rationale → see the visual direction musing (git commit 29096deb). Questions about data pipeline → the existing extract-graph-data.py is the starting point; extend it for the timeline/agent/health data shapes described in section 4.
→ FLAG @leo: Spec complete. Covers tokens, grid, components, data pipeline, tech stack, acceptance criteria. This should unblock Oberon's frontend work.

View file

@ -0,0 +1,155 @@
---
type: musing
agent: clay
title: "Diagnostics dashboard visual direction"
status: developing
created: 2026-03-25
updated: 2026-03-25
tags: [design, visual, dashboard, communication]
---
# Diagnostics Dashboard Visual Direction
Response to Leo's design request. Oberon builds, Argus architects, Clay provides visual direction. Also addresses Cory's broader ask: visual assets that communicate what the collective is doing.
---
## Design Philosophy
**The dashboard should look like a Bloomberg terminal had a baby with a git log.** Dense, operational, zero decoration — but with enough visual structure that patterns are legible at a glance. The goal is: Cory opens this, looks for 3 seconds, and knows whether the collective is healthy, where activity is concentrating, and what phase we're in.
**Reference points:**
- Bloomberg terminal (information density, dark background, color as data)
- GitHub contribution graph (the green squares — simple, temporal, pattern-revealing)
- Grafana dashboards (metric panels, dark theme, no wasted space)
- NOT: marketing dashboards, Notion pages, anything with rounded corners and gradients
---
## Color System
Leo's suggestion (blue/green/yellow/red/purple/grey) is close but needs refinement. The problem with standard rainbow palettes: they don't have natural semantic associations, and they're hard to distinguish for colorblind users (~8% of men).
### Proposed Palette (dark background: #0D1117)
| Activity Type | Color | Hex | Rationale |
|---|---|---|---|
| **EXTRACT** | Cyan | `#58D5E3` | Cool — pulling knowledge IN from external sources |
| **NEW** | Green | `#3FB950` | Growth — new claims added to the KB |
| **ENRICH** | Amber | `#D4A72C` | Warm — strengthening existing knowledge |
| **CHALLENGE** | Red-orange | `#F85149` | Hot — adversarial, testing existing claims |
| **DECISION** | Violet | `#A371F7` | Distinct — governance/futarchy, different category entirely |
| **TELEGRAM** | Muted blue | `#6E7681` | Subdued — community input, not agent-generated |
| **INFRA** | Dark grey | `#30363D` | Background — necessary but not the story |
### Design rules:
- **Background:** Near-black (`#0D1117` — GitHub dark mode). Not pure black (too harsh).
- **Text:** `#E6EDF3` primary, `#8B949E` secondary. No pure white.
- **Borders/dividers:** `#21262D`. Barely visible. Structure through spacing, not lines.
- **The color IS the data.** No legends needed if color usage is consistent. Cyan always means extraction. Green always means new knowledge. A user who sees the dashboard 3 times internalizes the system.
### Colorblind safety:
The cyan/green/amber/red palette is distinguishable under deuteranopia (the most common form). Violet is safe for all types. I'd test with a simulator but the key principle: no red-green adjacency without a shape or position differentiator.
---
## Layout: The Three Panels
### Panel 1: Timeline (hero — 60% of viewport width)
**Stacked bar chart, horizontal time axis.** Each bar = 1 day. Segments stacked by activity type (color-coded). Height = total commits/claims.
**Why stacked bars, not lines:** Lines smooth over the actual data. Stacked bars show composition AND volume simultaneously. You see: "Tuesday was a big day and it was mostly extraction. Wednesday was quiet. Thursday was all challenges." That's the story.
**X-axis:** Last 30 days by default. Zoom controls (7d / 30d / 90d / all).
**Y-axis:** Commit count or claim count (toggle). No label needed — the bars communicate scale.
**The phase narrative overlay:** A thin horizontal band above the timeline showing which PHASE the collective was in at each point. Phase 1 (bootstrap) = one color, Phase 2 (community) = another. This is the "where are we in the story" context layer.
**Annotations:** Key events (PR milestones, new agents onboarded, first external contribution) as small markers on the timeline. Sparse — only structural events, not every merge.
### Panel 2: Agent Activity (25% width, right column)
**Vertical list of agents, each with a horizontal activity sparkline** (last 7 days). Sorted by recent activity — most active agent at top.
Each agent row:
```
[colored dot: active/idle] Agent Name ▁▂▅█▃▁▂ [claim count]
```
The sparkline shows activity pattern. A user sees instantly: "Rio has been busy all week. Clay went quiet Wednesday. Theseus had a spike yesterday."
**Click to expand:** Shows that agent's recent commits, claims proposed, current task. But collapsed by default — the sparkline IS the information.
### Panel 3: Health Metrics (15% width, far right or bottom strip)
**Four numbers. That's it.**
| Metric | What it shows |
|---|---|
| **Claims** | Total claim count + delta this week (+12) |
| **Domains** | How many domains have activity this week (3/6) |
| **Challenges** | Open challenges pending counter-evidence |
| **Contributors** | Unique contributors this month |
These are the vital signs. If Claims is growing, Domains is distributed, Challenges exist, and Contributors > 1, the collective is healthy. Any metric going to zero is a red flag visible in 1 second.
---
## Dual-Use: Dashboard → External Communication
This is the interesting part. Three dashboard elements that work as social media posts:
### 1. The Timeline Screenshot
A cropped screenshot of the timeline panel — "Here's what 6 AI domain specialists produced this week" — is immediately shareable. The stacked bars tell a visual story. Color legend in the caption, not the image. This is the equivalent of GitHub's contribution graph: proof of work, visually legible.
**Post format:** Timeline image + 2-3 sentence caption identifying the week's highlights. "This week the collective processed 47 sources, proposed 23 new claims, and survived 4 challenges. The red bar on Thursday? Someone tried to prove our futarchy thesis wrong. It held."
### 2. The Agent Activity Sparklines
Cropped sparklines with agent names — "Meet the team" format. Shows that these are distinct specialists with different activity patterns. The visual diversity (some agents spike, some are steady) communicates that they're not all doing the same thing.
### 3. The Claim Network (not in the dashboard, but should be built)
A force-directed graph of claims with wiki-links as edges. Color by domain. Size by structural importance (the PageRank score I proposed in the ontology review). This is the hero visual for external communication — it looks like a brain, it shows the knowledge structure, and every node is clickable.
**This should be a separate page, not part of the ops dashboard.** The dashboard is for operators. The claim network is for storytelling. But they share the same data and color system.
---
## Typography
- **Monospace everywhere.** JetBrains Mono or IBM Plex Mono. This is a terminal aesthetic, not a marketing site.
- **Font sizes:** 12px body, 14px panel headers, 24px hero numbers. That's the entire scale.
- **No bold except metric values.** Information hierarchy through size and color, not weight.
---
## Implementation Notes for Oberon
1. **Static HTML + vanilla JS.** No framework needed. This is a single-page data display.
2. **Data source:** JSON files generated from git history + claim frontmatter. Same pipeline that produces `contributors.json` and `graph-data.json`.
3. **Chart library:** If needed, Chart.js or D3. But the stacked bars are simple enough to do with CSS grid + calculated heights if you want zero dependencies.
4. **Refresh:** On page load from static JSON. No websockets, no polling. The data updates when someone pushes to main (~hourly at most).
5. **Dark mode only.** No light mode toggle. This is an ops tool, not a consumer product.
---
## The Broader Visual Language
Cory's ask: "Posts with pictures perform better. We need diagrams, we need art."
The dashboard establishes a visual language that should extend to all Teleo visual communication:
1. **Dark background, colored data.** The dark terminal aesthetic signals: "this is real infrastructure, not a pitch deck."
2. **Color = meaning.** The activity type palette (cyan/green/amber/red/violet) becomes the brand palette. Every visual uses the same colors for the same concepts.
3. **Information density over decoration.** Every pixel carries data. No stock photos, no gradient backgrounds, no decorative elements. The complexity of the information IS the visual.
4. **Monospace type signals transparency.** "We're showing you the raw data, not a polished narrative." This is the visual equivalent of the epistemic honesty principle.
**Three visual asset types to develop:**
1. **Dashboard screenshots** — proof of collective activity (weekly cadence)
2. **Claim network graphs** — the knowledge structure (monthly or on milestones)
3. **Reasoning chain diagrams** — evidence → claim → belief → position for specific interesting cases (on-demand, for threads)
→ CLAIM CANDIDATE: Dark terminal aesthetics in AI product communication signal operational seriousness and transparency, differentiating from the gradient-and-illustration style of consumer AI products.

66
core/contributor-guide.md Normal file
View file

@ -0,0 +1,66 @@
# Contributor Guide
Three concepts. That's it.
## Claims
A claim is a statement about how the world works, backed by evidence.
> "Legacy media is consolidating into three dominant entities because debt-loaded incumbents cannot compete with cash-rich tech companies for content rights"
Claims have confidence levels: proven, likely, experimental, speculative. Every claim cites its evidence. Every claim can be wrong.
**Browse claims:** Look in `domains/{domain}/` — each domain has dozens of claims organized by topic. Start with whichever domain matches your expertise.
## Challenges
A challenge is a counter-argument against a specific claim.
> "The AI content acceptance decline may be scope-bounded to entertainment — reference and analytical AI content shows no acceptance penalty"
Challenges are the highest-value contribution. If you think a claim is wrong, too broad, or missing evidence, file a challenge. The claim author must respond — they can't ignore it.
Three types:
- **Full challenge** — the claim is wrong, here's why
- **Scope challenge** — the claim is true in context X but not Y
- **Evidence challenge** — the evidence doesn't support the confidence level
**File a challenge:** Create a file in `domains/{domain}/challenge-{slug}.md` following the challenge schema, or tell an agent your counter-argument and they'll draft it for you.
## Connections
Connections are the links between claims. When claim A depends on claim B, or challenges claim C, those relationships form a knowledge graph.
You don't create connections as standalone files — they emerge from wiki links (`[[claim-name]]`) in claim and challenge bodies. But spotting a connection no one else has seen is a genuine contribution. Cross-domain connections (a pattern in entertainment that also appears in finance) are the most valuable.
**Spot a connection:** Tell an agent. They'll draft the cross-reference and attribute you.
---
## What You Don't Need to Know
The system has 11 internal concept types (beliefs, positions, convictions, entities, sectors, sources, divergences, musings, attribution, contributors). Agents use these to organize their reasoning, track companies, and manage their workflow.
You don't need to learn any of them. Claims, challenges, and connections are the complete interface for contributors. Everything else is infrastructure.
## How Credit Works
Every contribution is attributed. Your name stays on everything you produce or improve. The system tracks five roles:
| Role | What you did |
|------|-------------|
| Sourcer | Pointed to material worth analyzing |
| Extractor | Turned source material into a claim |
| Challenger | Filed counter-evidence against a claim |
| Synthesizer | Connected claims across domains |
| Reviewer | Evaluated claim quality |
You can hold multiple roles on the same claim. Credit is proportional to impact — a challenge that changes a high-importance claim earns more than a new speculative claim in an empty domain.
## Getting Started
1. **Browse:** Pick a domain. Read 5-10 claims. Find one you disagree with or know something about.
2. **React:** Tell an agent your reaction. They'll help you figure out if it's a challenge, a new claim, or a connection.
3. **Approve:** The agent drafts; you review and approve before anything gets published.
Nothing enters the knowledge base without your explicit approval. The conversation itself is valuable even if you never file anything.

View file

@ -0,0 +1,71 @@
---
type: challenge
target: "legacy media is consolidating into three surviving entities because the Warner-Paramount merger eliminates the fourth independent major and forecloses alternative industry structures"
domain: entertainment
description: "The three-body oligopoly thesis implies franchise IP dominates creative strategy, but the largest non-franchise opening of 2026 suggests prestige adaptations remain viable tentpole investments"
status: open
strength: moderate
source: "Clay — analysis of Project Hail Mary theatrical performance vs consolidation thesis predictions"
created: 2026-04-01
resolved: null
---
# The three-body oligopoly thesis understates original IP viability in the prestige adaptation category
## Target Claim
[[legacy media is consolidating into three surviving entities because the Warner-Paramount merger eliminates the fourth independent major and forecloses alternative industry structures]] — Post-merger, legacy media resolves into Disney, Netflix, and Warner-Paramount, creating a three-body oligopoly with distinct structural profiles that forecloses alternative industry structures.
**Current confidence:** likely
## Counter-Evidence
Project Hail Mary (2026) is the largest non-franchise opening of the year — a single-IP, author-driven prestige adaptation with no sequel infrastructure, no theme park tie-in, no merchandise ecosystem. It was greenlit as a tentpole-budget production based on source material quality and talent attachment alone.
This performance challenges a specific implication of the three-body oligopoly thesis: that consolidated studios will optimize primarily for risk-minimized franchise IP because the economic logic of merger-driven debt loads demands predictable revenue streams. If that were fully true, tentpole-budget original adaptations would be the first casualty of consolidation — they carry franchise-level production costs without franchise-level floor guarantees.
Key counter-evidence:
- **Performance floor exceeded franchise comparables** — opening above several franchise sequels released in the same window, despite no built-in audience from prior installments
- **Author-driven, not franchise-driven** — Andy Weir's readership is large but not franchise-scale; this is closer to "prestige bet" than "IP exploitation"
- **Ryan Gosling attachment as risk mitigation** — talent-driven greenlighting (star power substituting for franchise recognition) is a different risk model than franchise IP, but it's not a dead model
- **No sequel infrastructure** — standalone story, no cinematic universe setup, no announced follow-up. The investment thesis was "one great movie" not "franchise launch"
## Scope of Challenge
**Scope challenge** — the claim's structural analysis (consolidation into three entities) is correct, but the implied creative consequence (franchise IP dominates, original IP is foreclosed) is overstated. The oligopoly thesis describes market structure accurately; the creative strategy implications need a carve-out.
Specifically: prestige adaptations with A-list talent attachment may function as a **fourth risk category** alongside franchise IP, sequel/prequel, and licensed remake. The three-body structure doesn't eliminate this category — it may actually concentrate it among the three survivors, who are the only entities with the capital to take tentpole-budget bets on non-franchise material.
## Two Possible Resolutions
1. **Exception that proves the rule:** Project Hail Mary was greenlit pre-merger under different risk calculus. As debt loads from the Warner-Paramount combination pressure the combined entity, tentpole-budget original adaptations get squeezed out in favor of IP with predictable floors. One hit doesn't disprove the structural trend — Hail Mary is the last of its kind, not the first of a new wave.
2. **Scope refinement needed:** The oligopoly thesis accurately describes market structure but overgeneralizes to creative strategy. Consolidated studios still have capacity and incentive for prestige tentpoles because (a) they need awards-season credibility for talent retention, (b) star-driven original films serve a different audience segment than franchise IP, and (c) the occasional breakout original validates the studio's curatorial reputation. The creative foreclosure is real for mid-budget original IP, not tentpole prestige.
## What This Would Change
If accepted (scope refinement), the target claim would need:
- An explicit carve-out noting that consolidation constrains mid-budget original IP more than tentpole prestige adaptations
- The "forecloses alternative industry structures" language softened to "constrains" or "narrows"
Downstream effects:
- [[media consolidation reducing buyer competition for talent accelerates creator economy growth as an escape valve for displaced creative labor]] — talent displacement may be more selective than the current claim implies if prestige opportunities persist for A-list talent
- [[the media attractor state is community-filtered IP with AI-collapsed production costs where content becomes a loss leader for the scarce complements of fandom community and ownership]] — the "alternative to consolidated media" framing is slightly weakened if consolidated media still produces high-quality original work
## Resolution
**Status:** open
**Resolved:** null
**Summary:** null
---
Relevant Notes:
- [[legacy media is consolidating into three surviving entities because the Warner-Paramount merger eliminates the fourth independent major and forecloses alternative industry structures]] — target claim
- [[media consolidation reducing buyer competition for talent accelerates creator economy growth as an escape valve for displaced creative labor]] — downstream: talent displacement selectivity
- [[Warner-Paramount combined debt exceeding annual revenue creates structural fragility against cash-rich tech competitors regardless of IP library scale]] — the debt load that should pressure against original IP bets
- [[the media attractor state is community-filtered IP with AI-collapsed production costs where content becomes a loss leader for the scarce complements of fandom community and ownership]] — alternative model contrast
Topics:
- [[web3 entertainment and creator economy]]
- entertainment

View file

@ -9,7 +9,8 @@ created: 2026-04-01
depends_on:
- "media disruption follows two sequential phases as distribution moats fall first and creation moats fall second"
- "streaming churn may be permanently uneconomic because maintenance marketing consumes up to half of average revenue per user"
challenged_by: []
challenged_by:
- "challenge-three-body-oligopoly-understates-original-ip-viability-in-prestige-adaptation-category"
---
# Legacy media is consolidating into three surviving entities because the Warner-Paramount merger eliminates the fourth independent major and forecloses alternative industry structures

View file

@ -1,15 +1,18 @@
---
type: source
title: "Paramount/Skydance/Warner Bros Discovery Merger Research"
title: "Paramount/Skydance/Warner Bros Discovery Merger — Deal Specifics & Timeline"
author: "Clay (multi-source synthesis)"
date: 2026-04-01
domain: entertainment
format: research
intake_tier: research-task
rationale: "Record the full deal mechanics, timeline, competing bids, financing structure, and regulatory landscape of the largest entertainment merger in history while events are live"
status: processed
processed_by: "Clay"
processed_date: 2026-04-01
tags: [media-consolidation, mergers, legacy-media, streaming, IP-strategy]
tags: [media-consolidation, mergers, legacy-media, streaming, IP-strategy, regulatory, antitrust]
contributor: "Cory Abdalla"
sources_verified: 2026-04-01
claims_extracted:
- "legacy media is consolidating into three surviving entities because the Warner-Paramount merger eliminates the fourth independent major and forecloses alternative industry structures"
- "Warner-Paramount combined debt exceeding annual revenue creates structural fragility against cash-rich tech competitors regardless of IP library scale"
@ -19,28 +22,199 @@ enrichments:
- "community-owned IP has structural advantage in human-made premium because provenance is inherent and legible"
---
# Paramount/Skydance/Warner Bros Discovery Merger Research
# Paramount / Skydance / Warner Bros Discovery — Deal Specifics
Multi-source synthesis of the Paramount-Skydance acquisition and subsequent Warner Bros Discovery merger, covering deal structure, regulatory landscape, and strategic implications for the entertainment industry.
Comprehensive record of the two-stage entertainment mega-merger: Skydance's acquisition of Paramount Global (20242025) and the subsequent Paramount Skydance acquisition of Warner Bros Discovery (20252026).
## Key Events
---
### Act 1: Skydance Takes Paramount (2024-2025)
## Act 1: Skydance Takes Paramount (20242025)
After months of competing bids (Apollo, Sony/Apollo), Shari Redstone sold National Amusements to David Ellison's Skydance, ending decades of Redstone family control. Competing bids failed because: Sony/Apollo had antitrust risk (two major studios combining), Apollo was too debt-heavy, and Redstone preferred a clean exit. Deal closed Q1 2025. "New Paramount" under Ellison began operating.
### Key Players
### Act 2: Warner-Paramount Merger (2025-2026)
- **Shari Redstone** — Chair of National Amusements Inc. (NAI), which held 77% voting power in Paramount Global via supervoting shares. Ended the Redstone family dynasty that began with Sumner Redstone.
- **David Ellison** — CEO of Skydance Media, became Chairman & CEO of combined entity.
- **Larry Ellison** — David's father, Oracle co-founder. Primary financial backer.
- **Gerry Cardinale** — RedBird Capital Partners. Skydance's existing investor and deal partner.
- **Jeff Shell** — Named President of combined Paramount.
June 2025: WBD announced plans to split into two companies (studios/streaming vs linear networks). Late 2025: Bidding war — Paramount/Skydance, Netflix, and Comcast all circled WBD. December 2025: WBD signed merger agreement with Netflix (focused on studios/streaming). Paramount launched rival all-cash tender offer. February 26, 2026: WBD board declared Paramount's offer superior. Netflix declined to match. March 5, 2026: Definitive agreement signed. The combined entity represents the largest media merger in history by enterprise value.
### Timeline
| Date | Event |
|------|-------|
| 20232024 | NAI explores sale options; multiple suitors approach |
| July 2, 2024 | Preliminary agreement for three-way merger (Skydance + NAI + Paramount Global) |
| Aug 2024 | Edgar Bronfman Jr. submits competing $6B bid; rejected on financing certainty |
| Feb 2025 | SEC and European Commission approve transaction |
| July 24, 2025 | FCC approves merger |
| Aug 1, 2025 | Skydance announces closing date |
| **Aug 7, 2025** | **Deal closes. "New Paramount" begins operating.** |
### Deal Structure
- NAI shareholders received $1.75 billion in cash for Redstone family shares.
- Total merger valued at $8 billion. Ellison family controls combined entity, which remains publicly traded.
- Paramount restructured into three divisions: **Studios**, **Direct-to-Consumer**, **TV Media**.
- $2 billion cost synergies target — Ellison expressed "greater confidence in our ability to not only achieve — but meaningfully exceed" that figure through single technology platform transition.
### Competing Bidders (Who Lost and Why)
| Bidder | Why They Lost |
|--------|---------------|
| **Sony / Apollo** | Antitrust risk — combining two major studios. Did not advance to binding offer. |
| **Apollo Global** (solo) | Too debt-heavy. Redstone preferred clean exit with operational vision. |
| **Edgar Bronfman Jr.** | Late $6B bid. Paramount special committee deemed Skydance deal superior on financing certainty. |
| **Barry Diller / IAC** | Expressed interest but never submitted competitive final bid. |
---
## Act 2: Paramount Acquires Warner Bros Discovery (20252026)
### The WBD Split Decision
In mid-2025, Warner Bros Discovery announced plans to **split into two separate companies**:
1. **Warner Bros** — film/TV studios, HBO, HBO Max, streaming assets (the valuable part)
2. **Discovery Global** — linear cable networks (HGTV, Discovery Channel, TLC, Food Network) to be spun off as separate public company
This split was designed to unlock value and set the stage for a sale of the studios/streaming business.
### Bidding War — Three Rounds
**Round 1: Non-Binding Proposals (November 20, 2025)**
| Bidder | Bid Structure |
|--------|---------------|
| **Paramount Skydance** | $25.50/share for the **entire company** (no split required) |
| **Netflix** | Bid for Warner Bros studios/IP, HBO, HBO Max (post-split assets only) |
| **Comcast** | Similar to Netflix — bid for studios/streaming assets only |
**Round 2: Binding Bids (December 1, 2025)**
| Bidder | Bid Structure |
|--------|---------------|
| **Paramount Skydance** | Raised to all-cash **$26.50/share** for entire company |
| **Netflix** | Undisclosed improved bid for post-split Warner Bros |
| **Comcast** | Undisclosed improved bid |
**Round 3: Netflix Wins Initial Deal (December 5, 2025)**
Netflix and WBD signed a definitive merger agreement:
- **$27.75/share** ($23.25 cash + $4.50 in Netflix stock per share)
- **$82.7 billion** enterprise value (**$72 billion** equity value)
- Netflix secured a **$59 billion bridge loan** (including $5B revolving credit + two $10B delayed-draw term loans)
- Deal structured around post-split Warner Bros (studios, HBO, HBO Max)
- WBD board recommended the Netflix deal to shareholders
**Round 4: Paramount's Superior Counter (JanuaryFebruary 2026)**
Paramount launched an aggressive counter-offer:
- **All-cash tender offer at $31.00/share** for ALL outstanding WBD shares (entire company, no split)
- Larry Ellison provided a **$40.4 billion "irrevocable personal guarantee"** backing the offer
- **$47 billion in equity** financing, fully backed by Ellison Family + RedBird Capital
- Included payment of WBD's **$2.8 billion termination fee** owed to Netflix
- **$7 billion regulatory termination fee** if deal fails on regulatory grounds
**February 26, 2026**: WBD board declared Paramount's revised offer a **"Company Superior Proposal"** under the merger agreement terms.
Netflix declined to match.
**March 5, 2026**: Definitive merger agreement signed between Paramount Skydance and Warner Bros Discovery.
### Deal Terms — Final
| Metric | Value |
|--------|-------|
| Per-share price | $31.00 (all cash) |
| Equity value | $81 billion |
| Enterprise value | $110.9 billion |
| Financing | $47B equity (Ellison/RedBird), remainder debt |
| Netflix termination fee | $2.8B (Paramount pays) |
| Regulatory break fee | $7B (if regulators block) |
| Synergies target | $6 billion+ |
| Ticking fee | $0.25/share/quarter if not closed by Sep 30, 2026 |
### Combined Entity Profile
Franchises: Harry Potter, DC, Game of Thrones, Mission: Impossible, Top Gun, Star Trek, SpongeBob, Yellowstone, HBO prestige catalog. Streaming: Max + Paramount+ merging into single platform (~200M subscribers). The largest combined IP library in entertainment history. However, the combined entity carries massive long-term debt — the largest debt load of any media company.
**Working name:** Warner-Paramount (official name not yet confirmed)
### Regulatory Status (as of April 2026)
**Leadership:** David Ellison, Chairman & CEO
DOJ will not fast-track; subpoenas issued but most antitrust experts don't expect a block. FCC under pressure from 7 Democratic senators demanding foreign investment review — deal involves sovereign wealth fund money and Tencent exposure. California AG promising investigation. WBD shareholder vote scheduled April 23, 2026. Expected close Q3 2026.
**Combined IP portfolio — the largest in entertainment history:**
- **Warner Bros:** Harry Potter, DC (Batman, Superman, Wonder Woman), Game of Thrones / House of the Dragon, The Matrix, Looney Tunes
- **HBO:** Prestige catalog (The Sopranos, The Wire, Succession, The Last of Us, White Lotus)
- **Paramount Pictures:** Mission: Impossible, Top Gun, Transformers, Indiana Jones
- **Paramount TV:** Star Trek, Yellowstone, SpongeBob/Nickelodeon universe
- **CNN, TBS, TNT, HGTV, Discovery Channel** (linear networks)
**Streaming:** Max + Paramount+ merging into single platform. Combined ~200 million subscribers. Positions as credible third force behind Netflix (400M+) and Disney+ (~150M).
**Financial profile:**
- Projected $18 billion annual EBITDA
- **$79 billion long-term debt** ($33B assumed from WBD + Paramount's existing obligations + deal financing)
- Largest debt load of any media company globally
- Debt-to-EBITDA ratio elevated; credit rating implications pending
---
## Regulatory Landscape (as of April 1, 2026)
### Federal — DOJ Antitrust
- **Hart-Scott-Rodino (HSR) Act** 10-day statutory waiting period expired **February 19, 2026** without DOJ filing a motion to block. Widely interpreted as an initial positive signal.
- DOJ antitrust chief stated deal will **"absolutely not"** be fast-tracked for political reasons.
- **Subpoenas issued** — signaling deeper investigation phase.
- Most antitrust experts do not expect an outright block, given the companies operate primarily in content production (not distribution monopoly).
### Federal — FCC
- **FCC Chairman Brendan Carr** told CNBC the Paramount offer is a **"good deal"** and **"cleaner"** than Netflix's, indicating it will be approved **"quickly"**.
- However, **7 Democratic senators** demanded a **"thorough review"** of foreign investment stakes, citing:
- **Saudi Arabian** sovereign wealth fund involvement
- **Qatari** sovereign wealth fund involvement
- **UAE** sovereign wealth fund involvement
- **Tencent** (Chinese gaming/internet conglomerate) — existing stake in Skydance Media (~7-10%)
- The foreign investment review is a political pressure campaign; FCC Chair's public comments suggest it won't delay approval.
### State — California AG
- **Rob Bonta** (California Attorney General) has opened a **"vigorous"** investigation.
- California DOJ has an active investigation, though state AGs rarely block major media mergers.
### Shareholder Approval
- **WBD shareholder vote:** April 23, 2026 at 10:00 AM Eastern.
- Expected to pass given the $31/share premium and board's "superior proposal" determination.
### Expected Timeline
- **Close target:** Q3 2026
- **If delayed past Sep 30, 2026:** Ticking fee of $0.25/share/quarter kicks in
- **Overall regulatory window:** 618 months from agreement signing
---
## Why Paramount Won Over Netflix
1. **All-cash vs mixed consideration.** Paramount offered pure cash; Netflix offered cash + stock (exposing WBD shareholders to Netflix equity risk).
2. **Whole company vs post-split.** Paramount bid for the entire company (including linear networks), avoiding the complexity and value destruction of the WBD split.
3. **Higher price.** $31.00 vs $27.75 — an 11.7% premium per share.
4. **Irrevocable guarantee.** Larry Ellison's $40.4B personal guarantee provided deal certainty that Netflix's $59B bridge loan structure couldn't match.
5. **Regulatory simplicity.** FCC Chair explicitly called Paramount's structure "cleaner." Netflix acquiring WBD studios would have combined #1 and #3 streaming platforms, raising more acute market concentration concerns.
---
## Sources
Multiple news sources, financial analyses, and regulatory filings consulted across Reuters, Bloomberg, Variety, The Hollywood Reporter, and SEC filings. Deal terms and regulatory status verified across multiple independent sources.
- [Paramount press release: merger announcement](https://www.paramount.com/press/paramount-to-acquire-warner-bros-discovery-to-form-next-generation-global-media-and-entertainment-company)
- [WBD board declares Paramount's offer "Company Superior Proposal"](https://ir.wbd.com/news-and-events/financial-news/financial-news-details/2026/Warner-Bros--Discovery-Board-of-Directors-Determines-Revised-Proposal-from-Paramount-Skydance-Constitutes-a-Company-Superior-Proposal/default.aspx)
- [Netflix original WBD acquisition announcement](http://about.netflix.com/en/news/netflix-to-acquire-warner-bros)
- [Variety: Netflix declines to raise bid](https://variety.com/2026/tv/news/netflix-declines-raise-bid-warner-bros-discovery-1236674149/)
- [Variety: DOJ will not fast-track](https://variety.com/2026/film/news/doj-paramount-warner-bros-deal-review-fast-track-review-political-reasons-1236693308/)
- [Variety: Senators demand FCC foreign investment review](https://variety.com/2026/tv/news/senators-demand-fcc-foreign-investment-review-paramount-warner-bros-deal-1236696679/)
- [CNBC: FCC Chair Carr on deal approval](https://www.cnbc.com/2026/03/03/fcc-chair-brendan-carr-wbd-paramount-merger-deal-netflix.html)
- [CNBC: Netflix WBD bridge loan](https://www.cnbc.com/2025/12/22/netflix-warner-bros-discovery-bridge-loan.html)
- [Variety: Skydance closes $8B Paramount acquisition](https://variety.com/2025/tv/news/paramount-skydance-deal-closes-1236477281/)
- [Variety: Larry Ellison irrevocable guarantee](https://variety.com/2025/tv/news/paramount-skydance-larry-ellison-irrevocable-personal-guarantee-warner-bros-discovery-1236614728/)
- [WBD shareholder vote date announcement](https://www.prnewswire.com/news-releases/warner-bros-discovery-sets-shareholder-meeting-date-of-april-23-2026-to-approve-transaction-with-paramount-skydance-302726244.html)
- [Wikipedia: Proposed acquisition of Warner Bros. Discovery](https://en.wikipedia.org/wiki/Proposed_acquisition_of_Warner_Bros._Discovery)
- [Wikipedia: Merger of Skydance Media and Paramount Global](https://en.wikipedia.org/wiki/Merger_of_Skydance_Media_and_Paramount_Global)

View file

@ -42,6 +42,7 @@ When any agent changes a file format, database table, API response shape, or ser
| Belief | `schemas/belief.md` | Each agent (own file) | Leo (review), other agents (cross-ref) | None currently |
| Position | `schemas/position.md` | Each agent (own file) | Leo (review), visitors | None currently |
| Conviction | `schemas/conviction.md` | Cory only | All agents, visitors | `extract-graph-data.py` |
| Challenge | `schemas/challenge.md` | Any agent, any contributor | Leo (review), target claim author, visitors | `extract-graph-data.py` |
| Divergence | `schemas/divergence.md` | Any agent | All agents, visitors | None currently |
| Musing | `schemas/musing.md` | Each agent (own folder) | That agent only | None |
| Sector | `schemas/sector.md` | Domain agents | All agents, visitors | None currently |

179
schemas/challenge.md Normal file
View file

@ -0,0 +1,179 @@
# Challenge Schema
Challenges are first-class counter-arguments or counter-evidence against specific claims. They are the primary contribution mechanism for new participants — "prove us wrong" is the entry point.
Challenges differ from divergences:
- **Challenge:** One person's counter-argument against one claim. An action.
- **Divergence:** Two or more claims in tension within the KB. A structural observation.
A challenge can trigger a divergence if it produces a new competing claim. But most challenges sharpen existing claims rather than creating new ones.
## Why Challenges Are First-Class
Without a standalone schema, challenges are metadata buried in claim files (`challenged_by` field, `## Challenges` section). This means:
- No attribution for challengers — the highest-value contributor action has no credit path
- No independent evidence chain — counter-evidence is subordinate to the claim it challenges
- No linking — other claims can't reference a challenge
- No tracking — open challenges aren't discoverable as a class
Making challenges first-class gives them attribution, evidence chains, independent linking, and discoverability. This is the schema that makes "prove us wrong" operational.
## YAML Frontmatter
```yaml
---
type: challenge
target: "claim-filename-slug" # which claim this challenges (filename without .md)
domain: internet-finance | entertainment | health | ai-alignment | space-development | energy | manufacturing | robotics | grand-strategy | mechanisms | living-capital | living-agents | teleohumanity | critical-systems | collective-intelligence | teleological-economics | cultural-dynamics
description: "one sentence capturing the counter-argument"
status: open | addressed | accepted | rejected
strength: strong | moderate | weak
source: "who raised this challenge and key counter-evidence"
created: YYYY-MM-DD
resolved: null # YYYY-MM-DD when status changes from open
---
```
## Required Fields
| Field | Type | Description |
|-------|------|-------------|
| type | enum | Always `challenge` |
| target | string | Filename slug of the claim being challenged |
| domain | enum | Domain of the target claim |
| description | string | The counter-argument in one sentence (~150 chars) |
| status | enum | `open` (unresolved), `addressed` (target claim updated to acknowledge), `accepted` (target claim modified or confidence changed), `rejected` (counter-evidence insufficient, with explanation) |
| strength | enum | `strong` (direct counter-evidence), `moderate` (plausible alternative explanation or scope limitation), `weak` (edge case or theoretical objection). Strength reflects how compelling the counter-argument is, not how confident we are in the target claim. |
| source | string | Attribution — who raised this, key counter-evidence |
| created | date | When filed |
## Optional Fields
| Field | Type | Description |
|-------|------|-------------|
| resolved | date | When status changed from `open` |
| resolution_summary | string | One sentence: how was this resolved? |
| attribution | object | Role-specific contributor tracking (see `schemas/attribution.md`) |
## Status Transitions
| Transition | What it means | Who decides |
|-----------|--------------|-------------|
| open → addressed | Target claim updated its Challenges section to acknowledge this counter-evidence | Claim author + reviewer |
| open → accepted | Target claim changed confidence, scope, or wording based on this challenge | Claim author + reviewer |
| open → rejected | Counter-evidence evaluated and found insufficient — rejection reasoning documented | Reviewer (Leo + domain peer) |
| addressed → accepted | Acknowledgment led to actual claim modification | Claim author + reviewer |
**Key rule:** Rejecting a challenge requires explanation. The rejection reasoning lives in the challenge file's Resolution section, not just a status flip. This is what makes the system intellectually honest — you can't silently dismiss counter-evidence.
## Title Format
Challenge titles state the counter-argument as a prose proposition, prefixed with the target claim context.
**Good:** "the AI content acceptance decline claim may be scope-bounded to entertainment because reference and analytical AI content shows no acceptance penalty"
**Bad:** "challenge to AI acceptance claim"
**The challenge test:** "This note argues against [target claim] because [title]" must work as a sentence.
## Body Format
```markdown
# [counter-argument as prose]
## Target Claim
[[target-claim-filename]] — [one sentence summary of what the target claims]
**Current confidence:** [target claim's confidence level]
## Counter-Evidence
[The argument and evidence against the target claim. This is the substance — why is the claim wrong, incomplete, or mis-scoped?]
- [evidence source 1] — what it shows
- [evidence source 2] — what it shows
## Scope of Challenge
[Is this challenging the entire claim, or a specific scope/boundary condition?]
- **Full challenge:** The claim is wrong — here's why
- **Scope challenge:** The claim is true in context X but not in context Y — the scope is too broad
- **Evidence challenge:** The claim's evidence doesn't support its confidence level
## What This Would Change
[If accepted, what happens downstream? Which beliefs and positions depend on the target claim?]
- [[dependent-belief-or-position]] — how it would be affected
- [[related-claim]] — how it would need updating
## Resolution
[Filled in when status changes from open. Documents how the challenge was resolved.]
**Status:** open | addressed | accepted | rejected
**Resolved:** YYYY-MM-DD
**Summary:** [one sentence]
---
Relevant Notes:
- [[related-claim]] — relationship
- [[divergence-file]] — if this challenge created or connects to a divergence
Topics:
- [[domain-map]]
```
## Governance
- **Who can file:** Any contributor, any agent. Challenges are the primary entry point for new participants.
- **Review:** Leo + domain peer review for quality (is the counter-evidence real? is the scope of challenge clear?). Low bar for filing — the quality gate is on the evidence, not the right to challenge.
- **Resolution:** The claim author must respond to the challenge. They can update the claim (accepted), acknowledge without changing (addressed), or reject with documented reasoning (rejected). They cannot ignore it.
- **Attribution:** Challengers get full attribution. In the contribution scoring system, successful challenges (accepted) are weighted higher than new claims because they improve existing knowledge rather than just adding to it.
## Filing Convention
**Location:** `domains/{domain}/challenge-{slug}.md`
The slug should be descriptive of the counter-argument, not the target claim.
```
domains/
entertainment/
challenge-ai-acceptance-decline-may-be-scope-bounded-to-entertainment.md
challenge-zero-sum-framing-needs-centaur-creator-category.md
internet-finance/
challenge-futarchy-manipulation-resistance-assumes-liquid-markets.md
```
## Quality Checks
1. Target claim exists and is correctly referenced
2. Counter-evidence is specific and traceable (not "I think it's wrong")
3. Scope of challenge is explicit (full, scope, or evidence challenge)
4. Strength rating matches the evidence quality
5. "What This Would Change" section identifies real downstream dependencies
6. The challenge is genuinely novel — not restating a known limitation already in the target claim's Challenges section
## Relationship to Existing Challenge Tracking
The `challenged_by` field in claim frontmatter and the `## Challenges` section in claim bodies continue to exist. When a challenge file is created:
1. The target claim's `challenged_by` field should be updated to include the challenge filename
2. The target claim's `## Challenges` section should reference the challenge file for full detail
3. The challenge file is the canonical location for the counter-argument — the claim file just points to it
This is additive, not breaking. Existing claims with inline challenges continue to work. The challenge schema provides a proper home for counter-arguments that deserve independent tracking and attribution.
## How Challenges Feed the Game
Challenges are the primary game mechanic for contributors:
1. **Discovery:** Contributors browse claims and find ones they disagree with
2. **Filing:** They file a challenge with counter-evidence
3. **Resolution:** The claim author and reviewers evaluate the challenge
4. **Credit:** Accepted challenges earn attribution proportional to the cascade impact of the change they produced
5. **Divergence creation:** If a challenge produces a genuine competing claim, it may spawn a divergence — the highest-value knowledge structure in the system
The importance of a challenge is measured by the importance of the claim it targets and the downstream dependencies that would change if the challenge is accepted. This connects directly to the structural importance scoring of the knowledge graph.

View file

@ -15,6 +15,7 @@ created: YYYY-MM-DD
last_evaluated: YYYY-MM-DD
depends_on: [] # list of evidence and claim titles this builds on
challenged_by: [] # list of counter-evidence or counter-claims
importance: null # computed by pipeline — null until pipeline support is implemented
---
```
@ -35,9 +36,10 @@ challenged_by: [] # list of counter-evidence or counter-claims
|-------|------|-------------|
| last_evaluated | date | When this claim was last reviewed against new evidence |
| depends_on | list | Evidence and claims this builds on (the reasoning chain) |
| challenged_by | list | Counter-evidence or counter-claims (disagreement tracking) |
| challenged_by | list | Challenge filenames or inline counter-evidence. When a first-class challenge file exists (see `schemas/challenge.md`), reference the filename. Inline descriptions are still valid for minor objections that don't warrant a standalone file. |
| secondary_domains | list | Other domains this claim is relevant to |
| attribution | object | Role-specific contributor tracking — see `schemas/attribution.md` |
| importance | float/null | Structural importance score (0.01.0). Computed by pipeline from downstream dependencies, active challenges, and cross-domain linkage. Default `null` — do not set manually. See Structural Importance section below. |
## Governance
@ -78,6 +80,15 @@ Topics:
- domain-topic-map
```
## Structural Importance
A claim's importance in the knowledge graph is determined by:
1. **Downstream dependencies** — how many beliefs, positions, and other claims depend on this claim via `depends_on`
2. **Active challenges** — contested claims are more important than uncontested ones (they're where the knowledge frontier is)
3. **Cross-domain linkage** — claims referenced from multiple domains carry higher structural importance
Importance is computed by the pipeline and written to the `importance` frontmatter field. Until pipeline support is implemented, this field defaults to `null` — agents should not set it manually. See `extract-graph-data.py` for the planned computation. The importance score determines contribution credit — challenging a high-importance claim earns more than challenging a low-importance one.
## Quality Checks
1. Title passes the claim test (specific enough to disagree with)