PBS Specs
This directory contains the normative PBS specification set.
Purpose
Specs define the official PBS contract.
They exist to make behavior, constraints, and interfaces stable across implementations and reviews.
Expected Format
The exact structure may vary by document, but a spec should usually contain:
- Title
- Status
- Scope or Applies To
- Purpose
- Authority and Precedence
- Normative Inputs
- Core Rules
- Non-Goals
- Exit Criteria
Some specs may also include:
- already-settled inputs,
- initial section targets,
TODOsections for tracked unresolved items,- cross-references to adjacent specs.
Writing Rules
- Write in normative language.
- Integrate only decisions that have already been closed.
- Keep debate history and exploratory alternatives out of the spec body.
- Preserve clear boundaries between adjacent specs.
- Use
TODOonly for explicitly tracked unresolved items, not as a substitute for agenda work.
Upstream Rule
Specs should normally be fed by:
- agendas that frame the open topic,
- decisions that close the architectural question,
- then spec integration.
If a spec edit would require guessing an unresolved design choice, the correct action is to stop and surface the missing decision first.