> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plannotator.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Technical Specification Template

> Copy a technical specification template for requirements, non-goals, architecture, interfaces, data, failure behavior, rollout, and verification.

Use a technical specification when behavior and design must remain understandable beyond one implementation pass. It should tell implementers what must be true and give reviewers enough detail to challenge the design.

```md theme={null}
# [System or feature] technical specification

Status: Draft | Accepted | Implemented | Superseded
Owners: [People or team]
Last reviewed: [Date]

## Summary
[The useful answer in two or three sentences.]

## Problem and users
[Who needs what, and what evidence establishes the problem.]

## Requirements
- R1. [Observable required behavior]
- R2. [Observable required behavior]

## Non-goals
- [Behavior or system deliberately excluded]

## Design
[Components, responsibilities, data flow, and important boundaries.]

## Interfaces and data
[Routes, events, schemas, files, commands, or protocols.]

## Failure and recovery
[Expected failures, error behavior, retries, rollback, and operator recovery.]

## Security and privacy
[Trust boundaries, credentials, sensitive data, abuse limits.]

## Compatibility and rollout
[Migration, sequencing, feature flags, fallback, removal plan.]

## Verification
[Tests and real-world proof tied to each requirement.]

## Open questions
- [Decision that still blocks acceptance]

## Related decisions
- [ADR, RFC, plan, issue, or source link]
```

## Example requirement and proof

```md theme={null}
## Requirements
- R1. An expired share link returns the same public response as an unknown link.

## Verification
- V1. Create one valid and one expired link against the real route harness.
- V2. Assert that both hidden cases return the documented status and body.
- V3. Assert that the expired request does not read document content.
```

The requirement is observable. The proof checks both response behavior and the sensitive internal boundary.

Inspect the [generated BMad express technical specification for reliable webhook delivery](https://github.com/plannotator/spec-planning-frameworks/blob/main/examples/bmad-method/raw/_bmad-output/specs/spec-reliable-webhook-delivery/SPEC.md) for a compact same-case output.

## Review prompts

* Can each requirement be tested without interpreting the author's intent?
* Does the design assign one owner for every durable state transition?
* Are failure, privacy, migration, and rollback behavior first-class sections?
* Which details belong in an ADR rather than the maintained specification?

See [ADR vs RFC vs technical specification](/compare/adr-vs-rfc-vs-technical-specification) before choosing a format. GitHub Spec Kit also separates specification, plan, and tasks; see its [official documentation](https://github.github.com/spec-kit/) and our [evidence profile](/frameworks/github-spec-kit).

*Reviewed July 19, 2026. Written and maintained by the Plannotator documentation team.*