{"path":"technical-direction.md","content":"# Deliberus Technical Direction\n\n> **STATUS: EXPLORATORY.** This document maps the technical landscape and potential approaches. No architecture decisions have been made. The right choices depend on deep philosophical work about what Deliberus fundamentally *is* — the ontology shapes the architecture, not the other way around. Stack, framework, and approach are all TBD.\n\n## Architecture Philosophy\n\n**\"Proposer + Verifier\"** — borrowed from Lean's formal verification architecture. The LLM is the creative/search engine; a verification layer is the referee.\n\n- LLMs propose structure (extract claims, identify support/attack relations, suggest premise decompositions)\n- A verification layer checks the output (human votes, NLI models, argument scheme validation)\n- Crowd provides what formal logic can't: relevance judgments, value weights, credibility assessments\n\n## The LLM-Enabled Paradigm Shift\n\nWhat was impossible in 2012 is now viable:\n\n| 2012 Limitation | 2026 Capability |\n|-----------------|-----------------|\n| Manual claim extraction from text | **Claimify-style** LLM decomposition: Select → Disambiguate → Decompose |\n| Manual argument mapping | LLM relation classification (support/attack/qualify) |\n| No semantic dedup | Embedding similarity + LLM verification |\n| Manual moderation only | AI moderation at scale |\n| No real-time collaboration | CRDTs (Yjs), WebSockets |\n| Heroku basic hosting | Graph databases, modern deployment |\n| No entailment checking | NLI models (DeBERTa) + LLM-as-judge |\n\n## Implementation Tiers (Pragmatic Approach)\n\n### Tier 1: Claim Extraction Pipeline (Build First)\n**Text → atomic claims → relations → graph**\n\nFor the current live system in plain language, see [extraction-pipeline.md](extraction-pipeline.md). This section stays at the architecture/tradeoff level.\n\n1. **Claimify-style extraction** via Claude API:\n   - Selection (filter for sentences with verifiable content)\n   - Disambiguation (detect/resolve ambiguities)\n   - Decomposition (atomic, context-independent claims)\n   - Fact/value classification (descriptive vs normative routing)\n\n2. **Relation detection** (support/attack edges):\n   - Embedding similarity for candidate pairs (cheap, fast)\n   - LLM classifier on pairs above threshold\n   - User validation as fallback\n\n3. **Storage**: Claims as nodes, relations as edges in graph database\n\n### Tier 2: Entailment / Logical Kernel (Build Second)\n\nThree levels of increasing formality:\n\n**Level A — LLM-as-judge** (fastest to build):\n- Feed conclusion + premises to LLM\n- Ask: \"Does the conclusion follow? What's missing? What logical error?\"\n- Surface as one signal among many (alongside crowd votes)\n- Weakness: who watches the watchmen?\n\n**Level B — NLI models** (cheap deterministic signal):\n- DeBERTa fine-tuned on MNLI/SNLI → ENTAILS / CONTRADICTS / NEUTRAL\n- Run on every premise→conclusion pair\n- \"Structural coherence score\" — fast, consistent, auditable\n- Use as always-on background signal\n\n**Level C — Semi-formal argument schemes** (the sweet spot):\n- Doug Walton's argument schemes with critical questions\n- E.g., \"argument from expert opinion\": Expert E says X in domain D → X. Critical questions: Is E expert in D? Scope? Agreement? Bias?\n- LLM classifies which scheme a free-text argument fits, auto-fills template, surfaces unanswered critical questions\n- Defeasible but structured and auditable\n- Maps to \"VALID\" badges in the argument bundles sketch\n\n### The Inductive Reasoning Problem (Open Research Agenda)\n\nDeductive arguments are structurally checkable — if premises are true, the conclusion must be true. But most real-world arguments are **inductive**: based on evidence, statistics, probability, analogy, generalization. This was identified as \"the hard problem\" in 2012: *\"Deductive arguments are simpler than inductive arguments — dealing with probability estimates for all claims can get hairy.\"*\n\n**Core question**: Can we move from \"this evidence kinda supports this claim\" to something more like \"this evidence raises the posterior probability of this claim from 0.6 to 0.78, conditional on these assumptions\"? If tractable, this changes how Deliberus stores and displays argument strength.\n\n**Nine research areas** (ongoing investigation, will inform ontology design):\n\n1. **LLMs as Bayesian reasoners** — Can LLMs perform calibrated probabilistic reasoning? Forecasting accuracy vs prediction markets (Metaculus, Manifold). LLM calibration research 2024-2026\n2. **Bayesian argumentation** — Probabilistic extensions to Dung's frameworks. Bayesian argument maps. Combining Bayesian networks with argumentation theory\n3. **Argument strength quantification** — Evidential weight, Bayesian confirmation theory. NLI models (DeBERTa) for entailment probability as a continuous signal, not binary\n4. **Decomposing inductive arguments** — Break \"climate change is human-caused\" into atomic sub-arguments with individual probability estimates that compose. Structured analytic techniques (Analysis of Competing Hypotheses). Inference to the best explanation (IBE) formalization\n5. **Scientific method as algorithm** — Computational formalization of Popper (falsification) + Bayes (updating) + Kuhn (paradigm shifts). Automated hypothesis testing\n6. **Probabilistic programming + argumentation** — Express an argument as a probabilistic program (Pyro, Stan, Turing.jl), compute posterior belief. Could arguments literally be executable models?\n7. **Epistemic calibration** — Superforecasting methods (Tetlock), prediction market structures, calibration training. How to present uncertainty honestly in a UI. Epistemic humility scores\n8. **LLM-assisted evidence weighing** — Using LLMs to evaluate evidence quality, detect cherry-picking, assess statistical reasoning, identify confounders. SAFE framework, ARGUS multi-agent verification\n9. **Real implementations** — Metaculus, Manifold Markets, Good Judgment Open (probabilistic reasoning at scale). Elicit/Ought (decomposing research questions). What can we learn from how they structure and display probabilistic reasoning?\n\nThese areas bridge the gap between Tier 2 (logical/deductive verification) and the reality that most arguments people care about are probabilistic, not certain.\n\n### Truth Graph Read Layer (Apr 8, 2026)\n\nThe \"truth graph\" should not become a second source of record. It is a query-time read layer over the existing argument graph, QBAF strengths, critical questions, contested concepts, sources, and evidence metadata. A short user question can then retrieve the relevant subgraph, compute current strengths, name gaps, and ask an LLM to synthesize the graph's state at the right cognitive resolution.\n\nThe recovered `claude/truth-graph-evidence-system-akm9a` branch prototypes this direction with a `/query` endpoint, `deliberus/truth_graph.py`, quantitative claim metadata, and methodology-adjusted QEM base weights. Treat it as a useful substrate, not a complete merge target: it does not yet wire the landing page into a \"Think with Deliberus\" path, generate the final conversational answer, classify short authored inputs, store private provisional structure, or consistently connect methodology metadata to aggregate badge computation. See [research/truth-graph-evidence-system.md](research/truth-graph-evidence-system.md).\n\nThe synthesis contract matters as much as the retrieval contract. A technically correct query layer can still fail the user if it surfaces internal system language or tangential semantic neighbors as if they were solid help. The first answer should therefore be conservative and plain-language by default: direct answer, what earlier material Deliberus found, what is still unclear, and the best next step. Internal ontology terms stay available deeper in the product, but they should not be the opening copy. False relevance erodes trust faster than an honest \"Deliberus does not have much on this yet.\" See [research/truth-graph-evidence-system.md](research/truth-graph-evidence-system.md), [ux-principles.md](ux-principles.md).\n\nThe next architectural refinement is not \"draft world vs graph world\" but one evolving graph with staged maturity. Extraction output, authored-input dialogue, later clarification, and decomposition should all be able to live in the same overall system as long as provenance and lifecycle are explicit. The important distinction is not whether something is stored, but whether it is raw, draft, candidate, canonical, or superseded, and how much default retrieval influence it should carry. This points toward revision-preserving lineage rather than silent overwrite, and toward influence that grows out of clarification, decomposition, evidence, and later QBAF/QEM/Bayesian evaluation rather than out of age gates alone. See [research/truth-graph-evidence-system.md](research/truth-graph-evidence-system.md), [research/soft-canonical-clustering-and-reversible-merge-semantics.md](research/soft-canonical-clustering-and-reversible-merge-semantics.md).\n\n**Implementation note (Apr 8, 2026, later evening):** The first operational slice of this now exists. Claim nodes can carry `maturity_stage` and `retrieval_weight`; new stored claims default to `candidate`; and default public truth-query/feed surfaces suppress `raw` / `draft` / `superseded` material while honoring explicit retrieval-weight overrides. The next slice is live too: short-authored `/query` responses can persist a `deliberation_drafts` record with the raw turn trace, the first synthesis, and heuristic promotion metadata, while keeping draft persistence best-effort rather than on the critical response path. And the first continuity slice is now live as well: the same draft can continue across turns, with recent trace fed back into the next synthesis. That is still a guardrail, not the full promotion model. The next layer is promotion logic driven by clarification, decomposition, evidence, votes, and later QBAF/QEM/Bayesian signals, plus clearer UI visibility of lifecycle and continuity. See [research/truth-graph-evidence-system.md](research/truth-graph-evidence-system.md).\n\n### Tier 3: Crowd Calibration & Feed (Build Third)\n\n**Scoring**:\n- Multi-axis voting with full distributions (Bayesian average for small-sample stability)\n- Three primary axes from sketches: truthiness, relevance, controversiality\n- Graph-structural score: recursive score propagation (claims supported by well-supported premises + few counterarguments → high structural score)\n- Dung's argumentation semantics for acceptability computation\n\n**Feed algorithm**:\n- Choose between infinite scroll vs \"organic redraw\" (recomputes what matters)\n- Composite ranking: recency × controversiality × structural importance × relevance to user's focus\n- Funnel/threshold at configurable cutoff (60% from sketch)\n\n### Tier 4: Values & Social Dynamics (Later)\n\n**Normative layer**:\n- Classify claims as descriptive vs normative (LLM)\n- For normative claims: score on \"importance\" + \"agreement\" (not true/false)\n- Decompose normative arguments: \"We should reduce emissions\" → value premise + empirical claims\n- Make value structures legible, don't try to compute \"the right answer\"\n\n**Social dynamics**:\n- Tone/emotion analysis (GoEmotions, off-the-shelf)\n- Self-censorship signals: behavioral (deletes, shortened contributions, hedging language)\n- Obfuscation detection: flag low-information-density contributions\n\n## Computational Argumentation Foundations\n\n### Dung's Abstract Argumentation Frameworks\n- Arguments as nodes, attacks as edges\n- Computes which sets of arguments can be jointly accepted\n- Existing solvers: ASPARTIX, ConArg\n\n### ASPIC+ Framework\n- Handles defeasible reasoning (arguments defeated by new information)\n- Structured arguments with strict/defeasible rules\n- Closer to human argumentation than Lean's deductive logic\n\n### Abstract Dialectical Frameworks (ADF)\n- Generalization of Dung — nodes have acceptance conditions\n- More expressive but more complex\n\n### Lean4 Transferable Lessons\n- **Proof trees ≈ argument trees**: theorem depends on lemmas ≈ conclusion depends on premises\n- **Premise selection**: search 210K+ theorems for relevant ones ≈ search existing claims for duplicates\n- **Kernel architecture**: small trusted checker, creative proposer layer\n- **`sorry`-driven argument blueprints**: Lean's `sorry` mechanism (placeholder for unproven lemmas) + Massot's Blueprint tool (color-coded dependency graph of proof status) transfer directly to argument contribution UX. Users sketch argument structure with explicit gaps; the system tracks incompleteness transitively; contributors fill in individual nodes without understanding the whole argument. Tao's PFR project: 25 strangers formalized a 33-page proof in 3 weeks using this pattern. See [research/lean-deliberus-analogies.md §1](research/lean-deliberus-analogies.md)\n- **`@[simp]` accumulated knowledge flywheel**: Each community-vetted claim makes the platform better at auto-connecting future arguments — the `exact?` moment (\"this claim already exists in discussion #X\"). Crowdsourced automation that grows with every contribution. See [research/lean-deliberus-analogies.md §2](research/lean-deliberus-analogies.md)\n- **The definition problem is recursive**: Lean's kernel checks proofs but NOT whether definitions capture the intended concept — definitions require human judgment and social process. Same for Deliberus: the system checks argument structure, but whether terms are defined correctly requires deliberation. The platform's own rules of rational argumentation should be deliberatable. See [research/lean-deliberus-analogies.md §3](research/lean-deliberus-analogies.md)\n- **Deprecation over deletion**: When better formulations emerge, old ones remain linked (not erased). Understanding evolution is content. See [research/lean-deliberus-analogies.md §4](research/lean-deliberus-analogies.md)\n- **Incremental re-validation**: When a claim changes, only re-check dependent arguments — not the entire graph. Lean's Lake build system pattern. See [research/lean-deliberus-analogies.md §7](research/lean-deliberus-analogies.md)\n- **NOT transferable**: deductive certainty, mathematical domain specificity\n- **Full analysis**: [research/lean-deliberus-analogies.md](research/lean-deliberus-analogies.md) (synthesis), [research/lean4-proof-assistant-deep-dive.md](research/lean4-proof-assistant-deep-dive.md) (architecture), [research/lean-social-system-research.md](research/lean-social-system-research.md) (community dynamics)\n\n## Graph Database: FalkorDB via Graphiti\n\nAlready running on Darwin (darwin.home:6380). Graphiti's features map well:\n\n- **Episodes** ≈ source texts ingested\n- **Entities** ≈ claims/propositions\n- **Facts/edges** ≈ support/attack relations\n- **Temporal metadata** ≈ when claims were added, how graph evolves\n- **Group IDs** ≈ separate debate topics/contexts\n\nCould also leverage Darwin's local embeddings engine for semantic search.\n\n## Technology Stack (Current — Mar 31, 2026)\n\n| Layer | Technology | Rationale |\n|-------|-----------|-----------|\n| Graph DB | FalkorDB (direct, `falkordb-py`) | Running on Darwin:6380, scoped to `deliberus_extraction` graph |\n| Relational DB | PostgreSQL 16 (Kamal accessory) | Extraction JSONB storage + user accounts. LAN-exposed :5432. Shared dev/prod |\n| LLM | Gemini 3 Flash via `instructor` + Pydantic | Cost-effective ($0.50/$3.00/1M), structured output, zero JSON failures |\n| Embeddings | Qwen3-Embedding-4B on Darwin (Ollama, :8080) | Local, ~41ms, 1024 dims. SIMILAR_TO edges at 0.80 cosine threshold |\n| Backend | Python (FastAPI) | REST API, SSE streaming, `python-dotenv` for dev |\n| Frontend | SvelteKit (adapter-static) | Served by FastAPI in production, dev server on :5173 |\n| Visualization | D3.js | Force-directed ego-graph on claim pages |\n| Auth | Authlib (Google OAuth) + session cookies | HTTP-only, signed, 14-day expiry. See §Authentication Architecture |\n| Workflows | Temporal 1.24 (Python SDK) | Deploy-surviving extraction pipeline. Separate task queues for dev/prod |\n| Monitoring | Prometheus + ntfy + enhanced health | Auto-instrumented metrics, push notifications, FalkorDB probe, scanner-probe ntfy suppression, doc-read and pipeline-stage notifications |\n| Deploy | Kamal 2.11 → Darwin (Docker + kamal-proxy + TLS) | `kamal deploy` ~25s end-to-end |\n\n## Authentication Architecture (Decided — Mar 30, 2026)\n\n**Google OAuth via Authlib + HTTP-only session cookies.** Extensively researched against JWT, OAuth SaaS (Auth0, Clerk), and self-hosted platforms (Keycloak, Logto). See [research/auth-patterns-deliberation-platforms.md](research/auth-patterns-deliberation-platforms.md) for full analysis.\n\n**Why sessions over JWTs**: Same-origin deployment (SvelteKit + FastAPI on deliberus.com) eliminates JWT's only advantage (cross-service stateless verification). Sessions provide instant revocation (`session.clear()`), no XSS exposure (HTTP-only cookies invisible to JS), no token refresh complexity (`rolling=True` extends on activity). The industry consensus (Curity, OWASP, FastAPI template PR #1606) has shifted to \"JWTs are not sessions.\" JWTs can be added later as a second auth method if third-party API consumers or mobile apps arrive.\n\n**Why Authlib over fastapi-users**: ~30 lines of code, zero ORM coupling, zero framework baggage. User model stays simple and owned by the project. fastapi-users adds batteries (password reset, email verification) not needed until user accounts grow beyond OAuth.\n\n**Tiered pseudonymous model** (planned, from platform research — Kialo, Pol.is, Discourse, Wikipedia patterns):\n- Anonymous: reading, browsing the graph\n- Pseudonymous (session): voting/reactions\n- Pseudonymous with reputation: claim submission, correction\n- Verified identity: moderation, curation\n\n**Key insight from platform research**: Unlike Wikipedia where vandalism is easy in free text, structured argumentation makes low-quality contributions structurally visible — a malformed argument with no supporting claims is self-evidently weak. This means Deliberus can afford lower identity barriers than Wikipedia because the argument structure IS the quality filter. See [research/auth-patterns-deliberation-platforms.md](research/auth-patterns-deliberation-platforms.md).\n\n## Claimify / Claim Extraction (Researched Mar 27, 2026)\n\n**Paper**: \"Towards Effective Extraction and Evaluation of Factual Claims\" (Metropolitansky & Larson, MS Research, ACL 2025). ArXiv: 2502.10855.\n\n**Pipeline**: Sentence splitting (NLTK, no LLM) → three LLM stages per sentence, each a filter:\n\n1. **Selection** — \"Does this sentence contain a specific, verifiable proposition?\" Strips opinions/speculation, keeps facts. \"AI could help healthcare\" → discarded. \"John is CEO of TurboCorp\" → kept. \"The partnership illustrates innovation\" → rewritten to \"There is a partnership between X and Y\". Context window: 5 preceding + 5 following sentences.\n\n2. **Disambiguation** — \"Can a stranger verify this sentence in isolation?\" Resolves \"he\"→\"John Smith\", \"the company\"→\"TurboCorp\", \"last year\"→\"2010\". Key test: would a group of readers reach consensus on the meaning? If ambiguous → discarded entirely (e.g., \"Their approach\" where \"their\" could refer to multiple entities).\n\n3. **Decomposition** — \"Break into smallest discrete facts.\" One compound sentence → multiple atomic claims. \"John and Jane co-founded CleanTech and partnered with MiniMax\" → 4 separate claims. Each gets `[bracketed clarifications]` for context a fact-checker would need.\n\n**Voting**: Stages 1-2 call the LLM **3 times** each, require **2/3 majority agreement** (catches LLM flakiness). Stage 3 calls once (decomposition is more deterministic). Pipeline order is cost-optimized: most sentences get filtered at Stage 1 (cheapest), only clean survivors reach Stage 3.\n\n**Paper hyperparameters**: Temperature 0.0 (selection), 0.2 (others). ~7 LLM calls per surviving sentence (3+3+1), but most sentences get filtered early. ~60-100 API calls per 20-sentence text.\n\n**Key design property**: Every output claim passes the \"stranger test\" — understandable by someone who has never seen the source text. This is what makes claims useful as graph nodes: they're self-contained.\n\n### Implementations\n\n| Implementation | Approach | LLM Provider | Notes |\n|---------------|----------|-------------|-------|\n| **deshwalmahesh/claimify** | Pure Python library, LLM-agnostic | Any (plug in function) | **Best for Deliberus** — 8 stars, faithful to paper, majority voting, accepts `llm(prompt, temperature) -> str` |\n| **ClaimsMCP** (AdamGustavsson) | MCP server | OpenAI (hardcoded) or MCP sampling | 13 stars, Apache 2.0. MCP sampling works with Claude Desktop but NOT Claude Code. OpenAI fallback needs API key |\n| **Microsoft official** | Dataset only | N/A | HuggingFace `microsoft/claimify-dataset` (6,490 annotated sentences) |\n\n### Fastest Path (validated)\n\nClone `deshwalmahesh/claimify`, write 10-line Claude wrapper:\n```python\nimport anthropic\nfrom src.claimify import Claimify\n\nclient = anthropic.Anthropic()\ndef claude_llm(prompt, temperature):\n    r = client.messages.create(model=\"claude-sonnet-4-6-20250514\", max_tokens=2048,\n                                temperature=temperature, messages=[{\"role\":\"user\",\"content\":prompt}])\n    return r.content[0].text\n\nc = Claimify(llm_function=claude_llm)\nclaims = c.extract_claims(question=\"...\", answer=\"...text...\")\n```\n\nNo OpenAI key needed. Uses existing `ANTHROPIC_API_KEY`. ~60 API calls per 20-sentence text.\n\nLocal clone available (includes full paper PDF).\n\n### Claimify vs Deliberus Extraction: Key Divergence\n\nClaimify is designed for **fact-checking** — it explicitly discards opinions, speculation, and normative claims at Stage 1. For Deliberus, those are the most interesting material. The platform needs to harvest opinions AND their underlying reasoning structure.\n\n**Deliberus extraction pipeline** (broader than Claimify):\n\n```\n\"We should ban factory farming because it causes\n animal suffering and accelerates climate change\"\n              │\n     ┌────────┼────────────┐\n  NORMATIVE   EMPIRICAL    EMPIRICAL\n  (opinion)   (premise)    (premise)\n\n  \"Factory    \"Factory     \"Factory farming\n   farming     farming      accelerates\n   should be   causes       climate change\"\n   banned\"     animal\n               suffering\"   ← verifiable\n\n  ← not true/false,        ← verifiable\n    scored on agreement\n    + importance\n```\n\n1. **Extract all claims** (factual AND normative — don't filter opinions)\n2. **Classify**: descriptive vs normative\n3. **Decompose normative claims** into value premises + empirical sub-claims\n4. **Verify empirical parts** (Claimify-style, NLI, or crowd)\n5. **Surface value premises explicitly** — the axioms people usually leave unstated (\"animal suffering matters morally\")\n\nClaimify is a useful **component** for step 4 (verifying the empirical sub-claims), but the extraction mouth must be wider. The opinion isn't discarded — it becomes the **root node** whose premises are judged as granularly and exactly as possible.\n\nThis connects to:\n- The **30°C example** (object-model.md) — \"It's 30°C\" is factual, \"It's hot\" is value-laden. Keep both, categorize separately\n- **Tier 4 normative layer** (below) — decompose normative arguments into value premise + empirical claims\n- **Multi-axis scoring** — truthiness for facts, agreement + importance for normative claims\n\n## Research Landscape (March 2026)\n\n### Available Tools & Libraries\n\n| Tool | What | Maturity | MVP-ready? |\n|------|------|----------|-----------|\n| **pygarg** | Python Dung semantics (SAT-based) | Published in journal, pip-installable | Yes |\n| **ClaimsMCP** | MCP server for Claimify methodology | 13 stars, Apache 2.0, Nov 2025 | Yes (adapt) |\n| **DeBERTa-v3-large-mnli-fever-anli-ling-wanli** | Best NLI model for entailment | 304M params, MIT license, ~90% MNLI | Yes (run on Darwin GPU) |\n| **ARGUS** | Multi-agent claim verification framework | 5 stars, Feb 2026, MIT license | Interesting reference |\n| **adf-obdd** | Rust ADF implementation | 8 stars, maintained 2025 | For later |\n\n### Key Academic Work (2025-2026)\n\n- **ACL 2025**: Claimify paper accepted. LLMs evaluated on Walton scheme classification (promising results).\n- **COLING 2025**: Fine-tuned LLMs achieve SOTA on all argument mining subtasks.\n- **JAIR 2025**: ASPIC+ applied to criminal investigation at Netherlands Police (real-world validation).\n- **Mar 2026**: \"LLM-based Argument Mining meets Argumentation and Description Logics\" — combines LLM extraction with formal frameworks. Most directly relevant to Deliberus.\n- **EACL 2026**: ARGSBASE — multi-agent interface for structured human-AI deliberation with argumentation grounding.\n\n### NLI Accuracy Reality Check\n\n- **Clean benchmarks**: ~90% on MNLI\n- **Adversarial/real-world**: ~60-70% on ANLI\n- **Practical implication**: NLI works as a background signal, not a sole judge. LLM fallback handles hard cases.\n- **Local inference**: 304M param model fits easily on Darwin's GTX 1650 (4GB VRAM)\n\n### Competitive Intelligence Update\n\n- **Polis**: 10M+ participants, national infrastructure in Taiwan/UK/Finland. But zero argument structure — pure opinion clustering.\n- **Kialo**: 5M+ arguments, 200K+ classroom discussions. AI moderation via SentiSight (Mar 2025). But no formal semantics, no NLI, no claim decomposition.\n- **ARG-tech (Dundee)**: Spinning off commercial arm \"Arg Technica Ltd.\" (2025). Leading AI4Deliberation EU Horizon project. The academic leaders.\n- **DELIBERATION.IO** (Stanford + MIT GOV/LAB): Successor to MIT Deliberatorium. Deployed in D.C. city proceedings Jul 2025. Uses Socratic AI dialogue. Open-source.\n- **Delibera.ai**: Commercial multi-perspective AI analysis for legal/financial. Claims MIT research basis.\n- **Market gap**: No platform combines formal argumentation theory + modern LLMs + usable interface.\n\n## Session 3 Research: Adoption & Interaction Architecture (Mar 28, 2026)\n\nFive new research streams address the adoption risk directly. All findings are exploratory — no decisions made — but they sharpen the design space significantly.\n\n**Single-player utility** ([research/single-player-utility.md](research/single-player-utility.md)): The entry point is \"help me think about X\" — the map is output, not goal. Matches Roam/Obsidian adoption pattern. Voice-to-argument contribution on mobile ([research/mobile-argument-ux.md](research/mobile-argument-ux.md)) dissolves the contribution barrier. The graph is a map for orientation, not the primary experience.\n\n**Bridging arguments** ([research/bridging-arguments.md](research/bridging-arguments.md)): Potentially the most novel theoretical contribution. Extends Polis's bridging statements to bridging *reasoning* — arguments whose logic is compelling across opinion groups even when conclusion-agreement diverges. Requires two-axis voting (agree vs well-argued). QBAF extension: per-group strength vectors. No existing platform implements this.\n\n**Epistemic reputation** ([research/epistemic-gamification.md](research/epistemic-gamification.md)): Four independent non-aggregated signals (calibration, argument quality, intellectual honesty, evidence contribution). Metaculus-style strictly proper scoring prevents gaming. r/ChangeMyView's delta system rewards public belief revision.\n\n**Feed design** ([research/feed-algorithm-design.md](research/feed-algorithm-design.md)): Optimize for Bayesian surprise (belief update), not engagement. Bluesky's algorithmic marketplace for feed governance. The sketches' \"organic redraw\" = continuously-recomputed dashboard where arguments are superseded, not chronologically buried.\n\n**Discourse layer warning** ([research/voice-memo-emanuel-sofia.md](research/voice-memo-emanuel-sofia.md)): Emanuel's 2013 insight — semantic agreement can mask discourse-level disagreement. Two people endorsing the same claim may draw opposite conclusions from it. The dedup system must detect this.\n\n## Weakest Links (Honest Assessment)\n\n0. **The structure bet itself** (added Aug 2026) — every choice below assumes typed structure earns its keep against unstructured LLM reasoning. That assumption now has outside evidence on both sides. A reformulation was tried and **retracted the same day**: \"reasoning must be persistent and contestable\" cannot lose, and is satisfied just as well by a forum with permalinks, so it argues for a transcript rather than for this architecture. What survives as a real risk is narrower — **does *typed* structure earn its cost over *cheap* structure, meaning good prose with permalinks and a model over it?** — and it renames the rival: the primary competitor is a well-kept wiki, not unstructured LLM reasoning. Two numbers to hold while reading the rest of this document: on simple retrieval, graphs and plain text are indistinguishable (GraphRAG-Bench, ICLR 2026, 60.9% vs 60.1%), and at 25 sources our whole corpus fits inside one context window, so the retrieval argument for a graph is **not yet live at our size**. Full analysis and how the bet could lose: [structure-versus-scale.md](research/structure-versus-scale.md).\n\n1. **Relation classification quality** — LLMs are decent at obvious support/attack but bad at subtle context-dependent relations. Silent failure mode: graph looks plausible but is wrong.\n2. **Deduplication** — semantic similarity catches obvious duplicates, misses nuanced differences. False merges worse than missed merges. The discourse layer problem (Emanuel 2013) adds another dimension: claims that look identical may carry opposite operative meanings.\n3. **Logical kernel hand-waving** — NLI, argument schemes, LLM-as-judge all work on toy examples. Unproven on messy real-world political/ethical arguments at scale.\n4. **Adoption risk** — Kialo, Debategraph, MIT Deliberatorium, ConsiderIt all worked technically but never reached critical mass. Structured argumentation is effortful. The bet: LLMs reduce friction + single-player utility dissolves the cold-start + mobile voice input dissolves the contribution barrier. Three mutually reinforcing mitigations, not just one.\n\n## Operational Architecture Decisions (Shipped)\n\nNot every decision in this doc is still exploratory. The pipeline has been running in production since Mar 31, 2026, and a handful of operational choices have been made and shipped. They belong in the technical direction because they constrain future architecture work.\n\n**Failure persistence is a first-class concern, not an afterthought.** `extraction_attempts` is a separate Postgres table that receives a row at API submission time (before the Temporal workflow even starts), gets its `source_id` attached once `fetch_url_activity` resolves the slug, and receives its terminal status (`completed` | `empty` | `failed`) from `workflow_lifecycle_activity`. Every submission leaves a row regardless of whether the pipeline reaches `save_extraction`. This fixes the category of silent-failure bug where the success path was the only write path — the exact class that hid the Apr 1–15 extraction outage for 15 days. Future pipeline changes should follow the same pattern: any new terminal state should write a row, and any new code path with `except Exception: return empty` should be treated as a latent production incident. Full rationale: [research/session13-notification-snr-and-extraction-outage-rca.md](research/session13-notification-snr-and-extraction-outage-rca.md) §Problem 2.\n\n**Pydantic response-model fields MUST use `Literal[...]` aliases, never bare `Enum` classes**, when using `instructor.from_provider` + `GENAI_TOOLS` mode. Gemini returns plain strings; Pydantic's `is_instance_of` check rejects them even when the enum inherits from `str`. This rule was introduced in commit `5456f8e` (Mar 31, 2026) but violated one day later by the Session 9 ClaimBase refactor (`0d8a8e3`), which reintroduced an `Enum`-typed field on `AtomicClaim`. The field silently broke every focused extraction for 15 days. Every response-model refactor should include a regression test of the shape `test_*_accepts_plain_string` that forces round-trip validation. See [research/session13-notification-snr-and-extraction-outage-rca.md](research/session13-notification-snr-and-extraction-outage-rca.md) §Problem 3.\n\n**Notification architecture is \"interrupts only.\"** Observability (page views, doc reads, pipeline stages, query volume) lives in Prometheus/logs and a daily digest push, never in per-event phone alerts. The ntfy signal carries only high-value interrupts — new users, real contributions, extraction failures, system errors, client errors — with rich inline forensics (url + user + text preview) so failures self-diagnose from the phone. Owner traffic and known bots are filtered before reaching the notification layer. See [research/session13-notification-snr-and-extraction-outage-rca.md](research/session13-notification-snr-and-extraction-outage-rca.md) §Problem 1 for the three-tier classification and the layered owner-vs-housemate filter.\n\n---\n\n**See also**: [Vision](vision.md) · [Object Model](object-model.md) · [Competitive Landscape](competitive-landscape.md) · [UX Principles](ux-principles.md)\n"}