Skip to content

A Tour of the Document Library — 214 Specs, Zero Excuses

SpecBase ships with 214 specification document types, organized across 11 software archetypes. The Document Library makes all of them browsable, searchable, and individually explainable — whether you’re a developer planning a project or an AI agent orienting itself to a codebase.

This post is a guided tour.

What the Library Is

The library is not a collection of actual specification documents — it’s a catalog of document types. Think of it as the table of contents for everything a well-documented software project might need, explained in enough depth that you understand why each document exists and what separates a good version from a weak one.

Each entry in the library is a standalone page. It tells you:

  • What the document is — the purpose, in plain language
  • What makes a good version — concrete criteria with examples of strong vs. weak content
  • Common mistakes — the anti-patterns teams fall into most often
  • How to use it — when to create it, who owns it, and how AI agents should interact with it
  • Which archetypes it appears in — whether it’s a base requirement or tied to a specific feature

The library browser at /docs/library/ lets you filter by:

  • Priority — Required (P0), Recommended (P1), Optional (P2)
  • Project type — any of the 11 archetypes (click a chip to filter)
  • Feature — once you select a single archetype, filter to documents added by a specific feature
  • Category — engineering, security, legal, product, design, operations, data, ml, governance
  • Search — full-text across titles and rationales

Start by clicking “Backend Service” in the archetype chips. You’ll see the 6 base documents every backend needs, plus the documents added by features like GDPR, public API, or async jobs.

Three Documents Worth Knowing

Architecture Overview

The Architecture Overview is a Required (P0) document for almost every archetype. It maps external service dependencies, data flow directions, and failure domains. It exists because this information — which systems talk to which, how data moves, what happens when something fails — never stays in anyone’s head long enough to be useful.

A strong Architecture Overview is specific enough that a new team member understands the full integration topology on their first day. A weak one is generic enough that it could describe any system (“the frontend calls the backend, which talks to the database”).

What makes this document particularly interesting in the library: it appears in 9 of 11 archetypes. The shape of what “architecture” means differs between a video game, an embedded system, and a web app — but the need to document it doesn’t.

Data Subject Request Flow

This is a Recommended (P1) document that appears whenever a project selects the gdpr feature on backend_service or web_app. It specifies exactly how your system handles the four GDPR data subject rights: access, erasure (“right to be forgotten”), portability, and rectification.

This document is a good example of why features matter. A backend service without GDPR scope doesn’t need this. But the moment you process personal data of EU residents — and especially the moment a user submits an erasure request — you need a documented process. Without it, you’ll discover the gaps at the worst possible time.

A strong version of this document specifies: the request intake channel (form, email, API endpoint), identity verification steps, what data stores are checked, the deletion or anonymization procedure for each store, the response timeline (GDPR requires 30 days), and exception handling.

Power Budget

This one lives at the intersection of two archetypes: embedded (as a base document) and iot (added by the battery feature). It’s one of the few documents in the library that appears in multiple archetypes with different contexts — on the power_budget detail page, you’ll see both entries under “Appears In.”

A power budget documents the power draw of each component, expected battery life under various load profiles, and thermal management strategy. It’s Required for embedded projects because power constraints affect hardware selection, firmware design, and user expectations. An IoT device that burns through its battery in 12 hours instead of 6 months is a product failure, not just a bug.

The Priority System

Documents are tagged P0, P1, or P2:

  • Required (P0): Skipping this document means you’re taking on real, known risk. If something goes wrong in this area and you don’t have the doc, the answer to “why not?” will be uncomfortable.
  • Recommended (P1): Important for most projects of this type. The risk of skipping it scales with project complexity and longevity.
  • Optional (P2): Valuable for specific circumstances — often features or regulatory requirements that only some projects face.

The library browser defaults to sorting by priority, so P0 documents always appear first. This is deliberate: if you’re starting a new project, focus there before moving to P1.

Machine-Readable for AI Agents

Every document in the library has a prompt_snippet — a concise, action-oriented instruction an AI agent can use when reviewing a project. For example, the Architecture Overview’s snippet is:

“Verify the project has an architecture overview mapping all external service dependencies, data flows, and failure domains.”

When SpecBase’s MCP tool get_standard_docs returns a list of required documents, each document includes its prompt snippet. Claude Code or any MCP-compatible agent can use this directly as a verification checklist — it knows exactly what to look for in the project and what “good” looks like.

Contribute to the Library

The knowledge base is CC-BY-4.0. If you know of a document type that should be part of a specific archetype, or you have detailed knowledge about what makes a particular spec good vs. bad, contributions are welcome.

The P1 document pages (Recommended, 115 total) currently show stub content — the structure is there, but the editorial depth is still being filled in. If you have expertise in a domain (security, ML systems, mobile, embedded), picking a few P1 documents in your area and writing up the good/bad criteria is one of the highest-value contributions you can make.

See CONTRIBUTING.md to get started. The format for each section is documented in detail, so you don’t need to guess what we’re looking for.

Browse the library: specbase.net/docs/library/