Data-First Architecture: Wiki Pages as Tabs + Structured Data Extraction

[OAGr]

Vision

Transition from the current wiki-centric architecture — where MDX pages embed structured data inline — to a data-first architecture where structured data lives in TableBase/FactBase/PG and wiki pages serve as narrative analysis tabs within entity directory pages.

Current state: Entity directory pages (e.g., /organizations/manifund) show structured data in tabs, while wiki pages (/wiki/E547) exist as separate standalone pages containing a mix of prose and embedded structured data (tables, timelines, comparisons). Users must click through to discover wiki content. ~40-50% of wiki page content is structured data that duplicates or should live in the database.

Target state: Entity directory pages are the primary view. Wiki content is a tab within them. Structured data is extracted from wiki pages into the proper data layer. Wiki prose focuses on analysis, context, and arguments — things that can't be a database row.

Reference: PR #2893 (wiki excerpt on person pages) is a first step. PRs #2897/#2899 (shrinking database.json) are laying infrastructure. Epic #2428 (PG-first direction) is the infrastructure foundation.

---

Workstreams

WS1: Wiki-as-Tab on Entity Directory Pages (~8h)

Make wiki content a tab within entity directory pages instead of a separate standalone page.

• Generalize WikiOverview (from PR feat: show wiki page excerpt on person directory pages #2893) into a full WikiTab component that renders complete MDX content (not just an excerpt) within ProfileTabs
• Add "Wiki" tab to organization pages — render the entity's full wiki content as a tab alongside Overview, People, Funding, etc.
• Add "Wiki" tab to people pages — upgrade the current excerpt (PR feat: show wiki page excerpt on person directory pages #2893) to a full tab
• Add "Wiki" tab to other entity types that have directory pages (AI models, legislation, projects, approaches, benchmarks, events)
• Handle TOC/citations: Decide whether the wiki tab includes its own table of contents and citation panel, or uses a simplified layout
• Redirect strategy: /wiki/E<id> redirects to /organizations/<slug>?tab=wiki for entities that have directory pages. Standalone /wiki/ URLs remain for entities without directory pages (concepts, risks, analyses)
• SEO: Ensure canonical URLs, meta tags, and OG previews work correctly for the tab-based layout

WS2: Extract Structured Data from Wiki Pages (~20h)

Audit existing wiki pages and move embedded structured data into the proper data layer. This is the bulk of the work — going page by page through the ~200 entity wiki pages that have directory page counterparts.

Data types to extract:

Embedded data pattern	Target location	Example
Grant/funding tables	PG grants table	Manifund's 377 grants
Personnel/team tables	PG personnel table	Founding team bios → structured records
Comparison tables (org vs org)	FactBase properties per entity	Manifund vs LTFF vs SFF
Timeline/history events	PG events table or FactBase temporal records	"Dec 2021: Founded"
Quick Assessment tables	FactBase properties	Speed, transparency ratings
Organization Details tables	TableBase entity YAML + FactBase	Type, legal status, annual volume
Financial metrics inline	FactBase properties	Revenue, headcount, valuation
Product/model specs inline	PG or FactBase	Model parameters, pricing

Process per page:

1. Identify all structured data sections
2. Ensure equivalent data exists in TableBase/FactBase/PG (create if missing)
3. Replace inline tables with data-backed components (WS3)
4. Trim wiki content to narrative-only
5. Run crux w fix escaping + crux w fix markdown + gate check

Priority order:

• Organizations with the most embedded data (Anthropic, OpenAI, Manifund, MIRI, etc.)
• People pages with detailed career tables
• AI model pages with spec tables
• Legislation pages with provision tables

WS3: Build Data-Backed Wiki Components (~8h)

Create reusable MDX components that render structured data from PG/FactBase, replacing static inline tables.

• <EntityComparison entities={["manifund","ltff","sff"]} properties={["speed","grant-size","transparency"]} /> — renders a comparison table from FactBase properties across multiple entities
• <EntityTimeline entityId="manifund" /> — renders a timeline from temporal FactBase records or PG events
• <GrantsSummary entityId="manifund" limit={10} /> — renders a summary of grants from PG with link to full tab
• <PersonnelTable entityId="manifund" /> — renders personnel from PG
• <QuickAssessment entityId="manifund" /> — renders assessment properties from FactBase
• <OrgDetails entityId="manifund" /> — renders key org metadata from TableBase + FactBase
• Register all components in mdx-components.tsx
• These components should gracefully degrade (show nothing or a placeholder) when data is missing

Design decision: These components read from database.json at build time (consistent with current wiki page pattern — zero runtime API calls for content pages). They pull structured data that was synced from PG/FactBase during build-data.mjs.

WS4: Expand FactBase Coverage (~10h)

Currently only ~40 entities have structured FactBase entries. To support data-first rendering, we need broader coverage.

• Priority 1 — Organizations with directory pages (~50-80 orgs): Add FactBase entries with key properties (founding date, headquarters, headcount, total funding, leadership, org type)
• Priority 2 — Key people (~50-100 people): Structured career history, current role, affiliations, notable positions
• Priority 3 — AI models: Structured specs (parameter count, training data, release date, pricing, safety evaluations) — partially covered by benchmarks PG table
• Batch tooling: Extend crux tb or crux fb with a command to bootstrap FactBase entries from existing wiki page content (semi-automated extraction)
• Auto-update integration: Configure auto-update sources to keep FactBase entries current for key entities

WS5: Audit & Cleanup Wiki Pages Post-Extraction (~8h)

After structured data is extracted, audit wiki pages for quality:

• Remove duplicate data: Sections that now duplicate what's shown in other tabs (Overview, People, Funding, etc.)
• Strengthen narrative: Ensure remaining prose adds analytical value — not just restating facts
• Consistent structure: Wiki tab content follows a consistent pattern: brief context → analysis → implications → related reading
• Cross-page consistency: Entity facts referenced in multiple wiki pages should use <FBF> components (single source of truth)
• Gate check: All modified pages pass crux w validate gate --fix

---

Key Design Decisions (Need Input)

1. Full wiki vs excerpt in tab? PR feat: show wiki page excerpt on person directory pages #2893 shows an excerpt. Should the wiki tab show the complete article, or always an excerpt with "Read more"? Full article means some tabs could be very long.

2. What happens to /wiki/E<id> URLs? Options:

   • (a) Redirect to /<type>/<slug>?tab=wiki — clean but breaks existing links
   • (b) Keep both URLs, canonical on the tab version — more work but no broken links
   • (c) /wiki/E<id> renders the same content but in a full-page layout (no tabs) — for sharing/printing

3. Entities without directory pages: ~450 entities (concepts, risks, analyses) have wiki pages but no directory page. Options:

   • (a) Create a generic entity directory page with minimal tabs (Overview + Wiki)
   • (b) Keep these as standalone /wiki/ pages
   • (c) Phase 2 — create directory pages for entity types as they accumulate enough structured data

4. Component data source: Should data-backed MDX components read from database.json (build-time, consistent with current wiki pattern) or make ISR API calls to wiki-server (fresher data, more complexity)?

5. Migration pace: Go entity-type-by-type (all orgs, then all people, then all models)? Or priority-by-importance (top 20 entities across all types first)?

---

Estimated Effort

Workstream	Hours	Can be parallelized?
WS1: Wiki-as-Tab	~8h	Independent
WS2: Extract structured data	~20h	After WS3 components exist
WS3: Data-backed components	~8h	After WS1 proves the pattern
WS4: Expand FactBase	~10h	Independent, can run alongside
WS5: Audit & cleanup	~8h	After WS2
Total	~54h

WS1 and WS4 can start immediately in parallel. WS3 follows once WS1 validates the tab pattern. WS2 is the bulk and depends on WS3 components. WS5 is cleanup after WS2.

Much of WS2 and WS5 is mechanical page-by-page work well-suited to agent sessions with crux w improve.

---

Success Metrics

• Zero standalone wiki pages for entities with directory pages — all wiki content accessible via tabs
• <10% of wiki page content is structured data (currently ~40-50%)
• FactBase coverage: 100+ entities with structured facts (currently ~40)
• No duplicate data: A fact appears in exactly one authoritative source, rendered everywhere via components
• Page load: Directory pages with wiki tab load in <2s (no regression from embedding MDX)

[OAGr]

Status (April 2026): The vision described here has been partially realized through incremental work rather than a big-bang migration. Organization pages now have rich tab-based layouts (personnel, funding, divisions, charts). Entity directory pages are the primary browsing interface. Wiki pages serve as narrative analysis. The architectural direction moved forward without a formal RFC decision — closing as the current implementation reflects the spirit of this proposal.