Email Draft for SovereignSpec

I want to email this guy about sovereignspec https://github.com/jflam

Based on his profile, urlJohn Lam's GitHub profilehttps://github.com/jflam shows that he works on AI coding experiences at Microsoft and has been heavily involved in specification-driven development tooling, agent workflows, and projects like Specify. His public activity suggests he is likely to appreciate a concise, technically grounded message rather than a marketing-style pitch. citeturn0search0turn0search6 Here's a draft you could send: :::writing{variant="email" id="58421" subject="SovereignSpec - Local-First Specification Driven Development"} Hi John, I've been following some of your work around Specify, agent workflows, and specification-driven development. I recently released an open-source project called SovereignSpec that explores a related but somewhat different direction. The core idea is that specifications should become the primary artifact of software development, with AI agents acting as implementation engines rather than the source of truth. SovereignSpec focuses on local-first development, human ownership of specifications, and maintaining durable intent across different coding agents and model providers. Instead of treating prompts as disposable conversations, SovereignSpec attempts to formalize requirements, architecture, implementation plans, and validation criteria into portable specifications that can be executed by Claude Code, Codex, Copilot, local Ollama models, or future agents. The goal is to reduce vendor lock-in while making AI-assisted development more deterministic and reproducible. Repository: https://github.com/kliewerdaniel/sovereignSpec I would be interested in your thoughts, particularly where you think SovereignSpec aligns with or diverges from the design principles behind Specify and other specification-first development systems. Thanks for taking a look. Best, Daniel Kliewer https://www.danielkliewer.com ::: If your goal is to maximize the chance of a response, I would keep the email under 200 words, focus on the overlap with Specify, and explicitly ask for feedback rather than asking him to promote it. People working on developer tooling are generally much more likely to engage with "I'd like your thoughts on this architectural approach" than "please help spread this project."

are you sure it is specify and not spec kit you are thinking of?

Good catch. You're right to question that. I searched before answering, and the evidence points strongly to **Spec Kit**, not "Specify" as a standalone project. John Lam appears to be one of the maintainers and primary advocates behind GitHub's **Spec Kit** project. The confusion comes from the fact that the CLI command is called **`specify`**, but the project itself is **Spec Kit**. citeturn0search8turn0search5 In fact, the official docs repeatedly refer to: - **Spec Kit** (the methodology/toolkit) - **Spec-Driven Development (SDD)** (the philosophy) - **`specify`** (the CLI executable) citeturn0search8turn0search3 What's interesting is that after looking at some of John's comments, he seems particularly interested in the idea that specifications become the long-term source of truth for software systems. In one discussion he literally describes specs as "the source code for the implementation." citeturn0search4 That observation may actually give you a stronger angle for the email. Instead of positioning SovereignSpec as "another spec-driven development tool," you could position it as an exploration of a question that the Spec Kit community is actively debating: > How do specifications remain authoritative over the lifetime of a project rather than just over the lifetime of a feature branch? Looking at the discussions, there appears to be ongoing debate within the Spec Kit community about evolving specs, master specs, and maintaining a durable source of truth. citeturn0search4turn0search2 From what I've seen of SovereignSpec, one of its differentiators is not merely generating plans and tasks from specs, but treating the specification itself as a sovereign artifact that persists across models, agents, implementations, and time. That's a much more interesting conversation starter for John Lam than simply saying "I built something similar to Spec Kit." If I were writing to him, I'd probably say something like: > "I've been following Spec Kit and your work around specification-driven development. SovereignSpec grew out of my interest in a related problem: how specifications can remain the authoritative artifact across multiple AI agents and over the full lifecycle of a project, rather than being tied to a particular implementation cycle." That frames SovereignSpec as a complementary exploration rather than a competitor, which usually gets a better response from open-source maintainers.

now write an email from me but be humble on my part danielkliewer.com based on my recent posts

A humble approach will probably work best here. The goal is not to convince him that SovereignSpec is revolutionary; it's to start a conversation with someone who has been thinking deeply about similar problems. :::writing{variant="email" id="73184" subject="Thoughts on SovereignSpec and Spec-Driven Development"} Hi John, I hope you don't mind the unsolicited email. I've been following your work around Spec Kit and specification-driven development, and a lot of it resonated with ideas I've been exploring independently over the past several months. I'm a self-taught developer in Austin, and I've been writing extensively about local-first AI systems, AI-assisted software development, and the role specifications might play as the primary artifact in the development process. Those ideas eventually led me to build a small open-source project called SovereignSpec. The project grew out of a simple question: if AI agents are becoming increasingly capable of implementation, what should humans actually own? My conclusion was that we should own the specification itself—the intent, constraints, architecture, and validation criteria—while allowing implementation to be delegated to whichever agent is most capable at the time. After discovering Spec Kit, I realized many of the underlying principles overlap with what I had been thinking about. The difference, if there is one, is that I've been particularly interested in how specifications can remain durable across different models, coding agents, and even over long periods of time, rather than being tied to a single implementation cycle. I recently wrote a few posts about these ideas and published SovereignSpec as an experiment: https://www.danielkliewer.com https://github.com/kliewerdaniel/sovereignSpec I'm still refining both the ideas and the implementation, so I'm not reaching out with any expectation beyond curiosity. If you happen to have a few minutes to glance at it, I'd genuinely be interested in hearing where you think the approach aligns with or diverges from the principles behind Spec Kit. Either way, thank you for the work you've been doing. Spec Kit helped clarify several ideas I'd been struggling to articulate. Best regards, Daniel Kliewer Austin, Texas https://www.danielkliewer.com ::: I like this version because it acknowledges that Spec Kit came first, positions SovereignSpec as an experiment rather than a challenge, and invites discussion instead of validation. That tends to get better responses from experienced open-source maintainers.

try again, Hi John, I’ve been following your work around Spec Kit and specification-driven development, and a lot of it resonated with ideas I’ve been exploring independently over the past several months. I’m a self-taught developer in Austin, and I’ve been writing extensively about local-first AI systems, AI-assisted software development, and the role specifications might play as the primary artifact in the development process. Those ideas eventually led me to build a small open-source project called SovereignSpec. The project grew out of a simple question: if AI agents are becoming increasingly capable of implementation, what should humans actually own? My conclusion was that we should own the specification itself—the intent, constraints, architecture, and validation criteria—while allowing implementation to be delegated to whichever agent is most capable at the time. After discovering Spec Kit, I realized many of the underlying principles overlap with what I had been thinking about. The difference, if there is one, is that I’ve been particularly interested in how specifications can remain durable across different models, coding agents, and even over long periods of time, rather than being tied to a single implementation cycle. I recently wrote a few posts about these ideas and published SovereignSpec as an experiment: https://www.danielkliewer.com/blog/2026-06-12-sovereignspec-local-first-spec-driven-development https://github.com/kliewerdaniel/sovereignSpec I’m still refining both the ideas and the implementation, so I’m not reaching out with any expectation beyond curiosity. If you happen to have a few minutes to glance at it, I’d genuinely be interested in hearing where you think the approach aligns with or diverges from the principles behind Spec Kit. Either way, thank you for the work you’ve been doing. Spec Kit helped clarify several ideas I’d been struggling to articulate. Best regards, Daniel Kliewer Austin, Texas https://www.danielkliewer.com ------ put now we are going to take the following technical details into consideration and give a short version to read initially and the longer version for them to read if they are really interested in the project : # SovereignSpec — Deep Research Report **Date:** June 13, 2026 **Subject:** SovereignSpec by kliewerdaniel — A Local-First, Offline Spec-Driven Development Engine **Confidence Level:** High (90%+) — based on official repo, blog post, and multiple corroborating sources --- ## Executive Summary SovereignSpec is a local-first, fully offline Spec-Driven Development (SDD) engine built by Daniel Kliewer that addresses a critical gap in the SDD landscape: **no existing SDD tool runs entirely offline**. While GitHub's Spec Kit (28K+ stars) has catalyzed the SDD movement, every pipeline step — spec evaluation, clarification, planning, and implementation — routes through cloud AI APIs. SovereignSpec eliminates this dependency entirely, running all inference locally through Ollama with zero cloud API calls, while adding capabilities that Spec Kit lacks: ChromaDB-powered RAG, GBNF grammar-constrained deterministic output, a NetworkX knowledge graph with 11 node types and 9 edge types, and a 12-step compiler pipeline with 12 validation rules. It ships with a 16-command Python CLI, 11 agent adapters, SQLite persistence, and a Next.js dashboard — making it the first truly sovereign SDD implementation. --- ## Chronological Timeline ```mermaid gantt title SovereignSpec & SDD Landscape Timeline dateFormat YYYY-MM-DD section SDD Emergence Spec Kit released on GitHub :2025-09-01, 30d Spec Kit reaches 28K+ stars :2025-10-01, 180d section SovereignSpec Development specgen released :2025-12-01, 30d synth01 released :2025-12-01, 30d objective05 (Sovereign AI) roadmap :2026-03-01, 60d SovereignSpec project proposal published :2026-06-12, 1d SovereignSpec repo created :2026-06-12, 1d ``` ### Key Events - **September 2025**: GitHub releases Spec Kit, catalyzing the Spec-Driven Development movement [citation:Spec Kit GitHub](https://github.com/github/spec-kit) - **Early 2026**: Spec Kit reaches v0.5.0 with presets, extensions, and lifecycle hooks; gains 28K+ stars [citation:Spec Kit GitHub](https://github.com/github/spec-kit) - **Mid-2026**: SDD becomes the dominant paradigm — Martin Fowler publishes analysis, Microsoft publishes SDD guide, DeepLearning.AI launches SDD course [citation:Martin Fowler SDD Analysis](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html) [citation:Microsoft SDD Guide](https://developer.microsoft.com/blog/spec-driven-development-ai-native-engineering) [citation:DeepLearning.AI SDD Course](https://www.deeplearning.ai/courses/spec-driven-development-with-coding-agents) - **June 12, 2026**: Daniel Kliewer publishes project proposal and creates SovereignSpec repository, identifying the cloud-dependency gap in all existing SDD tools [citation:SovereignSpec Project Proposal](https://www.danielkliewer.com/blog/2026-06-12-sovereignspec-local-first-spec-driven-development) --- ## The Problem SovereignSpec Solves ### The SDD Revolution Spec-Driven Development (SDD) flips traditional software development: instead of code-first with specs as afterthought, **specs become executable** — the single source of truth from which implementation, testing, and documentation are derived. The core equation: ``` Complete Specs + AI Context = Reliable Code ``` [citation:Spec-Driven Development Wikipedia](https://en.wikipedia.org/wiki/Specification-driven_development) The context hierarchy ensures layers exist before asking for code: 1. **Global rules** (coding standards, patterns) 2. **Project context** (architecture, tech stack) 3. **Feature specs** (PRD, acceptance criteria) 4. **Implementation specs** (API, schema, components) 5. **Task context** (specific file, specific function) Without specs, AI tools invent. With specs, they implement. [citation:Microsoft SDD Guide](https://developer.microsoft.com/blog/spec-driven-development-ai-native-engineering) ### The Cloud Dependency Gap **Every existing SDD tool requires cloud AI agents.** Spec Kit — the dominant SDD toolkit with 28K+ stars — works with Claude Code, Copilot, Cursor, Gemini CLI, Windsurf, and TabNine CLI. But every step of its seven-command workflow (`/constitution → /specify → /clarify → /plan → /tasks → /analyze → /implement`) calls external LLM APIs. There is no offline mode. There is no local model integration. [citation:Spec Kit GitHub](https://github.com/github/spec-kit) For builders who believe that "a weak local model controlled by you is spiritually superior to a powerful cloud model," this is a fundamental design failure. SovereignSpec exists to fix this. --- ## Architecture Overview ```mermaid flowchart TD subgraph L7["Layer 7: Interface"] A[Next.js Dashboard + shadcn/ui] end subgraph L6["Layer 6: Agent Integration"] B[11 Agent Adapters + Context Manager] end subgraph L5["Layer 5: Specification Engine"] C[.sspec Compiler — 12-step Pipeline] D[12 Validation Rules] end subgraph L4["Layer 4: Knowledge Graph"] E[NetworkX — 11 Node Types, 9 Edge Types] F[Impact Analysis Queries] end subgraph L3["Layer 3: Repository Intelligence"] G[ChromaDB Vector Search — RAG] H[Repo Maps] end subgraph L2["Layer 2: Persistence"] I[SQLite — Raw SQL + Migration Runner] J[ChromaDB — Embedded + Caching] end subgraph L1["Layer 1: Local Infrastructure"] K[Ollama — Qwen, Llama 3.1, DeepSeek, Gemma, Mistral] L[File System — .sspec, .json, GBNF grammars] end A --> B --> C --> E --> G --> I --> K C --> D E --> F G --> H I --> J K --> L ``` ### Layer-by-Layer Breakdown #### Layer 1: Local Infrastructure (Ollama + Files) - **Ollama** runs all inference locally — Qwen, Llama 3.1, DeepSeek, Gemma, Mistral - **GBNF grammars** (8 grammar files) constrain token space for deterministic output — no hallucination, no format drift - **`.sspec` files** — YAML superset format parsed via Pydantic #### Layer 2: Persistence (SQLite + ChromaDB) - **SQLite** with raw SQL and migration runner for structured metadata - **ChromaDB** embedded vector store with caching for semantic search over specs, ADRs, and patterns #### Layer 3: Repository Intelligence (RAG + Maps) - **ChromaDB-powered semantic search** across all specifications, architectural decision records (ADRs), and design patterns - **Repository maps** provide structural context for spec-grounded reasoning #### Layer 4: Knowledge Graph (NetworkX) - **11 node types**: spec, feature, requirement, constraint, decision, pattern, component, service, module, task, artifact - **9 edge types**: depends_on, conflicts_with, implements, refines, supersedes, relates_to, grounds, validates, evolves - **Impact analysis queries**: change one spec, see ripple effects across the entire system #### Layer 5: Specification Engine (.sspec Compiler) - **12-step compiler pipeline**: parse → validate → ground → resolve → compile → verify → emit - **12 validation rules**: contradiction detection, drift detection, completeness checks, dependency resolution, semantic diffing, version tracking #### Layer 6: Agent Integration (11 Adapters) - Adapters for Claude Code, Copilot, Cursor, Gemini CLI, Windsurf, TabNine, Kimi Code, and 4 more - Context manager feeds spec-grounded context to agents — agents read specs and implement deterministically #### Layer 7: Interface (Next.js + shadcn/ui) - Full dashboard for spec management, graph visualization, and implementation tracking --- ## Technical Deep Dive ### The .sspec Format SovereignSpec introduces the `.sspec` format — a YAML superset parsed via Pydantic. Unlike Spec Kit's flat markdown, `.sspec` files are structured, typed, and machine-validatable: ```yaml --- spec: id: "auth-module-v2" version: "2.1.0" status: "active" grounds: - "security-constraint-001" - "pattern-oauth2-implementation" requirements: - type: "functional" priority: "P0" description: "Implement OAuth2 PKCE flow" acceptance: - "User authenticates via Google OAuth2" - "Refresh tokens rotate on each use" constraints: - type: "security" description: "No credentials in logs" ``` ### GBNF Grammar-Constrained Generation SovereignSpec uses GBNF (Grammar BNF) — the same grammar notation supported by llama.cpp — to force the model to emit only syntactically valid output. This is a critical innovation: - **Spec Kit generates code from specs but doesn't enforce deterministic output formats** - **SovereignSpec constrains token space**: the model can only generate tokens that match the grammar - **Result**: 100% compliance with output schemas, regardless of model size — even tiny models like phi-3-mini produce valid output - **Trade-off**: grammars must be defined upfront; generation performance degrades slightly as token masking is not yet parallelized on GPU [citation:GBNF Constrained Generation](https://www.jamesdrandall.com/posts/gbnf-constrained-generation/) [citation:Ollama Structured Outputs](https://blog.danielclayton.co.uk/posts/ollama-structured-outputs/) ### Knowledge Graph Impact Analysis When a spec changes, SovereignSpec queries the NetworkX graph to determine ripple effects: ``` auth-module-v2 --depends_on--> security-constraint-001 security-constraint-001 --grounds--> logging-module-v1 logging-module-v1 --conflicts_with--> debug-mode-proposal ``` Changing `auth-module-v2` triggers alerts for `logging-module-v1` and `debug-mode-proposal`. This is **impossible in Spec Kit**, which has no relationship modeling. ### 12-Step Compiler Pipeline The `.sspec` compiler runs specs through a 12-step pipeline: 1. **Parse**: Load `.sspec` YAML via Pydantic 2. **Validate**: Run 12 validation rules (contradiction, drift, completeness, dependency) 3. **Ground**: Resolve references in knowledge graph (NetworkX) 4. **Resolve**: Semantic search for relevant context (ChromaDB) 5. **Compile**: Generate implementation plan via Ollama with GBNF constraints 6. **Verify**: Cross-check generated plan against spec requirements 7. **Emit**: Output deterministic code or structured task list --- ## Comparison: SovereignSpec vs Spec Kit vs Alternatives | Feature | Spec Kit | SovereignSpec | OpenSpec | Kiro | |---------|----------|---------------|----------|------| | **Cloud dependency** | Required (all steps) | **None — fully offline** | Required | Required | | **Local LLM support** | ❌ | ✅ (Ollama) | ❌ | ❌ | | **RAG integration** | ❌ | ✅ (ChromaDB) | ❌ | ❌ | | **Grammar enforcement** | ❌ | ✅ (GBNF) | ❌ | ❌ | | **Spec evolution tracking** | Basic | ✅ (full diffing + drift) | Basic | Basic | | **Knowledge graph** | ❌ | ✅ (NetworkX) | ❌ | ❌ | | **Agent adapters** | 7 agents | **11 agents** | 3 agents | 1 agent | | **CLI commands** | 7 slash commands | **16 Python commands** | 5 commands | 4 commands | | **Dashboard** | ❌ | ✅ (Next.js) | ❌ | ✅ | | **Spec format** | Markdown | **.sspec (typed YAML)** | Markdown | Markdown | [citation:Spec Kit GitHub](https://github.com/github/spec-kit) [citation:OpenSpec](https://openspec.pro/) --- ## The Ecosystem: SovereignSpec in Context SovereignSpec doesn't exist in isolation. It's part of a broader local-first infrastructure stack: ```mermaid flowchart LR subgraph SovereignStack["Sovereign Stack"] direction TB A[specgen] -->|feeds| B[sovereignSpec] C[synth01] -->|feeds| B D[objective05] -->|feeds| B B -->|outputs| E[GraphRAG Research Assistant] B -->|outputs| F[Dynamic Persona MoE RAG] end A -.->|local-first| C C -.->|local-first| D ``` - **specgen**: Deterministic code generation engine from structured technical specifications - **synth01**: Privacy-focused news synthesizer - **objective05**: Sovereign AI roadmap - **GraphRAG Research Assistant**: Graph-based retrieval-augmented generation for research - **Dynamic Persona MoE RAG**: Mutable persona state vectors with reinforcement-driven evolution [citation:SovereignSpec Project Proposal](https://www.danielkliewer.com/blog/2026-06-12-sovereignspec-local-first-spec-driven-development) [citation:SOVEREIGN Architecture](https://www.danielkliewer.com/blog/2026-03-29-sovereign-synthesis) --- ## Strengths & Weaknesses ### Strengths 1. **Truly offline**: Zero cloud dependency — the only SDD tool that runs entirely locally 2. **Deterministic output**: GBNF grammars guarantee syntactically valid output, eliminating hallucination 3. **Knowledge-grounded**: Specs are not flat text — they reference a living knowledge graph with impact analysis 4. **Richer than Spec Kit**: 16 commands vs 7, 11 agent adapters vs 7, full dashboard 5. **Spec evolution tracking**: Full version history with semantic diffs and contradiction detection 6. **RAG integration**: ChromaDB-powered semantic search across specs, ADRs, and patterns 7. **Typed spec format**: `.sspec` is machine-validatable — not just markdown 8. **Part of a larger ecosystem**: Integrates with specgen, synth01, and the sovereign AI stack ### Weaknesses 1. **Early stage**: Repository was just created (June 12, 2026) — minimal stars, no community traction yet 2. **Ollama performance trade-off**: GBNF-constrained generation degrades inference speed; token masking is not parallelized on GPU 3. **Grammar definition burden**: GBNF grammars must be defined upfront — requires upfront work 4. **No existing user base**: Spec Kit has 28K+ stars and an established community; SovereignSpec starts from zero 5. **Model dependency**: Quality depends on local model capability — a weak local model may produce weak implementations even with grammar constraints 6. **Documentation gap**: The project proposal is thorough, but the repo itself needs more inline documentation and examples --- ## Market Positioning ### The SDD Landscape (2026) SDD has become the dominant paradigm for AI-assisted software development in 2026. The landscape: - **Spec Kit** (GitHub): The dominant tool — 28K+ stars, but cloud-dependent - **OpenSpec**: Open-source alternative, also cloud-dependent - **Kiro**: Enterprise-focused, cloud-dependent - **SovereignSpec**: The **only** fully offline option — fills a gap that didn't exist until now [citation:Spec-Driven Development 2026 Guide](https://thebcms.com/blog/spec-driven-development) [citation:Medium — 30+ Agentic Coding Frameworks](https://medium.com/@visrow/spec-driven-development-is-eating-software-engineering-a-map-of-30-agentic-coding-frameworks-6ac0b5e2b484) ### Target Audience 1. **Local-first purists**: Developers who refuse to send code specs to cloud APIs 2. **Government/defense**: Organizations with air-gapped infrastructure requirements 3. **Enterprise security**: Companies that cannot allow spec data to leave their network 4. **Privacy-focused builders**: Anyone who believes "a weak local model controlled by you is spiritually superior to a powerful cloud model" 5. **Sovereign AI ecosystem**: Users of specgen, synth01, and the broader sovereign stack --- ## Sources ### Primary Sources - [SovereignSpec GitHub Repository](https://github.com/kliewerdaniel/sovereignSpec) — Official source code - [SovereignSpec Project Proposal](https://www.danielkliewer.com/blog/2026-06-12-sovereignspec-local-first-spec-driven-development) — Detailed architecture and rationale - [SOVEREIGN: The Unified Architecture](https://www.danielkliew

I would not put the deep research report into the first email. John Lam is busy, and a wall of technical detail will likely reduce the chance that he reads it. Instead, make the email easy to scan in under 30 seconds, then include a short "If you're interested, here's the deeper technical thesis" section beneath it. :::writing{variant="email" id="46281" subject="SovereignSpec: A Local-First Approach to Spec-Driven Development"} Hi John, I hope you don't mind the unsolicited email. I've been following your work around Spec Kit and specification-driven development. Over the past several months I've been exploring many of the same ideas independently while writing about local-first AI systems and AI-assisted software development. That exploration led me to build SovereignSpec: https://github.com/kliewerdaniel/sovereignSpec and write about the motivation behind it: https://www.danielkliewer.com/blog/2026-06-12-sovereignspec-local-first-spec-driven-development The core question I keep coming back to is: if AI agents become increasingly capable of implementation, what should humans actually own? My answer has been that specifications should become the durable source of truth—capturing intent, constraints, architecture, and validation criteria—while implementation can be delegated to whichever coding agent is most capable at a given moment. After discovering Spec Kit, I realized there was substantial overlap in philosophy. The area I've been exploring further is how specifications can remain durable across different models, coding agents, and time horizons, rather than being tied to a particular implementation cycle or vendor ecosystem. A short summary of SovereignSpec is: • Fully local-first and offline through Ollama • Typed specifications rather than markdown-only artifacts • Knowledge graph + RAG for specification grounding • Grammar-constrained generation for deterministic outputs • Agent-agnostic workflows designed to survive model churn I'm still refining both the implementation and the ideas, so I'm reaching out primarily to learn. If you happen to have a few minutes to glance at it, I'd be interested in hearing where you think the approach aligns with—or diverges from—the principles behind Spec Kit. Either way, thank you for the work you've done with Spec Kit. It helped crystallize several ideas I'd been struggling to articulate. Best regards, Daniel Kliewer Austin, Texas https://www.danielkliewer.com --- Additional context if you're interested: My working thesis is that current Spec-Driven Development tooling has solved specification-driven workflows, but not specification sovereignty. Most systems today assume access to a specific cloud model or provider. SovereignSpec explores what happens if specifications become the primary artifact and AI models become interchangeable implementation engines. Technically, the project combines: • Local inference through Ollama • ChromaDB-based retrieval over specifications and architectural decisions • A NetworkX knowledge graph for impact analysis and dependency tracking • A typed .sspec specification format • Grammar-constrained generation for deterministic outputs • Agent adapters that allow the same specification to be used across multiple coding agents The project is very early, but the goal is to investigate whether specifications can function as durable assets that outlive individual models, coding agents, and vendors. ::: This version leads with the idea rather than the implementation details. The technical section becomes optional reading instead of a hurdle. That is usually the right balance when emailing a maintainer or architect.