The four design docs from the GP architecture research thread. These define Speckl's
general-purpose architecture: conversation → SIR → deterministic compile, with domain
plugins for state machines, data schemas, and workflows.
- sir-schema.md (48KB): Central IR data structure with ~20 interfaces, 8 domain element tables
- extraction-protocol.md (47KB): How conversation populates the SIR
- validation-engine.md (39KB): SIR validation before compilation
- compilation-layer.md (43KB): How validated SIRs compile to deterministic artifacts
Phase strategy: build GP core now, ship state machines first, layer data schemas
and workflows on the same architecture (no rewrites).
blog-01: Spec-Code Drift Is a Provenance Problem (~1,500 words)
blog-02: Designing SpeckDL (~1,800 words)
blog-03: How Speckl's Compiler Works (~1,900 words)
blog-04: Embedded Provenance (~1,200 words)
blog-05: Consensus Protocols in SpeckDL (~1,300 words)
publishing-toolkit: Dev.to/Medium/Reddit/HN formatting + objection prep (~3,500 words)
Total Phase 2 pipeline: ~11,200 words across 6 files.
Previously existed only in workspace copy (posts 1/3/toolkit) or
as untracked files (posts 2/4/5). All now committed to Forgejo.
Comprehensive comparison of SpeckDL against:
- TLA+/PlusCal (model checking vs. runtime compilation)
- Alloy (structural vs. behavioral modeling)
- Coq/Rocq (static proofs vs. dynamic enforcement)
- Dafny (verified code vs. spec-as-code)
- Event-B, UML/SysML, P (Microsoft), OpenAPI/gRPC
- SBOM tools: Syft/Grype, SLSA, in-toto
Includes positioning table across 7 tools on 6 dimensions.
Defines niche: specification language with compiler-level provenance,
designed for teams that need evidence of correctness more than proof.
Covers: regulatory landscape (EO 14028, CRA, DORA, FedRAMP), NIST SA-11 control
mapping (sub-controls 2/4/6/7), the evidence problem, compliance automation workflow,
judgement transport model, 4 real-world use cases (FDA, CISA, DORA, SLSA), clear
boundaries on what Speckl does not do, and cost equation with before/after comparison.
Completes the bridge between provenance (S4) and practical regulatory value.
Rewrites the whitepaper from the old 'Dark Provenance' concept to reflect
what Speckl actually is now: specifications that compile to software.
Section 1 covers:
- The Archaeology Problem (specs that rot in docs)
- The Formal Methods Gap (verified spec ≠ running system)
- The SpeckDL Approach (compile spec directly to code + provenance)
- Concrete ToggleSwitch example (14 lines → 5 artifacts)
Whitepaper outline restructured around current compiler capabilities
(TypeScript, WASM, PROV-O, CycloneDX, SPDX generators).
Old: D (Open Standard) → C (Consulting) → A (SaaS) → B (Compliance)
New: A (Open Standard) → B (Consulting) → C (SaaS) → D (Compliance)
Updated: README.md, strategy.md, plan-flow.svg, landing page
- docs/blog/2026-04-28-why-dark-provenance.md: First blog post explaining the vision
- docs/content-calendar.md: 2-week content plan with themes and targets
- docs/warp-monitoring.md: Process for monitoring Warp and engaging thoughtfully
Part of the build-in-public campaign for Speckl (Dark Provenance for AI agents).
- Dark Provenance whitepaper: complete sections 2-6 (What Is Dark Provenance,
The Speckl Approach, Semantic Preservation & SA-11, Implications, Call to Action)
- README: public launch-ready with architecture, roadmap, getting started
- SpeckDL SPEC.md: v0.1 language specification with EBNF grammar,
type system, compilation pipeline, 5 example Specks
- Reference agent: TypeScript scaffold with Orchestrator, TeamLead, SMEs
(VerificationSME, CodegenSME), TillDone condition tracking,
ProvenanceGraph, and CLI with example Specks
- MIT license
- README with project overview, Dark Provenance intro, and structure
- Empty directories: speckdl/, reference-agent/, examples/
- Placeholder whitepaper with Dark Provenance outline
Parent: Greybeard Holdings, LLC
Status: Early / Pre-Alpha
