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>
56 lines
2.5 KiB
Markdown
56 lines
2.5 KiB
Markdown
# 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
|
|
|
|
1. **Normal reading experience** — The paper reads like any academic paper
|
|
2. **Subtle highlights** — Claims have a dotted underline (amber, unobtrusive)
|
|
3. **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
|
|
|
|
1. **Phase 1: Static claims** — Claims are hardcoded in the React component with mock data (current state)
|
|
2. **Phase 2: API integration** — Claims are fetched from a running StemeDB instance
|
|
3. **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:
|
|
1. What StemeDB is (a claim-oriented database)
|
|
2. How it works (Lenses, source tiers, provenance)
|
|
3. Why it matters (disagreement is information)
|
|
|
|
...and they understood this by *using* it, not just reading about it.
|