A **Living Specification** is a collaboratively authored document that evolves over time to describe how a system is intended to work—**not only at launch, but as it changes and grows**.
It serves two complementary purposes:
1. As a Functional Specification 2. As a Living Document
# Functional Specification The Functional Specification outlines the structure, behavior, and responsibilities of different components in a system. Like Joel Spolsky’s definition, it answers questions such as: - What does the software do? - How should different parts interact? - What happens under specific conditions?
# As a Living Document A traditional specification often claims to be "alive" in that it is the responsibility of the (product) owner of that document to keep it current. However in practice this is often not the case, with the document becoming frozen at a point in time.
A Living Specification on the other hand alwys remains editable, with tooling and processes that ensure it "liveness" is paramount. It grows in detail and clarity as the project unfolds. This reflects implementation realities, community feedback, and new requirements.
A Living Specification embodies, both artifical intelligence, and the practice and tooling of wiki as a federated social writing practice. More than this it a Living Specification fully embraces rich media (in particular audio and to some extent video) that when combined with generative ai can enable more dynamic and expressive human input.
It is this combination of the ease of expression and documentation, together with the social aspect and the power of ai to support the creation and organissation of this documentation process that make it possible for a specification to be alive and remain living.
# Why Use a Living Specification? - **Evolvable**: It’s built to accommodate change, not resist it. - **Collective memory**: It records both design intent and reasoning, reducing the loss of context over time. - **Federated**: In environments like Federated Wiki, it can be maintained across many nodes by different contributors—inviting iteration, commentary, and refinement. - **Bridges thinking and doing**: It connects high-level vision with actual implementation detail—without requiring all the answers up front.
# In Practice In this project, the Living Specification brings together: - **Modular thinking** from software engineering - **Community authorship** from the wiki model - **Iterative documentation** from open science
It does not require formal sign-off to be useful. Instead, it earns its value by being **continuously useful**, **open to revision**, and **reflective of current understanding**—while still providing enough structure to inform design and implementation decisions.