Why now: AI-augmented development (Devin) is shipping real PRs today, making the trust problem urgent. The updated Graduated Trust document now links concrete evidence (Devin case study), existing protocols (Secure Scuttlebutt), Seed's own community models, and P2P trust primitives into a coherent argument.

NEW evidence (2026-07-28): The Community Models in Seed document is now cross-linked from the Graduated Trust proposal, providing the actual Seed substrate: formal communities (explicit membership, role-based permissions) and user web of trust (one-way follows for discovery/filtering). This transforms Graduated Trust from "interesting proposal" to "buildable on Seed today." The argument is no longer abstract — Seed has the primitives.

NEW opportunity: Write a "Seed Already Has the Trust Primitives" essay that bridges Community Models + contacts-as-vouching + capabilities-as-delegated-trust + documents-as-policy-layer into one narrative. This is the "why Seed" argument that the Graduated Trust proposal needs as a companion piece.

Impact: High — defines a new category of thinking about AI safety in OSS
Effort: Medium — write series of 3-5 articles, then a talk/workshop
Confidence: 8/10 → 9/10 (upgraded — Community Models ground the theory in working Seed primitives)
Compounds: Yes — every piece feeds the next; could become a book

Action: Write a "Graduated Trust in Practice" piece using the Devin case study as narrative spine. Then write "Seed Already Has the Trust Primitives" as the companion.

Why now: The LLM Wiki project document is a 3,000+ word, fully specified proposal — one of the most thorough feature specs in the repository. It covers: document tree structure, processing pipeline, entity/topic/contradiction pages, self-healing mechanisms (version tracking, deletion handling, periodic regeneration), human-override semantics, and bidirectional cross-references through existing Seed link infrastructure. This is not a vague idea — it's a blueprint.

Why this is a content opportunity, not just a product one: The LLM Wiki is a story about architectural philosophy — building on existing primitives (not creating new storage), respecting human intent over automation, designing for self-healing rather than perfection. This philosophy applies beyond Seed. An essay about "How We Design Self-Healing Systems at Seed" would attract system architects, knowledge management enthusiasts, and LLM application builders.

Impact: Medium-High — establishes Seed's architectural voice, attracts knowledge management audience
Effort: Medium — one detailed architectural essay (3-4k words) + interview-style breakdown
Confidence: 8/10 — spec is complete enough to write a compelling essay
Compounds: Yes — LLM Wiki content positions Seed as a knowledge platform, not just a hypermedia protocol

Action: Publish "How We're Building an LLM-Powered Wiki Into Seed" — architectural deep-dive framed as design philosophy.

Why now: The Query Blocks and Databases document has rich technical detail. The architectural choice is clear: schemaless attributes with query-defined lenses (Rich Hickey approach). This is a core Seed product feature.

NEW evidence (2026-07-28): Horacio updated the Query Blocks document with additional implementation details on attribute types (text, number, datetime, boolean, select, multi-select, URL), new design explorations, and rabbit-hole notes on spreadsheets, formulas, and block-level attributes.

Impact: High — unlocks Seed as a Notion/Obsidian competitor
Effort: High — requires backend indexing API + UI
Confidence: 9/10
Compounds: Yes — attribute system enables all future structured data features

Action: Publish an architectural decision record; prioritize in product roadmap.

Why now: The "X, Y and Y replied" UI pattern and the trust graph are the same graph viewed at different distances — UI relevance signals use short distances (2-3 hops), contribution scoring uses the full graph. Making this connection explicit is a strategic argument about Seed's unified data model.

NEW connection (2026-07-28): The Community Models document defines two trust models explicitly — formal communities (mutual membership, role-based) and user web of trust (one-way follows, discovery/filtering). These are the two graphs that map to the two use cases. Formal communities map to contribution scoring (roles determine trust distance). Web of trust maps to UI relevance (followed accounts' replies shown first). This gives us a clear taxonomy.

Impact: Medium — improves engagement and network effects
Effort: Low-Medium — UI work, no new infrastructure
Confidence: 7/10 → 8/10 (upgraded — Community Models taxonomy clarifies the dual-graph architecture)
Compounds: Yes — social signals improve all content surfaces

Action: Write a short essay: "Two Graphs, One Seed: How Community Models and Web of Trust Power Social UI." Then prototype "trusted replies" widget.

Why now: The Create Comments design story is mature with acceptance criteria, flows, and video demos.

Impact: Medium — essential for collaboration but not differentiating
Effort: Medium — full UX implementation + backend
Confidence: 9/10
Compounds: Partially — enables other features (review workflows)

Action: Support the design implementation; write a post about "collaborative annotations on a P2P hypermedia system."

Why now: The Graduated Trust document links to the P2P Technologies Trust & Safety knowledge base. A "Graduated Trust Explained" resource could serve as an entry point for newcomers.

Impact: Medium-High — establishes authority, drives traffic
Effort: Low — repurpose existing writing into a structured guide
Confidence: 6/10
Compounds: Yes — becomes evergreen reference

Action: Extract core concepts from Graduated Trust into a standalone explainer document.

---