diff --git a/docs/blog/2026-04-28-why-dark-provenance.md b/docs/blog/2026-04-28-why-dark-provenance.md
new file mode 100644
index 0000000..251b211
--- /dev/null
+++ b/docs/blog/2026-04-28-why-dark-provenance.md
@@ -0,0 +1,105 @@
+# Why We're Building Dark Provenance: A Manifesto
+
+**April 28, 2026** | Scott Scoble | [speckl.dev](https://speckl.dev) (forthcoming)
+
+## The Crisis of Intent
+
+Software development has a dirty secret: we've lost the ability to answer "why does this code exist?"
+
+In the early days, the answer was simple: "Because Fred wrote it." Fred was in the next cube. You could ask Fred. Fred remembered.
+
+Today, Fred is gone. The codebase is 14 years old. The original Jira ticket is archived. The Slack thread ends with "actually let's go with option B" and nothing else. The Git blame shows a commit from `github-actions[bot]`. The PR description says "chore: update dependencies." The real reason the code exists — the intent behind it — is lost to time.
+
+This was already a problem. Then AI showed up.
+
+## The AI Intent Gap
+
+When you ask an LLM to "write a retry handler with exponential backoff, max 3 retries," and it generates 40 lines of TypeScript, a fundamental question arises:
+
+**Who decided on 3 retries?**
+
+Was it you? The LLM? Some pattern in the training data? A bug? Six months later, when an auditor asks for the design decision, the honest answer is: *nobody knows*.
+
+This isn't about hallucinations or reliability. It's about a structural gap: AI-generated code bypasses the entire chain of intent. There's no requirement document, no design spec, no human decision point — just a prompt and some code. The provenance is missing.
+
+## The Compliance Time Bomb
+
+Regulated industries feel this pain first. DO-178C, IEC 62304, ISO 26262 — these standards require traceability from requirements through code. Today's compliance strategies treat LLM outputs like code from a junior developer: subject it to full review.
+
+This works when AI generates 10% of the codebase. When it generates 70%? The review pipeline collapses. The standards assume a human author who can explain intent. An LLM has no intent. It has a probability distribution over tokens.
+
+The result: AI-generated code hits a trust ceiling. It's fine for autocomplete and internal tools. For production systems? Safety-critical code? Regulated environments? It's disqualified by design.
+
+## Dark Provenance: The Solution
+
+Dark provenance is a methodology where every behavior in a system traces back to its original source — a specification, a regulatory requirement, a design decision. The "dark" means you don't think about it until you need it, but the graph is always there.
+
+It's not about documenting AI outputs. It's about capturing intent *before* code generation, in a form that machines can verify and humans can audit.
+
+### How It Works
+
+1. **Write the spec first** — in SpeckDL, a language for defining *what* a system should do, not *how*
+2. **Verify the spec** — with Z3, an SMT solver that catches contradictions before code is written
+3. **Generate the code** — from verified specs, through a deterministic pipeline
+4. **Grow the provenance graph** — automatically, as a side effect of the process
+
+The provenance graph is queryable: "Show me every behavior derived from DO-178C section 6.3" is a graph traversal, not a manual search.
+
+### Why It's Different
+
+Traditional traceability links requirements to code through documents. Dark provenance inverts this: it backward-traces from every runtime behavior to the specification that motivated it.
+
+Specifications are small and stable. Code is large and frequently regenerated. By anchoring provenance to the spec, we make the audit surface tractable regardless of codebase size.
+
+## The Speckl Approach
+
+Speckl implements dark provenance through three mechanisms:
+
+1. **SpeckDL** — a specification language that encodes intent directly
+2. **Verification pipeline** — SpeckDL → Z3 → DST → WASM, deterministic and auditable
+3. **Tiered agent harness** — Orchestrator → Team Lead → SME, with TillDone condition-based tracking
+
+The key insight: if humans review the specification, and the compilation pipeline preserves semantics, then the generated implementation inherits the specification's assurance properties.
+
+This satisfies the *intent* of compliance standards without requiring line-by-line code review.
+
+## Why This Matters
+
+### For Developers
+
+- No more oral tradition. Every behavior has a source.
+- Onboarding becomes querying the provenance graph, not asking "who remembers why this exists?"
+- The spec is the primary artifact. Code is derived. The audit surface stays small.
+
+### For Compliance Teams
+
+- Evidence is always available, not assembled under deadline pressure
+- The provenance graph provides traceability matrices automatically
+- Human review happens at the spec boundary, where it's most effective
+
+### For the Industry
+
+- AI-generated code moves from "might work" to "provably correct"
+- The trust ceiling disappears
+- Agents become the most trusted participants in development
+
+## The Future
+
+Dark provenance enables a future where AI agents don't just generate code — they generate *verified* code. Code that provably satisfies its specification.
+
+This is a qualitative shift. Today's AI coding agents are productivity tools. Tomorrow's verified agents are assurance tools. The difference between "this code was generated by an AI" and "this code was proven correct against its specification" is the difference between a productivity claim and a trust guarantee.
+
+## Join Us
+
+We're building Speckl in public. The specification language, the verification pipeline, the agent harness — all open source, MIT license.
+
+- Read the [whitepaper](https://github.com/sscoble/speckl/blob/main/docs/whitepapers/dark-provenance.md)
+- Explore the [reference agent](https://github.com/sscoble/speckl/tree/main/reference-agent)
+- Follow along as we build
+
+The software industry faces a choice: a future where most software is written by machines and understood by no one, or a future where intent is traceable, provenance is automatic, and AI-generated code is the most trusted code in the system.
+
+We choose the latter. Join us.
+
+--
+*Scott Scoble is the creator of Speckl and the Dark Provenance methodology. He writes about the human side of software development at [scoble.me](https://scoble.me). Speckl is open source under the MIT license. Repository: [github.com/sscoble/speckl](https://github.com/sscoble/speckl)*
\ No newline at end of file
diff --git a/docs/content-calendar.md b/docs/content-calendar.md
new file mode 100644
index 0000000..715dc8d
--- /dev/null
+++ b/docs/content-calendar.md
@@ -0,0 +1,120 @@
+# Speckl Content Calendar
+
+## April 28 - May 11, 2026
+
+### Week 1: Foundation & Vision
+
+**April 28 (Today)**
+- ✅ Publish: "Why We're Building Dark Provenance: A Manifesto" (blog)
+- ✅ Set up Warp monitoring (Twitter/X, LinkedIn, blog)
+- Create content calendar (this document)
+
+**April 30 (Thursday)**
+- Publish: "The AI Intent Gap: Why Current Traceability Fails" (blog)
+- Focus: Deep dive on the structural problem with AI-generated code
+- Target: Technical audience, compliance professionals
+
+**May 2 (Saturday)**
+- Publish: "SpeckDL by Example: Writing Your First Specification" (blog)
+- Focus: Hands-on tutorial with RetryHandler example
+- Target: Developers, architects
+
+### Week 2: Technical Deep Dives
+
+**May 5 (Tuesday)**
+- Publish: "How Z3 Verification Works in Speckl" (blog)
+- Focus: Walkthrough of the verification pipeline
+- Target: Formal methods engineers, security teams
+
+**May 7 (Thursday)**
+- Publish: "Dark Provenance vs Traditional Traceability" (blog)
+- Focus: Side-by-side comparison with Jira/Confluence workflows
+- Target: Engineering managers, compliance teams
+
+**May 9 (Saturday)**
+- Publish: "Building the Reference Agent: Architecture Decisions" (blog)
+- Focus: Why Orchestrator → Team Lead → SME? Why TillDone?
+- Target: Agent developers, systems architects
+
+### Week 3: Adoption & Community
+
+**May 12 (Tuesday)**
+- Publish: "Getting Started with Speckl: Your First 30 Minutes" (blog)
+- Focus: Step-by-step setup and first run
+- Target: Developers ready to try it
+
+**May 14 (Thursday)**
+- Publish: "Dark Provenance for Compliance: DO-178C Case Study" (blog)
+- Focus: How semantic preservation satisfies assurance requirements
+- Target: Aerospace, medical device, automotive teams
+
+## Social Media Strategy
+
+### Warp Monitoring
+
+**Targets:**
+- @warpdotdev (Twitter/X, LinkedIn)
+- Oz agent announcements
+- Technical deep-dives from Warp engineers
+- CEO posts about agents/provenance/orchestration
+
+**Engagement Rules:**
+1. **Don't pitch** — add value, educate, build credibility
+2. **Connect to Speckl concepts** — when they talk about agents, mention provenance
+3. **Be thoughtful** — technical insights > marketing
+4. **Engage authentically** — like, comment, share when genuinely interesting
+
+**Example Responses:**
+- "This is a great point about agent orchestration. At Speckl, we're exploring how provenance graphs can make these interactions auditable — every agent decision traces back to its source spec."
+- "Interesting approach to verification! We're using Z3 in the Speckl pipeline to catch contradictions before code generation. Would love to hear your thoughts on formal methods in agent systems."
+
+## Metrics to Track
+
+- Blog post views and engagement
+- GitHub stars and forks
+- Twitter/X impressions and engagement on Warp-related comments
+- LinkedIn connections and post reach
+- Community contributions (issues, PRs, discussions)
+
+## Content Backlog
+
+**Technical:**
+- "Provenance Graph Queries: Finding the Source of Any Behavior"
+- "TillDone: Why Condition-Based Tracking Beats Status Fields"
+- "SpeckDL Language Design: Why We Chose These Constructs"
+- "The Bootstrapping Problem: Verifying the Verifier"
+
+**Adoption:**
+- "From Jira to Dark Provenance: A Migration Guide"
+- "Dark Provenance for Startups: When to Adopt"
+- "The Business Case for Provenance: ROI of Traceability"
+
+**Industry:**
+- "Dark Provenance in Medical Devices: IEC 62304 Compliance"
+- "Automotive Functional Safety with Speckl: ISO 26262"
+- "Dark Provenance for FinTech: SOC 2 and FedRAMP"
+
+**Community:**
+- "Contributing to Speckl: Where to Start"
+- "The Speckl Roadmap: What's Coming Next"
+- "Meet the Speckl Community: Early Adopter Stories"
+
+## Publishing Workflow
+
+1. **Draft** in `/docs/blog/` with date prefix
+2. **Review** internally (team, advisors)
+3. **Publish** to GitHub (main branch)
+4. **Share** on Twitter/X, LinkedIn, relevant communities
+5. **Engage** with comments and discussions
+6. **Iterate** based on feedback
+
+## Tools & Automation
+
+- **Monitoring:** Use TweetDeck or similar for Warp mentions
+- **Scheduling:** GitHub Actions for regular content reminders
+- **Analytics:** GitHub Insights + social media analytics
+- **Engagement:** Manual for now, consider automation for high-volume
+
+---
+*Last updated: April 28, 2026*
+*Owner: @content (Scobleclaw Content Agent)*
\ No newline at end of file
diff --git a/docs/warp-monitoring.md b/docs/warp-monitoring.md
new file mode 100644
index 0000000..c8f2dc8
--- /dev/null
+++ b/docs/warp-monitoring.md
@@ -0,0 +1,139 @@
+# Warp Monitoring Process
+
+## Objective
+
+Monitor Warp (@warpdotdev) for agent-related announcements, technical insights, and opportunities to engage thoughtfully about dark provenance and Speckl.
+
+## Targets
+
+### Primary Accounts
+
+- **Twitter/X:** [@warpdotdev](https://twitter.com/warpdotdev)
+- **LinkedIn:** [Warp](https://www.linkedin.com/company/warpdotdev)
+- **Blog:** [warp.dev/blog](https://warp.dev/blog)
+
+### Key People
+
+- **Zach Lloyd** (CEO, co-founder) — [@zachlloyd](https://twitter.com/zachlloyd)
+- **Ari Fordsham** (co-founder) — [@arifordsham](https://twitter.com/arifordsham)
+- **Warp Engineering** — [@warpeng](https://twitter.com/warpeng)
+
+## Monitoring Setup
+
+### Tools
+
+- **Twitter/X:** TweetDeck or native Twitter lists
+- **LinkedIn:** Follow company + key people, enable notifications
+- **RSS:** Follow blog via RSS (if available) or subscribe to email updates
+- **Google Alerts:** Set up for "Warp agent" and "Warp Oz"
+
+### Notification Rules
+
+- **Twitter/X:** Enable mobile notifications for @warpdotdev, @zachlloyd, @arifordsham
+- **LinkedIn:** Enable post notifications for Warp company page
+- **Email:** Filter blog updates to a dedicated label/folder
+
+## Engagement Triggers
+
+### High-Priority (Respond within 24h)
+
+1. **Agent announcements** — New features in Oz, agent capabilities, orchestration improvements
+2. **Technical deep-dives** — Blog posts or threads about verification, provenance, safety
+3. **CEO/Founder posts** — Zach or Ari talking about the future of agents
+4. **Provenance-related content** — Any mention of traceability, intent, verification
+5. **Orchestration content** — Agent coordination, multi-agent systems, workflow automation
+
+### Medium-Priority (Respond within 48h)
+
+1. **General agent updates** — Bug fixes, performance improvements
+2. **Community discussions** — Warp team engaging with users about agents
+3. **Industry comparisons** — Warp vs other agent frameworks
+4. **Hiring posts** — Especially for agent/verification roles
+
+### Low-Priority (Monitor, engage if relevant)
+
+1. **General Warp updates** — Non-agent features, company news
+2. **User testimonials** — Unless they mention agents/provenance
+3. **Job postings** — Non-technical roles
+
+## Response Guidelines
+
+### Do's
+
+✅ **Add value first** — Educate, clarify, connect concepts
+✅ **Be technical** — Show deep understanding of the space
+✅ **Mention Speckl naturally** — "At Speckl, we're thinking about this too..."
+✅ **Ask questions** — "How are you handling X? We're exploring Y."
+✅ **Give credit** — "Great insight! This aligns with our thinking on Z."
+✅ **Be concise** — Twitter: 1-2 tweets max. LinkedIn: 2-3 sentences.
+
+### Don'ts
+
+❌ **Don't pitch** — No "Try Speckl!" or "Check out our repo!"
+❌ **Don't argue** — Disagree respectfully or don't engage
+❌ **Don't spam** — One thoughtful response > three shallow ones
+❌ **Don't over-promise** — Stick to what Speckl actually does
+❌ **Don't be generic** — "Great post!" adds no value
+
+## Response Templates
+
+### Agent Announcement
+
+**Example:** Warp announces new Oz agent capabilities
+
+> "This is a great step forward for agent orchestration! At Speckl, we're exploring how provenance graphs can make these multi-agent interactions auditable — every decision traces back to its source specification. Curious if you've thought about intent tracing in Oz's architecture?"
+
+### Verification/Provenance Post
+
+**Example:** Warp talks about verifying agent behavior
+
+> "Verification is key — we're using Z3 in the Speckl pipeline to catch contradictions before code generation. The challenge we see is maintaining provenance: how do you trace agent decisions back to their original intent? Would love to hear your approach."
+
+### Orchestration Post
+
+**Example:** Warp discusses agent coordination
+
+> "Orchestration at scale is fascinating. We're using a tiered model (Orchestrator → Team Lead → SME) with condition-based task tracking (TillDone). How does Oz handle dynamic team scaling and task decomposition? Any lessons learned?"
+
+### Safety/Critical Systems Post
+
+**Example:** Warp mentions agents in regulated environments
+
+> "The compliance challenge is real. We're working on 'dark provenance' — automatic traceability from every behavior back to its source spec. For DO-178C/IEC 62304, this lets humans review specs (small, stable) instead of generated code (large, volatile). Have you explored similar approaches?"
+
+## Tracking & Metrics
+
+### Engagement Log
+
+Maintain a log in `/docs/warp-engagement.log` with:
+
+```
+YYYY-MM-DD | Platform | Post URL | Response | Engagement (likes/replies)
+```
+
+### Monthly Review
+
+1. **Volume:** Number of Warp posts monitored
+2. **Relevance:** % that were agent/provenance-related
+3. **Engagement:** Number of Speckl responses
+4. **Reach:** Impressions/engagement on our responses
+5. **Outcomes:** Follows, mentions, DMs, collaborations
+
+## Automation (Future)
+
+As volume grows, consider:
+
+- **RSS-to-slack:** Pipe Warp blog to a dedicated Slack channel
+- **Twitter API:** Auto-detect agent-related tweets, flag for review
+- **LinkedIn alerts:** Browser extensions for real-time notifications
+- **Response templates:** Pre-approved snippets for common topics
+
+## Ownership
+
+- **Primary:** @content (Scobleclaw Content Agent)
+- **Backup:** @cos (Scobleclaw Orchestrator)
+- **Review:** Weekly sync in #content channel
+
+---
+*Last updated: April 28, 2026*
+*Status: Active monitoring started*