b3e8a9a058
Major additions: - Community Next.js app (port 18187) for browsing claims with API docs - stemedb-chaos crate: Fault injection, chaos testing, CRDT properties - Latent ingestion system: Reddit/FDA ingesters with ADK-Go agents - Disputed claims handling: Manual review workflows and validation - Aphoria security scanner: New extractors (SQL injection, command injection, weak crypto, TLS version), policy-based ignores, UAT reports - Docker infrastructure: Dockerfile, docker-compose.yml for full stack - VulnBank demo: Intentionally vulnerable multi-language test corpus SDK & API enhancements: - Source registry handlers for tracking data provenance - Metrics endpoint - Skeptic filtering improvements Code quality: - Split 14 large files (>500 lines) into focused modules - All files now under 500-line limit per project guidelines Documentation: - Chaos testing guide, circuit breakers, observability docs - Phase 7 UAT documentation updates - Martin Kleppmann technical writer agent Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2.5 KiB
Community Vision
A technical white paper that eats its own dogfood.
The Idea
The StemeDB white paper makes claims. Dozens of them. Right now they look like facts—printed in authoritative academic prose. But they're claims: some well-sourced, some design decisions, some complexity assertions that haven't been benchmarked.
By highlighting claims in the paper itself, we demonstrate the core thesis visually. The reader sees: "Oh, this sentence isn't a fact—it's a claim, with a source (or without one), with a confidence level, potentially contested."
The paper becomes a live demo of what StemeDB does.
What a Reader Sees
- Normal reading experience — The paper reads like any academic paper
- Subtle highlights — Claims have a dotted underline (amber, unobtrusive)
- Click to inspect — Clicking a claim reveals:
- Source attribution (with tier badges: T0 Regulatory, T1 Peer-reviewed, etc.)
- Confidence level (0-100%)
- Conflict status (Unanimous / Mostly agreed / Contested)
- Notes on nuance or exceptions
Why This Matters
Most whitepapers present claims as facts. This one presents claims as claims—with provenance. It's intellectually honest in a way that traditional documents can't be.
The reader learns what StemeDB is by experiencing it, not just reading about it.
Technical Approach
- Phase 1: Static claims — Claims are hardcoded in the React component with mock data (current state)
- Phase 2: API integration — Claims are fetched from a running StemeDB instance
- Phase 3: Live updates — As new sources are added or conflicts emerge, the paper updates
Claims to Highlight
Priority claims to make interactive:
| Section | Claim | Why |
|---|---|---|
| §1 | "Every mainstream database enforces single value per key" | Foundational claim, has nuance |
| §2 | "CRDTs assume replicas are authoritative copies" | Technical claim about related work |
| §4.2.1 | "RecencyLens is O(n)" | Complexity claim, needs benchmarking |
| §4.2.2 | "ConsensusLens groups by exact object value match" | Design decision with known limitation |
| §6.1 | "Append-only storage grows without bound" | Tradeoff claim |
| §7.1 | "Trust parameters are heuristics without theoretical foundation" | Honest limitation |
Success Criteria
A reader finishes the paper understanding:
- What StemeDB is (a claim-oriented database)
- How it works (Lenses, source tiers, provenance)
- Why it matters (disagreement is information)
...and they understood this by using it, not just reading about it.