Open-Spek

An open standard for sharing the complete knowledge required to create software.

--- a/source
+++ b/source
@@ the definition of source @@
- Source is code.
+ Source is knowledge.

Abstract

Open-Spek names the durable artifact of software creation: the Spek — the complete knowledge required to create a piece of software. As AI becomes the primary producer of implementations, the artifact worth sharing, reviewing, and forking is no longer the code; it is the knowledge the code was generated from. Open Source made implementations open. Open-Spek makes knowledge open.

1.The claim

Software is no longer written first. It is described first. A Spek captures a project's vision, its locked design decisions with their rationale, its constraints, its acceptance criteria, and the exact instructions an implementer runs under — enough that a competent implementer, human or machine, can produce a correct, verifiable implementation with no other context.

The test of completeness is the regeneration question: if every implementation were deleted, could the software be recreated from the Spek alone?

2.The pipeline

        Knowledge
            |
          Spek        the source artifact ...........  spek
            |
           AI         the reference method ..........  loop
            |
          Code        one implementation ............ jsonq
            |
        Software

loop is a reference method, not the standard itself — it predates Open-Spek and runs without a complete Spek; a ratified Spek, in turn, does not require it. See §7.

3.The Spek

A Spek is a set of plain-text documents. Three sections are required — a vision (what this is and what it refuses to be), a design record (locked decisions with rationale, including the deliberately rejected alternatives), and mechanical acceptance criteria with the gate that verifies them. Constraints, prompts, decision logs, and executed examples are recommended. The normative format lives in SPEK-FORMAT.md.

4.Proof, not promise

The standard ships with a demonstration. jsonq — a fully type-safe JSON query engine in pure TypeScript — was created by ratifying its Spek first and letting an autonomous, test-gated agent loop generate the implementation.

5.Artifacts

6.Principles

• Knowledge is the source.
• Spek is the source artifact.
• Software is described before it is implemented.
• A single Spek can produce many implementations.
• Implementations evolve. Speks endure.
• Knowledge should remain open.

7.Positioning

Open-Spek shares vocabulary with Spec-Driven Development (SDD — Kiro, GitHub Spec Kit, Cursor Plan Mode) — both produce spec-like documents, both precede implementation. The overlap is real but narrow: SDD's spec is truth during development, kept live and co-evolving with the code (Kiro's own account is explicit about this). A Spek is truth for sharing: a durable artifact meant to outlive any one implementation, measured by the regeneration question rather than by how well it steers a live session. Neither claim displaces the other — they are adjacent layers, the way successive fields of study build on shared terms without contradicting each other.

loop is a third, separable layer: the reference method that turns a frozen Spek into verified code without a human editing the output. It was distilled from the LibreDB build before Open-Spek existed, and it runs without a complete Spek; a ratified Spek does not require it either. The two compose — jsonq is the proof — but neither is a precondition of the other.

• Is Open-Spek an SDD tool? No — an open artifact standard, not a development workflow.
• What is Loop Engineering? An autonomous, test-gated build method; the standard's reference method, not the standard itself.
• How does it differ from Kiro? Kiro is a development workflow; Open-Spek is the format of the knowledge worth sharing once that workflow is done — different layers, similar file names.

Full comparison, borrowed structure vs. differing purpose, and more FAQ: spek/POSITIONING.md.