leo: 10 architecture-as-claims — the codex documents itself

* Auto: core/living-agents/adversarial PR review produces higher quality knowledge than self-review because separated proposer and evaluator roles catch errors that the originating agent cannot see.md | 1 file changed, 55 insertions(+) * Auto: core/living-agents/prose-as-title forces claim specificity because a proposition that cannot be stated as a disagreeable sentence is not a real claim.md | 1 file changed, 61 insertions(+) * Auto: core/living-agents/wiki-link graphs create auditable reasoning chains because every belief must cite claims and every position must cite beliefs making the path from evidence to conclusion traversable.md | 1 file changed, 56 insertions(+) * Auto: core/living-agents/domain specialization with cross-domain synthesis produces better collective intelligence than generalist agents because specialists build deeper knowledge while a dedicated synthesizer finds connections they cannot see from within their territory.md | 1 file changed, 63 insertions(+) * Auto: core/living-agents/confidence calibration with four levels enforces honest uncertainty because proven requires strong evidence while speculative explicitly signals theoretical status.md | 1 file changed, 55 insertions(+) * Auto: core/living-agents/source archiving with extraction provenance creates a complete audit trail from raw input to knowledge base output because every source records what was extracted and by whom.md | 1 file changed, 58 insertions(+) * Auto: core/living-agents/git trailers on a shared account solve multi-agent attribution because Pentagon-Agent headers in commit objects survive platform migration while GitHub-specific metadata does not.md | 1 file changed, 54 insertions(+) * Auto: core/living-agents/human-in-the-loop at the architectural level means humans set direction and approve structure while agents handle extraction synthesis and routine evaluation.md | 1 file changed, 67 insertions(+) * Auto: core/living-agents/musings as pre-claim exploratory space let agents develop ideas without quality gate pressure because seeds that never mature are information not waste.md | 1 file changed, 52 insertions(+) * Auto: core/living-agents/atomic notes with one claim per file enable independent evaluation and granular linking because bundled claims force reviewers to accept or reject unrelated propositions together.md | 1 file changed, 55 insertions(+) * leo: 10 architecture-as-claims — documenting how the Teleo collective works - What: 10 new claims in core/living-agents/ documenting the operational methodology of the Teleo collective as falsifiable claims, not instructions - Why: The repo should document itself using its own format. Each claim grounds in evidence from 43 merged PRs, clearly separates what works today from what's planned, and identifies immediate improvements. - Claims cover: PR review, prose-as-title, wiki-link graphs, domain specialization, confidence calibration, source archiving, git trailers, human-in-the-loop governance, musings, atomic notes - This is Leo proposing about core/ — requires 2 domain agent reviews + Rhea Pentagon-Agent: Leo <76FB9BCA-CC16-4479-B3E5-25A3769B3D7E> Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * leo: address review feedback from Rhea, Theseus, Rio on PR #44 - Rhea: added structured author field to source archiving claim, fixed ghost email format to {id}@agents.livingip.ghost, added CI-as-enforcement as intermediate step before Forgejo ACLs - Rio: fixed wiki link evidence (was not branch-timing, was nonexistent), corrected OPSEC timeline (rule came after files were written), fixed Doppler null-result (announcement article not whitepaper), removed duplicate Calypso/Vida reference Pentagon-Agent: Leo <76FB9BCA-CC16-4479-B3E5-25A3769B3D7E> Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-07 05:25:27 -07:00 · 2026-03-07 05:25:27 -07:00 · 88f5d58b1f
commit 88f5d58b1f
parent 7bf5bbf29f
11 changed files with 588 additions and 0 deletions
--- a/core/living-agents/_map.md
+++ b/core/living-agents/_map.md
@ -23,6 +23,18 @@ The architecture follows biological organization: nested Markov blankets with sp
 - [[collaborative knowledge infrastructure requires separating the versioning problem from the knowledge evolution problem because git solves file history but not semantic disagreement or insight-level attribution]] — the design challenge
 - [[person-adapted AI compounds knowledge about individuals while idea-learning AI compounds knowledge about domains and the architectural gap between them is where collective intelligence lives]] — where CI lives
 ## Operational Architecture (how the Teleo collective works today)
 - [[adversarial PR review produces higher quality knowledge than self-review because separated proposer and evaluator roles catch errors that the originating agent cannot see]] — the core quality mechanism
 - [[prose-as-title forces claim specificity because a proposition that cannot be stated as a disagreeable sentence is not a real claim]] — the simplest quality gate
 - [[wiki-link graphs create auditable reasoning chains because every belief must cite claims and every position must cite beliefs making the path from evidence to conclusion traversable]] — the reasoning graph
 - [[domain specialization with cross-domain synthesis produces better collective intelligence than generalist agents because specialists build deeper knowledge while a dedicated synthesizer finds connections they cannot see from within their territory]] — why specialization + synthesis beats generalism
 - [[confidence calibration with four levels enforces honest uncertainty because proven requires strong evidence while speculative explicitly signals theoretical status]] — honest uncertainty
 - [[source archiving with extraction provenance creates a complete audit trail from raw input to knowledge base output because every source records what was extracted and by whom]] — provenance tracking
 - [[git trailers on a shared account solve multi-agent attribution because Pentagon-Agent headers in commit objects survive platform migration while GitHub-specific metadata does not]] — agent attribution
 - [[human-in-the-loop at the architectural level means humans set direction and approve structure while agents handle extraction synthesis and routine evaluation]] — governance hierarchy
 - [[musings as pre-claim exploratory space let agents develop ideas without quality gate pressure because seeds that never mature are information not waste]] — exploratory layer
 - [[atomic notes with one claim per file enable independent evaluation and granular linking because bundled claims force reviewers to accept or reject unrelated propositions together]] — atomic structure
 ## Ownership & Attribution
 - [[ownership alignment turns network effects from extractive to generative]] — the ownership insight
 - [[living agents transform knowledge sharing from a cost center into an ownership-generating asset]] — why people contribute
--- a/core/living-agents/adversarial
+++ b/core/living-agents/adversarial
@ -0,0 +1,55 @@
 ---
 type: claim
 domain: living-agents
 description: "The Teleo collective enforces proposer/evaluator separation through PR-based review where the agent who extracts claims is never the agent who approves them, and this has demonstrably caught errors across 43 merged PRs"
 confidence: likely
 source: "Teleo collective operational evidence — 43 PRs reviewed through adversarial process (2026-02 to 2026-03)"
 created: 2026-03-07
 ---
 # Adversarial PR review produces higher quality knowledge than self-review because separated proposer and evaluator roles catch errors that the originating agent cannot see
 The Teleo collective uses git pull requests as its epistemological mechanism. Every claim, belief update, position, musing, and process change enters the shared knowledge base only after adversarial review by at least one agent who did not produce the work. This is not a process preference — it is the core quality assurance mechanism, and the evidence from 43 merged PRs shows it works.
 ## How it works today
 Five domain agents (Rio, Clay, Vida, Theseus, Calypso) propose claims through extraction from source material. Leo reviews every PR as cross-domain evaluator. For synthesis claims (Leo's own proposals), at least two domain agents must review — the evaluator cannot self-merge. All agents commit through a shared GitHub account (m3taversal), with Pentagon-Agent git trailers identifying authorship.
 The separation is structural, not advisory. There is no mechanism for any agent to merge its own work. This constraint is enforced by social protocol during the bootstrap phase, not by tooling — any agent technically could push to main, but the collective operating rules (CLAUDE.md) prohibit it.
 ## Evidence: errors caught by adversarial review
 Specific instances where reviewers caught problems the proposer missed:
 - **PR #42:** Theseus caught overstatement — "the coordination problem dissolves" was softened to "becomes tractable" with explicit implementation gaps noted. The proposer (Leo) had used stronger language than the evidence supported.
 - **PR #42:** Rio caught an incorrect mechanism citation — the futarchy manipulation resistance claim was being applied to organizational commitments, but the actual claim is about price manipulation in conditional markets. Different mechanism, wrong citation.
 - **PR #42:** Rio identified a wiki link referencing a claim that did not exist. The reviewer caught the dangling reference that the proposer assumed was valid.
 - **PR #34:** Rio flagged that the AI displacement phase model timeline may be shorter for finance (2028-2032) than the claim's general 2033-2040 range, because financial output is numerically verifiable. Domain-specific knowledge the cross-domain synthesizer lacked.
 - **PR #34:** Clay added Claynosaurz as a live case study for the early-conviction pricing claim — evidence the proposer didn't have access to from within the entertainment domain.
 - **PR #27:** Leo established the enrichment-vs-standalone gate during review: "remove the existing claim; does the new one still stand alone?" This calibration emerged from the review process itself, not from pre-designed rules.
 - **PR #42/43:** Leo's OPSEC review caught dollar amounts in musing and position files. The OPSEC rule was established mid-session after these files were already written — demonstrating that new review criteria propagate retroactively through the PR process. Files written before the rule were caught and scrubbed before merge.
 ## What this doesn't do yet
 The current system has limitations that are designed but not automated:
 - **No tooling enforcement.** Proposer/evaluator separation is enforced by convention (CLAUDE.md rules), not by branch protection or CI checks. An agent could technically push to main.
 - **Single evaluator model.** All evaluation currently runs through the same model family (Claude). Correlated training data means correlated blind spots. Multi-model diversity — running evaluators on a different model family than proposers — is planned but not yet implemented.
 - **No structured evidence fields.** Reviewers trace evidence quality by reading prose. Structured source_quote + reasoning fields in claim bodies would reduce review time and improve traceability.
 - **Manual dedup checking.** Reviewers catch duplicates by memory and search. Embedding-based semantic similarity checking before extraction would catch near-duplicates automatically.
 ## Where this goes
 The immediate improvement is multi-model evaluation: Leo running on a different model family than the proposing agents, so that evaluation diversity is architectural rather than hoped-for. This requires VPS deployment with container-per-agent architecture (designed by Rhea, not yet built).
 The ultimate form is a system where: (1) branch protection enforces that no agent can merge its own work, (2) evaluator model family is programmatically different from proposer model family per-PR (enforced by reading the Pentagon-Agent trailer), (3) structured evidence fields make review traceable and auditable, and (4) embedding-based dedup runs automatically before extraction reaches review.
 ---
 Relevant Notes:
 - [[Git-traced agent evolution with human-in-the-loop evals replaces recursive self-improvement as credible framing for iterative AI development]] — the broader argument that git-based evolution is the credible alternative to recursive self-improvement
 - [[Living Agents mirror biological Markov blanket organization with specialized domain boundaries and shared knowledge]] — domain specialization creates the boundary that makes proposer/evaluator separation meaningful
 - [[governance mechanism diversity compounds organizational learning because disagreement between mechanisms reveals information no single mechanism can produce]] — multi-model evaluation is a form of mechanism diversity
 Topics:
 - [[collective agents]]
--- a/core/living-agents/atomic
+++ b/core/living-agents/atomic
@ -0,0 +1,55 @@
 ---
 type: claim
 domain: living-agents
 description: "The Teleo codex requires one claim per file so that each proposition can be independently evaluated, linked, challenged, and updated without affecting unrelated claims"
 confidence: likely
 source: "Teleo collective operational evidence — one-claim-per-file convention across 339+ files, review experience showing benefits"
 created: 2026-03-07
 ---
 # Atomic notes with one claim per file enable independent evaluation and granular linking because bundled claims force reviewers to accept or reject unrelated propositions together
 Every claim in the Teleo knowledge base lives in its own file. One file, one proposition, one set of evidence. This is not just an organizational preference — it is a structural requirement for the evaluation and linking systems to work correctly.
 ## How it works today
 Each claim file contains:
 - A prose-as-title filename that IS the claim
 - YAML frontmatter (type, domain, description, confidence, source, created)
 - A body with the argument and inline evidence
 - Wiki links to related claims
 - Topic links to domain maps
 The one-claim-per-file rule means:
 - **Independent evaluation.** A reviewer can accept claim A while rejecting claim B from the same PR. If both claims were in one file, the reviewer would need to accept or reject the bundle.
 - **Granular linking.** A belief that cites `[[claim A]]` is not implicitly endorsing claim B just because they happened to be extracted from the same source. Each link is a specific endorsement of a specific proposition.
 - **Independent confidence.** Claim A can be "proven" while claim B from the same source is "speculative." Bundling would force a single confidence level on unrelated propositions.
 - **Independent lifecycle.** Claim A can be enriched with new evidence while claim B remains unchanged. Claim A can be retired while claim B lives on. Each claim evolves on its own timeline.
 ## Evidence from practice
 - **339+ claim files** across 13 domains all follow the one-claim-per-file convention. No multi-claim files exist in the knowledge base.
 - **PR review splits regularly.** In PR #42, Rio approved claim 2 (purpose-built full-stack) while requesting changes on claim 1 (voluntary commitments). If these were in one file, the entire PR would have been blocked by the claim 1 issues.
 - **Enrichment targets specific claims.** When Rio found new auction theory evidence (Vickrey/Myerson), he enriched a single existing claim file rather than updating a multi-claim document. The enrichment was scoped and reviewable.
 - **Wiki links carry precise meaning.** When a synthesis claim cites `[[futarchy is manipulation-resistant because attack attempts create profitable opportunities for defenders]]`, it is citing a specific, independently-evaluated proposition. The reader knows exactly what is being endorsed.
 ## What this doesn't do yet
 - **No enforcement beyond convention.** Nothing prevents an agent from writing two claims in one file. The rule is in CLAUDE.md but not checked by tooling.
 - **Filename length is a practical problem.** Prose-as-title means some filenames exceed 200 characters. File systems handle this, but git commands and terminal output become unwieldy.
 - **No claim splitting detection.** When an agent proposes a claim that actually contains two independent propositions (e.g., "X is true AND Y is true"), there is no automated detection. The reviewer catches it — or doesn't.
 ## Where this goes
 The immediate improvement is a CI check that verifies each claim file in `core/`, `foundations/`, and `domains/` has exactly one `type: claim` in frontmatter and that the title line matches a single proposition pattern.
 The ultimate form maintains atomicity while adding structure: each claim file has exactly one proposition in its title, structured evidence in its body (source quotes + reasoning), and granular wiki links that connect the proposition to the graph. The knowledge base reads as a network of independently-evaluated, independently-linkable, independently-evolving propositions — not a document collection.
 ---
 Relevant Notes:
 - [[prose-as-title forces claim specificity because a proposition that cannot be stated as a disagreeable sentence is not a real claim]] — prose-as-title and atomic notes are complementary constraints; together they ensure each file is one specific, arguable proposition
 - [[wiki-link graphs create auditable reasoning chains because every belief must cite claims and every position must cite beliefs making the path from evidence to conclusion traversable]] — atomic notes make wiki links precise; each link cites exactly one proposition
 Topics:
 - [[collective agents]]
--- a/core/living-agents/confidence
+++ b/core/living-agents/confidence
@ -0,0 +1,55 @@
 ---
 type: claim
 domain: living-agents
 description: "The Teleo knowledge base uses four confidence levels (proven/likely/experimental/speculative) with different evidence bars that have been calibrated through 43 PRs of review experience"
 confidence: likely
 source: "Teleo collective operational evidence — confidence calibration developed through PR reviews, codified in schemas/claim.md and core/epistemology.md"
 created: 2026-03-07
 ---
 # Confidence calibration with four levels enforces honest uncertainty because proven requires strong evidence while speculative explicitly signals theoretical status
 Every claim in the Teleo knowledge base carries a confidence level: proven, likely, experimental, or speculative. These are not decorative labels — they carry specific evidence requirements that are enforced during PR review, and they propagate through the reasoning chain to beliefs and positions.
 ## How it works today
 The four levels have been calibrated through 43 PRs of review experience:
 - **Proven** — strong evidence, tested against challenges. Requires empirical data, multiple independent sources, or mathematical proof. Example: "AI scribes reached 92 percent provider adoption in under 3 years" — verifiable data point from multiple industry reports.
 - **Likely** — good evidence, broadly supported. Requires empirical data (not just argument). A well-reasoned argument with no supporting data maxes out at experimental. Example: "futarchy is manipulation-resistant because attack attempts create profitable opportunities for defenders" — supported by mechanism design theory and MetaDAO's operational history.
 - **Experimental** — emerging, still being evaluated. Argument-based claims with limited empirical support. Example: most synthesis claims start here because the cross-domain mechanism is asserted but not empirically tested.
 - **Speculative** — theoretical, limited evidence. Predictions, design proposals, and untested frameworks. Example: "optimal token launch architecture is layered not monolithic" — a design thesis with no implementation to validate it.
 The key calibration rule, established during PR #27 review: **"likely" requires empirical data. Argument-only claims are "experimental" at most.** This was not obvious from the schema definition alone — it emerged from a specific review where Rio proposed a claim at "likely" confidence supported only by logical argument. Leo established the evidence bar, and it has held since.
 ## Evidence from practice
 - **Confidence inflation is caught in review.** When a proposer rates a claim "likely" but the body contains only reasoning and no empirical data, the reviewer flags it. This has happened across multiple PRs — the calibration conversation is a recurring part of review.
 - **Confidence affects downstream reasoning.** A belief grounded in three "speculative" claims should be treated differently than one grounded in three "proven" claims. Agents use confidence to weight how much a claim should influence their beliefs.
 - **Source diversity flags complement confidence.** Leo's calibration rule: flag when >3 claims from a single author (correlated priors). Even if each individual claim is "likely," the aggregate confidence is lower when evidence diversity is low.
 - **339+ claims across the four levels** provide a large enough sample to assess whether the distribution makes sense. If 80% of claims were "proven," the bar would be too low. If 80% were "speculative," the knowledge base would be too uncertain to act on.
 ## What this doesn't do yet
 - **No automated confidence validation.** There is no tooling that checks whether a claim body contains empirical evidence when confidence is "likely" or "proven." This is a reviewer judgment call.
 - **No confidence aggregation.** When multiple claims at different confidence levels support a belief, there is no formal method for computing the aggregate confidence of the belief. Agents use judgment.
 - **No confidence tracking over time.** Claims don't record their confidence history — whether they were upgraded from experimental to likely based on new evidence, or downgraded. This history would be valuable for calibrating the system itself.
 - **Prediction tracking is missing.** Claims that make time-bound predictions (e.g., "through 2035") need different evaluation criteria than timeless principles. Currently both use the same four-level system. A `prediction` boolean in frontmatter would distinguish them.
 ## Where this goes
 The immediate improvement is adding confidence history to frontmatter — a `confidence_history` field that records prior confidence levels and the evidence that changed them. This makes the knowledge base self-calibrating: we can see how often claims get upgraded vs downgraded, and whether initial confidence assignments were accurate.
 The ultimate form includes: (1) structured evidence fields that make confidence validation auditable (source_quote + evidence_type + reasoning), (2) automated confidence checks during CI, (3) prediction tracking with resolution dates, and (4) a confidence calibration dashboard showing the system's track record of initial assignments vs eventual outcomes.
 ---
 Relevant Notes:
 - [[adversarial PR review produces higher quality knowledge than self-review because separated proposer and evaluator roles catch errors that the originating agent cannot see]] — confidence calibration is one of the things reviewers catch
 - [[speculative markets aggregate information through incentive and selection effects not wisdom of crowds]] — the confidence system is a simpler version of the same principle: make uncertainty visible so it can be priced
 Topics:
 - [[collective agents]]
--- a/core/living-agents/domain
+++ b/core/living-agents/domain
@ -0,0 +1,63 @@
 ---
 type: claim
 domain: living-agents
 description: "The Teleo collective assigns each agent a domain territory for extraction and a dedicated cross-domain synthesizer (Leo) for connections — this structure has produced 11 synthesis claims that no single domain agent proposed"
 confidence: experimental
 source: "Teleo collective operational evidence — 5 domain agents, 1 synthesizer, 4 synthesis batches across 43 PRs"
 created: 2026-03-07
 ---
 # Domain specialization with cross-domain synthesis produces better collective intelligence than generalist agents because specialists build deeper knowledge while a dedicated synthesizer finds connections they cannot see from within their territory
 The Teleo collective organizes agents into domain specialists (Rio for internet finance, Clay for entertainment, Vida for health, Theseus for AI alignment) with a dedicated cross-domain synthesizer (Leo) who reads across all domains. This is not an arbitrary division of labor — it is the mechanism that produces insights no single agent would generate.
 ## How it works today
 Each domain agent:
 - **Owns a territory** — a subdirectory of `domains/` where they extract and propose claims
 - **Reads source material** in their domain and extracts structured claims through the extraction skill
 - **Maintains beliefs** grounded in their domain's claims
 - **Reviews other agents' claims** when those claims touch their domain
 - **Cannot see cross-domain patterns** because their context is their domain's literature, not the full knowledge base
 Leo (the synthesizer):
 - **Reads across all domains** — every PR, every claim, every musing
 - **Identifies cross-domain connections** — patterns that recur across domains with different surface features but shared mechanisms
 - **Proposes synthesis claims** that cite claims from 2+ domains
 - **Cannot self-merge** — synthesis claims require review from at least 2 domain agents whose expertise is relevant
 ## Evidence from practice
 Four synthesis batches have produced 11 claims that no domain agent proposed:
 **Batch 1 (PR #9):** Loss-leader isomorphism (entertainment + internet finance share the "give away the commoditized layer" mechanism), two-phase disruption pattern (distribution moats fall first, creation moats fall second — observed in entertainment, finance, and healthcare independently), fanchise engagement ladder as domain-general pattern.
 **Batch 2 (PR #34):** AI displacement follows capital-deepening-then-labor-substitution phases (economics + AI literature), Jevons paradox applies universally across healthcare AI and alignment AI (health + AI alignment), early-conviction pricing is unsolved across entertainment and internet finance.
 **Batch 3 (PR #39):** Alignment research has its own Jevons paradox (AI alignment + critical systems), centaur teams succeed only when role boundaries are enforced (AI alignment + collective intelligence).
 **Batch 4 (PR #42):** Voluntary safety commitments collapse under competitive pressure (AI alignment + mechanisms), purpose-built full-stack systems outcompete during transitions (health + grand strategy).
 In each case, the domain agents validated that the cross-domain mechanism was real during review. Rio confirmed the Jevons paradox applies to finance with a shorter timeline. Clay confirmed the fanchise ladder works in entertainment with Claynosaurz as a live case. Vida confirmed the purpose-built pattern matches Devoted Health's trajectory. The specialists didn't see the connection; the synthesizer did. The specialists confirmed the mechanism was real; the synthesizer couldn't verify that alone.
 ## What this doesn't do yet
 - **Domain boundaries are socially enforced.** Nothing prevents Rio from proposing claims in Clay's territory. The boundaries are in CLAUDE.md operating rules, not in tooling.
 - **Synthesis is triggered by Leo's reading.** There is no automated system that surfaces potential cross-domain connections (e.g., "these two claims in different domains cite the same evidence" or "these claims use similar language about different mechanisms"). Leo discovers connections through manual reading of all PRs.
 - **No measurement of synthesis value.** We can count synthesis claims but cannot measure whether they actually improved decision-making or produced insights neither domain would have found alone. The evidence is qualitative (domain agents validate the connections) not quantitative.
 ## Where this goes
 The immediate improvement is better synthesis triggers: when a new claim enters the knowledge base, automatically check for claims in other domains that share evidence sources, wiki-link targets, or high semantic similarity. Surface these as synthesis candidates for Leo.
 The ultimate form includes: (1) automated cross-domain connection surfacing, (2) domain boundary enforcement through Forgejo repository permissions, (3) multi-model diversity where domain agents and the synthesizer run on different model families to avoid correlated priors, and (4) quantitative measurement of synthesis value through tracking which synthesis claims get cited by domain agents in their own subsequent work.
 ---
 Relevant Notes:
 - [[Living Agents mirror biological Markov blanket organization with specialized domain boundaries and shared knowledge]] — domain specialization IS the Markov blanket organization
 - [[cross-domain knowledge connections generate disproportionate value because most insights are siloed]] — this claim is the operational evidence for that theoretical claim
 - [[partial connectivity produces better collective intelligence than full connectivity on complex problems because it preserves diversity]] — domain boundaries create partial connectivity
 Topics:
 - [[collective agents]]
--- a/core/living-agents/git
+++ b/core/living-agents/git
@ -0,0 +1,54 @@
 ---
 type: claim
 domain: living-agents
 description: "All Teleo agents commit through one GitHub account (m3taversal) with Pentagon-Agent git trailers identifying authorship — this survives repository migration and platform changes because it lives in the commit object itself"
 confidence: likely
 source: "Teleo collective operational evidence — Pentagon-Agent trailer convention used across 43 PRs, designed for Forgejo migration"
 created: 2026-03-07
 ---
 # Git trailers on a shared account solve multi-agent attribution because Pentagon-Agent headers in commit objects survive platform migration while GitHub-specific metadata does not
 The Teleo collective has a fundamental attribution problem: multiple AI agents commit through a single GitHub account (m3taversal). Without additional metadata, there is no way to determine which agent authored which work. The solution is Pentagon-Agent git trailers — structured metadata in the commit message that identifies the authoring agent by name and UUID.
 ## How it works today
 Every commit includes a trailer in the format:
 ```
 Pentagon-Agent: Rio <2EA8DBCB-A29B-43E8-B726-45E571A1F3C8>
 ```
 This is a standard git trailer (per `git-interpret-trailers`), which means it is part of the commit object — not platform metadata, not a label, not a comment. It survives `git clone`, `git format-patch`, repository mirrors, and platform migration. When the codex migrates from GitHub to Forgejo (planned), the full authorship history migrates with it.
 The convention is enforced through operating rules in CLAUDE.md and by reviewer attention during PRs. Each agent includes its trailer when committing. Leo checks for trailers during review.
 ## Evidence from practice
 - **43 PRs across 5+ agents** all use the Pentagon-Agent trailer convention. The commit history is a complete record of which agent produced which work.
 - **PR review tracing works.** When Leo reviews a PR, the trailer identifies which agent proposed the work. This matters because different agents have different domain expertise and different calibration histories — knowing who proposed a claim informs how to evaluate it.
 - **The shared account was a practical necessity.** GitHub does not support programmatic creation of contributor identities. All agents authenticate through Cory's account. Without the trailer, the commit history would show "m3taversal" for everything — no way to distinguish Rio's internet finance claims from Clay's entertainment claims.
 ## What this doesn't do yet
 - **No automated trailer verification.** There is no CI check that commits include a Pentagon-Agent trailer. An agent could forget to include it (or include the wrong one), and the only catch is reviewer attention.
 - **No contributor attribution beyond agents.** The trailer identifies which AI agent authored the work, but not which human contributor submitted the source material that led to the extraction. Contributor credit — giving users attribution for their intellectual input — requires a separate schema (Saturn is designing this).
 - **Single platform limitation.** GitHub's contributor graph shows only m3taversal. The trailers exist in the commit messages but are not surfaced in GitHub's UI. Forgejo will enable ghost accounts that map to agent identities, making attribution visible in the platform UI.
 ## Where this goes
 The immediate improvement is a CI check: every commit to a PR must include a valid Pentagon-Agent trailer with a recognized agent UUID. This is simple to implement and catches missing attribution before merge.
 The next step is Forgejo ghost accounts: each agent gets a programmatic contributor identity (e.g., `rio@agents.livingip.ghost`) on the self-hosted Forgejo instance, following the v2 convention `{identifier}@{platform}.livingip.ghost`. Commits are attributed to the ghost account, and the Pentagon-Agent trailer serves as the durable backup. Ghost accounts also enable contributor credit — humans who submit sources can get ghost identities (e.g., `naval@x.livingip.ghost`) that resolve to real identities when they claim them. The standardized email format `{identifier}@{platform}.livingip.ghost` enables cross-platform merge logic: when a real person claims their ghost, all contributions across platforms (X, chat, direct submission) consolidate into one identity.
 The ultimate form is a complete attribution chain: human contributor submits source (credited via ghost account or contributor field) → agent extracts claims (credited via Pentagon-Agent trailer and Forgejo ghost account) → reviewer approves (credited via PR review record) → the full provenance from human insight to knowledge base entry is traceable and attributable.
 ---
 Relevant Notes:
 - [[Git-traced agent evolution with human-in-the-loop evals replaces recursive self-improvement as credible framing for iterative AI development]] — git trailers are the specific mechanism that makes agent evolution traceable
 - [[source archiving with extraction provenance creates a complete audit trail from raw input to knowledge base output because every source records what was extracted and by whom]] — source archives cover the input side, trailers cover the output side
 - [[usage-based value attribution rewards contributions for actual utility not popularity]] — attribution is the prerequisite for value-based credit
 Topics:
 - [[collective agents]]
--- a/core/living-agents/human-in-the-loop
+++ b/core/living-agents/human-in-the-loop
@ -0,0 +1,67 @@
 ---
 type: claim
 domain: living-agents
 description: "The Teleo collective operates with a human (Cory) who directs strategy, approves architecture, and overrides when needed — while agents handle the volume work of extraction, synthesis, and routine review"
 confidence: likely
 source: "Teleo collective operational evidence — human directs all architectural decisions, OPSEC rules, agent team composition, while agents execute knowledge work"
 created: 2026-03-07
 ---
 # Human-in-the-loop at the architectural level means humans set direction and approve structure while agents handle extraction synthesis and routine evaluation
 The Teleo collective is not an autonomous AI system. A human (Cory) sits at the top of the governance hierarchy, making decisions that agents cannot and should not make autonomously: strategic direction, team composition, OPSEC rules, architectural approvals, and override authority. Agents handle the volume work — extraction, synthesis, review, and routine operations — where AI capability exceeds human bandwidth.
 ## How it works today
 The division of authority is:
 **Human decides:**
 - Strategic priorities (which sources to process, which domains to grow, what to build next)
 - Team composition (which agents exist, what roles they fill, when to add or remove agents)
 - OPSEC rules (no dollar amounts in public materials — established mid-session, immediately enforced across all agents)
 - Architectural direction (cloud-primary vs local, Forgejo migration, multi-model diversity)
 - Override on any agent decision (Cory can approve, reject, or redirect any PR, task, or plan)
 **Agents decide (within human-set constraints):**
 - Which claims to extract from assigned sources
 - How to structure arguments and evidence in claim bodies
 - Which wiki links to add, what confidence level to assign
 - Review verdicts on each other's PRs (accept/reject/request changes)
 - Cross-domain synthesis — which connections to propose
 - Musing development — exploratory thinking within their domains
 **Shared authority (agent proposes, human approves):**
 - Architecture plans (Rhea and Ganymede design, Leo evaluates, Cory approves)
 - New agent assignments (Leo recommends, Cory decides)
 - Process changes (agents propose PR to CLAUDE.md or schemas, reviewed and merged through normal PR process, but Cory can override)
 ## Evidence from practice
 - **OPSEC enforcement.** Cory established mid-session that no dollar amounts or valuations appear in public materials. This was immediately enforced — Rio scrubbed PR #43, Leo scrubbed PR #42 musings and position files. The rule cascaded to all agents within one session. No agent could have established this rule autonomously because it requires understanding the legal and strategic context of public disclosure.
 - **Architecture direction.** Cory corrected Leo multiple times when Leo over-emphasized the Mac Studio as the platform. The definitive answer — cloud is primary, Mac Studio is Cory's terminal — required human knowledge about infrastructure plans, budget, and operational preferences that no agent had access to.
 - **Team composition.** Cory added Venus, Saturn, Rhea, Oberon, Ganymede, and Mercury to the organization. Leo audited them and recommended gap-filling (platform connector, blockchain, orchestrator), but the hiring decisions are human.
 - **Source routing.** Cory directs which sources to extract ("we need to rerun extraction on all historical tweets"). Agents don't autonomously decide to process the entire LivingIP v1 database — that directive came from human strategic judgment.
 ## What this doesn't do yet
 - **No automated escalation.** When an agent encounters a decision that exceeds its authority (e.g., a claim that has OPSEC implications), there is no formal escalation mechanism. The agent either catches it or doesn't. Structured escalation rules would define triggers for human review beyond the standard PR process.
 - **No permission tiers.** All agents have the same technical access to the repository. A domain agent could theoretically push to main or modify files outside their territory. The first enforcement tier is CI-based: pre-merge checks for schema validation, trailer verification, territory enforcement, and link health will reject PRs that violate boundaries even without platform-level ACLs. The second tier is Forgejo repository permissions, which add platform-level access control. CI-as-enforcement comes first and is independent of the Forgejo migration.
 - **Human bandwidth is the bottleneck.** Cory reviews agent output, directs strategy, and manages the organization. As the collective scales, this becomes unsustainable. The system needs to define which decisions can be fully delegated to agents and which always require human approval.
 ## Where this goes
 The immediate improvement is defining explicit escalation triggers: OPSEC-relevant content, cross-territory modifications, architecture changes, and belief/position updates that affect public commitments all trigger human review.
 The next step is permission tiers on Forgejo: domain agents can only write to their territory, Leo can write to `core/` and `foundations/`, architecture agents can write to infrastructure specs, and main branch protection requires human approval for merges that touch CLAUDE.md, schemas, or skills.
 The ultimate form maintains human authority at the architectural level while delegating routine operations completely: agents run on VPS, ingest content, extract claims, review each other's work, and post to X — all autonomously within human-set constraints. The human reviews dashboards, approves structural changes, and intervenes when the system's behavior diverges from intent. The human never needs to read every PR, but always can.
 ---
 Relevant Notes:
 - [[adversarial PR review produces higher quality knowledge than self-review because separated proposer and evaluator roles catch errors that the originating agent cannot see]] — PR review is one of the mechanisms that operates within human-set constraints
 - [[agents must evaluate the risk of outgoing communications and flag sensitive content for human review as the safety mechanism for autonomous public-facing AI]] — outgoing communications are a specific case where human-in-the-loop is safety-critical
 - [[centaur teams succeed only when role boundaries prevent humans from overriding AI in domains where AI is the stronger partner]] — the Teleo model respects this by not having humans re-extract claims or re-review evidence that agents handle better
 Topics:
 - [[collective agents]]
--- a/core/living-agents/musings
+++ b/core/living-agents/musings
@ -0,0 +1,52 @@
 ---
 type: claim
 domain: living-agents
 description: "The Teleo musing layer gives agents a personal workspace for developing ideas before extraction — with one-way links to claims, no review required, and stale detection after 30 days"
 confidence: experimental
 source: "Teleo collective operational evidence — musing schema (PR #29), Rio's 8 musings, Leo's 2 musings"
 created: 2026-03-07
 ---
 # Musings as pre-claim exploratory space let agents develop ideas without quality gate pressure because seeds that never mature are information not waste
 The Teleo knowledge base has a layer below claims: musings. These are per-agent exploratory notes where agents develop ideas, connect dots, flag questions, and build toward claims — without passing the quality gates that claims require. A musing that never becomes a claim is not a failure; it is a record of a line of reasoning that was explored and found insufficient.
 ## How it works today
 Musings live in `agents/{name}/musings/` and follow the schema in `schemas/musing.md`:
 - **Status lifecycle:** seed → developing → ready-to-extract → extracted | stale
 - **No review required.** Musings are personal workspaces. They enter the repo through PRs (for git tracing) but the review bar is "does this follow the musing schema" not "is this argument convincing."
 - **One-way linking.** Musings link TO claims (`[[claim title]]`). Claims never link to musings. This prevents the shared knowledge base from depending on personal exploratory notes.
 - **Stale detection.** Seeds untouched for 30 days get flagged for triage — either develop them or acknowledge they're dead ends.
 - **Structured markers.** `CLAIM CANDIDATE:` marks a specific extractable insight. `FLAG @agent:` requests input from another agent. `QUESTION:` tracks open issues. `SOURCE:` points to evidence.
 Currently the collective has ~10 musings across agents: Rio has 8 (including 5 vehicle design musings on Theseus's Living Capital structure), Leo has 2 (compliance-is-not-alignment, theseus-living-capital-deal-map).
 ## Evidence from practice
 - **Rio's 5 vehicle design musings** (PR #43) surfaced 4 claim candidates that no existing claim covered: tiered governance thresholds, NAV-floor arbitrage, circular economy risk classification, and predetermined investment Howey weakness. These emerged from working through the operational details of a specific vehicle design — a process too messy and iterative for the claim format.
 - **Rio's leverage musing** identified a connection between permissionless leverage and futarchy governance quality that feeds an investment position on OMFG. The musing is the working space; the position is the output.
 - **Leo's compliance-is-not-alignment musing** has 3 claim candidates in development. The ideas are not ready for extraction because the evidence needs strengthening. Without the musing layer, these would either be forced into premature claims (low quality) or lost (no record).
 - **The musing schema was itself proposed and reviewed** (PR #29). Rio, Clay, and Calypso all approved it because it matched workflows they were already doing informally.
 ## What this doesn't do yet
 - **Stale detection is not automated.** The 30-day flag for untouched seeds exists in the schema but is not implemented as tooling. No agent or script checks musing dates and surfaces stale seeds.
 - **CLAIM CANDIDATE markers are not aggregated.** There is no dashboard or report that collects all `CLAIM CANDIDATE:` markers across all agents' musings. Each agent tracks their own.
 - **Cross-agent musing visibility varies.** All musings are in the shared repo (readable by everyone), but agents don't systematically read each other's musings. The `FLAG @agent:` marker exists for explicit requests, but passive discovery of relevant musings across agents doesn't happen.
 ## Where this goes
 The immediate improvement is a periodic sweep: Leo reads all musings monthly and identifies claim candidates that are ready for extraction, cross-agent connections that no individual agent sees, and stale seeds that should be triaged.
 The ultimate form includes: (1) automated stale detection that surfaces seeds untouched for 30 days, (2) a claim candidate aggregator that collects all `CLAIM CANDIDATE:` markers into a pipeline view, (3) cross-agent musing discovery where agents are notified when another agent's musing touches their domain, and (4) musing-to-claim conversion tracking that measures how many musings produce claims vs how many are archived as dead ends — both being valid outcomes.
 ---
 Relevant Notes:
 - [[adversarial PR review produces higher quality knowledge than self-review because separated proposer and evaluator roles catch errors that the originating agent cannot see]] — musings bypass the quality gate; claims extracted from musings still go through full review
 - [[confidence calibration with four levels enforces honest uncertainty because proven requires strong evidence while speculative explicitly signals theoretical status]] — musings exist below the confidence system entirely; they don't carry confidence because they're not yet claims
 Topics:
 - [[collective agents]]
--- a/core/living-agents/prose-as-title
+++ b/core/living-agents/prose-as-title
@ -0,0 +1,61 @@
 ---
 type: claim
 domain: living-agents
 description: "The Teleo codex requires every claim title to be a full prose proposition that passes the test 'This note argues that [title]' — this constraint has demonstrably filtered vague claims and forced sharpening across 339+ claim files"
 confidence: likely
 source: "Teleo collective operational evidence — Ars Contexta design methodology applied across 339+ claims"
 created: 2026-03-07
 ---
 # Prose-as-title forces claim specificity because a proposition that cannot be stated as a disagreeable sentence is not a real claim
 Every claim in the Teleo knowledge base has a title that IS the claim — a full prose proposition, not a label or topic name. This is the simplest and most effective quality gate in the system. If you cannot state the claim as a sentence someone could disagree with, it is not specific enough to enter the knowledge base.
 ## How it works today
 The claim test is: "This note argues that [title]" must work as a grammatically correct sentence that makes an arguable assertion. This is checked during extraction (by the proposing agent) and again during review (by Leo).
 Examples of titles that pass:
 - "futarchy is manipulation-resistant because attack attempts create profitable opportunities for defenders"
 - "one year of outperformance is insufficient evidence to distinguish alpha from leveraged beta"
 - "healthcare AI creates a Jevons paradox because adding capacity to sick care induces more demand for sick care"
 Examples of what gets rejected:
 - "futarchy manipulation resistance" — this is a label, not a claim
 - "AI in healthcare" — this is a topic, not a proposition
 - "token launch mechanisms" — no assertion, nothing to disagree with
 The constraint propagates through the system. Because titles are propositions, wiki links between claims carry semantic weight: `[[futarchy is manipulation-resistant because...]]` in surrounding prose reads as a citation of a specific argument, not a pointer to a topic. This makes the knowledge graph navigable by reading, not just by following links.
 ## Evidence from practice
 Across 339+ claim files and 43 merged PRs, the prose-as-title constraint has:
 1. **Forced splitting of vague claims.** When a proposer tries to write "AI will change healthcare," the title test forces them to specify WHICH change, WHAT mechanism, and WHY — often producing 3-5 specific claims from what started as one vague one.
 2. **Made the knowledge base searchable by reading.** An agent encountering a wiki link can understand the cited claim's argument without opening the file. This is critical for cross-domain synthesis — Leo can read a chain of wiki links and understand the reasoning path.
 3. **Created a natural duplicate detector.** Two claims with nearly identical prose titles are obviously duplicates. Two claims with label-style titles ("AI healthcare" and "healthcare AI") could be the same claim or completely different ones.
 4. **Enabled the description field to add value.** Because the title carries the core proposition, the `description` field in frontmatter adds context beyond the title — methodology, scope, domain-specific framing. If titles were labels, descriptions would just restate what the note is "about."
 ## What this doesn't do yet
 - **No automated title validation.** The prose-as-title test is applied by agents during extraction and review. There is no CI check or linter that verifies titles are propositions rather than labels.
 - **Title length varies widely.** Some titles are concise ("coin price is the fairest objective function for asset futarchy") while others are long clauses. No guidance exists on optimal title length.
 - **Filename slugification is inconsistent.** The mapping from prose title to filename slug is not standardized — some use hyphens, some use spaces, capitalization varies.
 ## Where this goes
 The immediate improvement is a simple CI check: does the title contain a verb? Does it pass basic sentence structure? This catches the worst offenders (pure labels) without requiring NLP sophistication.
 The ultimate form combines prose-as-title with structured evidence: every claim title is a disagreeable proposition, every claim body traces the evidence chain from source quotes through reasoning to the title's conclusion, and the graph of wiki-linked propositions is traversable as a connected argument, not just a linked directory.
 ---
 Relevant Notes:
 - [[collaborative knowledge infrastructure requires separating the versioning problem from the knowledge evolution problem because git solves file history but not semantic disagreement or insight-level attribution]] — prose-as-title addresses the semantic layer that git alone cannot
 - [[cross-domain knowledge connections generate disproportionate value because most insights are siloed]] — prose titles make cross-domain links readable without opening files
 Topics:
 - [[collective agents]]
--- a/core/living-agents/source
+++ b/core/living-agents/source
@ -0,0 +1,58 @@
 ---
 type: claim
 domain: living-agents
 description: "The Teleo codex archives every source with standardized frontmatter tracking processing status, extracted claims, and extraction agent — creating an audit trail that currently covers 54 sources across 5 domains"
 confidence: likely
 source: "Teleo collective operational evidence — schemas/source.md + 54 archive files standardized in PR #41"
 created: 2026-03-07
 ---
 # Source archiving with extraction provenance creates a complete audit trail from raw input to knowledge base output because every source records what was extracted and by whom
 Every source that enters the Teleo knowledge base gets an archive file in `inbox/archive/` with standardized frontmatter that records: what the source was, who processed it, when, what claims were extracted, and what status it has. This creates a bidirectional audit trail — from any claim you can trace back to its source, and from any source you can see what claims it produced.
 ## How it works today
 Source archive files use the schema defined in `schemas/source.md` (standardized in PR #41). Each file contains:
 ```yaml
 status: unprocessed | processing | processed | null-result
 processed_by: [agent name]
 processed_date: YYYY-MM-DD
 claims_extracted:
  - "[[claim title 1]]"
  - "[[claim title 2]]"
 ```
 The workflow: a source arrives (article, tweet thread, paper, transcript). The proposing agent creates or updates an archive file, sets status to `processing`, extracts claims, then updates to `processed` with the list of extracted claims. If the source yields no extractable claims, it gets `null-result` with explanation (e.g., "marketing announcement — no mechanisms, no data").
 Currently 54 sources are archived: 30 processed, 8 unprocessed, 1 partial. Sources span articles (Noahopinion, Citrini Research, Aschenbrenner), whitepapers (Doppler, Solomon Labs), thread analyses (Claynosaurz, MetaDAO), and data reports (Bessemer State of Health AI, Pine Analytics).
 ## Evidence from practice
 - **Null-result tracking prevents re-extraction.** Rio's Doppler announcement article extraction returned null-result — "marketing announcement, no mechanisms, no data." The null-result archive distinguished this empty source from the actual Doppler whitepaper (which was separately processed and produced 1 claim), preventing confusion between two different sources about the same project.
 - **Claims-extracted lists enable impact tracing.** When reviewing a claim, Leo can check the source archive to see what else was extracted from the same source. If 5+ claims came from one author, the source diversity flag triggers.
 - **Processed-by field attributes extraction work.** Each source records which agent performed the extraction. This enables: contributor credit (the human who submitted the source), extraction credit (the agent who processed it), and quality tracking (which agent's extractions get the most changes requested during review).
 - **Unprocessed backlog is visible.** The 8 unprocessed sources (harkl, daftheshrimp, oxranga, citadel-securities, pineanalytics x2, theiaresearch-claude-code, claynosaurz-popkins) are a clear task list for domain agents.
 ## What this doesn't do yet
 - **No contributor attribution on sources.** The archive records who submitted and who processed, but not the original author's identity in a structured field that could feed ghost account creation or credit attribution. The `source` field in frontmatter is free text. The planned fix: a structured `author` block with name, handle, platform, and contributor_file reference — bridging source archiving to the ghost identity system so the audit trail reaches from "who contributed the original insight" through "who extracted" to "who reviewed."
 - **Historical sources from LivingIP v1 are not archived.** The `ingestedcontent` table in LivingIP's MySQL database contains tweets and documents that predate the codex. These have been found (Naval's "Wisdom of Markets" tweet, among others) but not yet re-extracted. Some were wrongly rejected by the v1 system.
 - **No automated source ingestion.** Sources currently arrive through human direction (Cory drops links, agents find material). There is no RSS feed, X API listener, or scraping pipeline that automatically surfaces sources for extraction.
 - **GCS blob access unverified.** Document content from the LivingIP v1 system is stored in Google Cloud Storage. Whether these blobs are still accessible has not been confirmed.
 ## Where this goes
 The immediate improvement is re-extracting historical content. Ben (human engineer) exports the `ingestedcontent` and `document` tables from LivingIP's MySQL database. Venus designs the re-extraction methodology. Domain agents process the content. Saturn's contributor attribution schema gives original contributors credit through ghost identities on Forgejo.
 The ultimate form is an automated ingestion pipeline: X API + RSS + manual submission feed into a SQLite staging database, a Tier 1 filter (lightweight local model) routes relevant content to domain agents, extraction happens automatically, and every source — from tweet to whitepaper — gets a permanent archive with full provenance. High ingest volume (1000+ sources/day screened), low extraction rate (~10/day through expensive models), lower still review rate (~5/day through adversarial evaluation).
 ---
 Relevant Notes:
 - [[adversarial PR review produces higher quality knowledge than self-review because separated proposer and evaluator roles catch errors that the originating agent cannot see]] — source archiving feeds the review process with provenance
 - [[collaborative knowledge infrastructure requires separating the versioning problem from the knowledge evolution problem because git solves file history but not semantic disagreement or insight-level attribution]] — source archiving is the attribution layer
 Topics:
 - [[collective agents]]
--- a/core/living-agents/wiki-link
+++ b/core/living-agents/wiki-link
@ -0,0 +1,56 @@
 ---
 type: claim
 domain: living-agents
 description: "The Teleo knowledge base uses wiki links as typed edges in a reasoning graph where claims ground beliefs and beliefs ground positions, creating chains that any agent can audit from conclusion back to evidence"
 confidence: experimental
 source: "Teleo collective operational evidence — belief files cite 3+ claims, positions cite beliefs, wiki links connect the graph"
 created: 2026-03-07
 ---
 # Wiki-link graphs create auditable reasoning chains because every belief must cite claims and every position must cite beliefs making the path from evidence to conclusion traversable
 The Teleo knowledge base is a directed graph where wiki links are the edges. Claims cite evidence and other claims. Beliefs cite 3+ claims as grounding. Positions cite beliefs as their basis. This creates a chain from raw evidence through interpretation to public commitment that any agent — or any human — can follow backward from any conclusion to its foundations.
 ## How it works today
 The knowledge hierarchy has three layers:
 1. **Claims** (shared commons) — arguable propositions backed by evidence. Live in `core/`, `foundations/`, and `domains/`. Currently 339+ claim files across 13 domains. Each claim's body contains inline evidence (data, quotes, studies) and wiki links to related claims.
 2. **Beliefs** (per-agent) — worldview premises grounded in 3+ claims. Each agent maintains `agents/{name}/beliefs.md` with beliefs that cite specific claims as their foundation. When underlying claims change, beliefs are flagged for review.
 3. **Positions** (per-agent) — trackable public commitments with performance criteria. Positions cite beliefs as their basis and include `review_interval` for periodic reassessment. When beliefs change, positions are flagged for review.
 The wiki link format `[[claim title]]` embeds the full prose proposition in the linking context. Because titles are propositions (not labels), the link itself carries argumentative weight: writing `[[futarchy is manipulation-resistant because attack attempts create profitable opportunities for defenders]]` in a belief file is simultaneously a citation and a summary of the cited argument.
 ## Evidence from practice
 - **Rio's beliefs.md** cites 15+ specific claims as grounding for beliefs about internet finance market structure, with explicit reasoning for each belief-to-claim connection.
 - **Theseus's position on LivingIP investment** cites claims from AI alignment, Living Capital, and mechanisms domains — a cross-domain reasoning chain that traces from mathematical impossibility theorems through market gaps to a specific investment thesis.
 - **Leo's synthesis claims** (batches 1-4) each cite claims from 2+ domains, with the wiki links serving as the evidence that the cross-domain connection is real and grounded, not analogical.
 - **Cascade detection works because links exist.** When PR #42 was reviewed, Rio traced from the voluntary commitment claim back through its wiki-linked claims to check whether the mechanism citations were accurate. The link chain was the audit trail.
 ## What this doesn't do yet
 - **Cascade is manual.** The cascade skill (skills/cascade.md) describes automatic flagging of beliefs and positions when underlying claims change. In practice, this is done by reviewer memory — Leo and domain agents notice when a claim change should affect beliefs. There is no automated tooling that traces the dependency graph and flags affected beliefs/positions.
 - **Link integrity is not verified automatically.** Wiki links can break when claim files are renamed, moved, or deleted. Broken links are caught during PR review but not by CI. Some claims reference files that exist only on other branches.
 - **No graph visualization.** The knowledge graph exists as a set of text files with wiki links. No tooling renders the graph, measures connectivity, or identifies orphan claims. Agents build mental models of the graph structure through reading.
 - **Belief-to-claim grounding varies in quality.** Some beliefs cite claims with explicit reasoning. Others list claims without explaining HOW the claim supports the belief. The 3+ claim minimum is enforced but the quality of the grounding explanation is not standardized.
 ## Where this goes
 The immediate improvement is a link integrity CI check: verify that every `[[wiki link]]` in the repository resolves to an actual file. This catches broken links at PR time rather than during review.
 The next step is automated cascade detection: when a claim file changes, trace all files that wiki-link to it and flag them for review. This turns the manual cascade skill into tooling.
 The ultimate form is a live knowledge graph where: (1) every link is verified to resolve, (2) claim changes automatically flag affected beliefs and positions, (3) the graph is visualizable so agents and humans can see the structure of the collective's reasoning, and (4) orphan claims (no inbound links) are surfaced for integration or retirement.
 ---
 Relevant Notes:
 - [[Living Agents mirror biological Markov blanket organization with specialized domain boundaries and shared knowledge]] — the graph crosses domain boundaries through synthesis claims, connecting specialist knowledge
 - [[cross-domain knowledge connections generate disproportionate value because most insights are siloed]] — wiki links between domains are where the most valuable insights live
 - [[collaborative knowledge infrastructure requires separating the versioning problem from the knowledge evolution problem because git solves file history but not semantic disagreement or insight-level attribution]] — the wiki-link graph is the semantic layer on top of git's versioning layer
 Topics:
 - [[collective agents]]