- Removed inaccurate multi-agent system description and architecture SVG
- Replaced with honest framing: Speckl is an open standard (methodology + language spec)
- Removed Discord CTA button per Scott's request
- Removed stale favicon.svg from landing dir
- General polish: hero layout, mobile breakpoints
- CLI entry point with yargs parsing for speckl-compile <file> --output-dir --bom-format
- TypeScript parser with AST types for all SpeckDL primitives
- Generator for PROV-O JSON-LD provenance graphs
- Generator for CycloneDX v1.6 BOMs
- Generator for SPDX 3.0.1 BOMs
- E2E test verifying RetryHandler.speck parsing and all output formats
All tests pass.
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
Static dark-mode site with hero, features, SpeckDL code example,
philosophy section, and roadmap. Deployed via NixOS module to
speckl.scoble.me with Cloudflare ACME DNS challenge.
SpeckBOM compilation manifest now supports two output formats:
- CycloneDX v1.6 JSON (OWASP/ECMA-424) — preferred for security tooling
- SPDX 3.0.1 JSON-LD (ISO 5962:2023) — preferred for regulated environments
Key changes:
- §4.5: Restructured as 'Compilation Manifest (SpeckBOM Output)' with dual format
support, comparison table (CycloneDX vs SPDX capabilities), both JSON examples,
and separate field mapping tables for each format
- Added compiler output section: --bom-format cdx|spdx|both (default: both)
- Appendix B restructured into 4 sections:
B.1 Provenance Graph (JSON-LD / PROV-O) — intent layer
B.2 SpeckBOM — CycloneDX v1.6 mapping table
B.3 SpeckBOM — SPDX 3.0.1 mapping table
B.4 Three-layer architecture: intent (PROV-O) + composition (CycloneDX or SPDX)
Rationale: Different regulators mandate different formats. DO-178C shops
need SPDX (ISO normative), security teams need CycloneDX (OWASP ecosystem).
Supporting both makes SpeckBOM universally adoptable.
Replace custom JSON-LD compilation manifest with valid CycloneDX v1.6
documents using bomType: specBOM and speckl: property namespace.
Key changes:
- §4.5: Compilation manifest now outputs CycloneDX v1.6 JSON
- Added 'Why CycloneDX' section comparing CycloneDX vs SPDX for this use case
- Full CycloneDX JSON example for DrugDosageCalculator
- Added CycloneDX field mapping table (SpeckDL primitive → CycloneDX location)
- Added path to standardization (community proposal → OWASP recognition)
- Appendix B restructured into three sections:
B.1 Provenance Graph (JSON-LD / PROV-O) — intent layer
B.2 SpeckBOM (CycloneDX v1.6) — composition layer
B.3 Two-Layer Architecture — how they complement each other
This extends an existing OWASP/ECMA-424 standard rather than defining
a bespoke format, ensuring compatibility with Dependency-Track and
the full CycloneDX tooling ecosystem.
New language features:
- bom {} block: declares toolchain dependencies (compiler, solver, runtime),
license, and content hash — the spec analog of an SBOM
- Import version pinning: hash and version on import statements for
reproducible builds and dependency integrity
- §3.6.6: SpeckBOM semantics — maps each bom clause to JSON-LD/SPDX
- §3.6.7: Import pinning semantics — hash verification at compile time
- §4.5: Compilation manifest — auto-generated audit-ready JSON-LD output
with spec hash, dependency integrity, toolchain versions, artifact hashes,
verification results, and reproducibility flag
- Updated EBNF grammar for bom_def and import hash/version
- Updated examples (InfusionPumpController shows bom block, PaymentService
shows import pinning)
- Updated Appendix B with SpeckBOM JSON-LD mappings
Together with existing DP primitives (provenance, review, derives, satisfies,
author, source), SpeckBOM provides the full picture: intent provenance +
composition manifest + verification evidence = audit-ready specification.
New language members: provenance, review, derives, satisfies, author, source
- provenance block: declare intent sources (regulation, design_decision, parent_spec, external_doc)
- review directive: mark verification boundaries (manual, auto, hybrid)
- derives/satisfies: spec-to-spec and spec-to-requirement edges
- author/source: who wrote it and what drove it
- Provenance-aware event semantics: runtime events trace back to intent
- Updated EBNF grammar, semantics, examples, and JSON-LD mapping
- Three new examples: regulated medical device, auto-verified service, compliance audit trail
- All primitives optional — Specks without provenance still compile fine
- 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
