Starter Templates

Blank project records you can copy, rename, combine or move into the tools you already use.

Choose only the records your project needs. Each template explains which ADEL responsibility it supports, when a separate record is useful and when an existing source is enough.

Choose by need

Choose the record you need.

You can begin with the guided starting prompt or with these blank templates. The prompt helps you develop each record through questions and review. The templates let you create a record yourself or place the same information in tools such as Jira or Confluence. Choose the route that fits your work; you do not need to use both.

Used across many changes

Project foundation

Start here when the project does not already have clear Governance principles, product intent and requirements, an approved design or agent instructions.

4 templates

Created when the work requires them

Records created when needed

Use these when an important design decision, delivery plan, work item or verification result must remain available after the current conversation or tool session.

4 templates

Only when direct links are not enough

Shared traceability view

Use the central table when people cannot follow the complete path through direct links, or when a legal, contract, audit or safety rule requires one maintained view.

1 template

Used across many changes

Project foundation

Start here when the project does not already have clear Governance principles, product intent and requirements, an approved design or agent instructions.

docs/governance/project-principles.md

# Project principles

Status: Draft | Active | Replaced
Maintained by:
Approver:
Effective from:
Last reviewed:

## Purpose and scope
What these principles govern and where they apply.

## Core principles

### <Principle name>
Rule:
The rule people and agents must follow. Use MUST / MUST NOT / SHOULD where useful.

Rationale:
Why this principle matters.

Applies to:
The decisions or work this principle constrains.

## Project-wide boundaries
- <decision authority, quality, security, data or another project-wide boundary>
- <what requires approval or requires the person or agent to stop and ask>

## Decision and exception authority
- Who may approve a change to these principles
- How exceptions are handled
- How conflicts with lower-level decisions are resolved

## Change history
- <date, change, approver and link to the replaced version when relevant>

ADEL responsibility

Governance

Possible format

Project principles, engineering principles, governance policy, charter or constitution

Use it when

The project needs one maintained place for rules that apply to every change and identify who may approve exceptions.

Use an existing source instead when

An existing policy, charter or constitution already holds these rules and remains accessible.

You can change the filename, headings and fields.

View the completed Project principles

Created when the work requires them

Records created when needed

Use these when an important design decision, delivery plan, work item or verification result must remain available after the current conversation or tool session.

docs/architecture/adr/0001-<decision>.md

# ADR-00X: <Decision title>

Status: Proposed | Accepted | Replaced | Rejected
Date: YYYY-MM-DD
Prepared by:
Approver:

## Decision background
What decision is required, why is it needed now, and what is affected?

## Question to resolve
State the decision as a concrete question.

## What affects the choice
The requirements, rules, risks, costs and operating needs that affect the choice.

## Decision
What was decided?

## Alternatives considered
| Option | Benefits | Costs / risks | Reason accepted or rejected |
|--------|----------|---------------|-----------------------------|
| ... | ... | ... | ... |

## Consequences
Positive, negative, operational and longer-term consequences.

## Conditions and follow-up
Prerequisites, verification needs, migration work or conditions that could
require this decision to be revisited.

## Related requirements and approved design

## Replaces / replaced by

ADEL responsibility

System Design

Possible format

Architecture decision record (ADR) or decision-log entry

Use it when

An important design decision and its rationale need to remain understandable after the immediate work ends.

Use an existing source instead when

The choice is routine and reversible, or the approved design already preserves all the reasoning future work will need.

You can change the filename, headings and fields.

View the completed decision record

Only when direct links are not enough

Shared traceability view

Use the central table when people cannot follow the complete path through direct links, or when a legal, contract, audit or safety rule requires one maintained view.

docs/assurance/traceability.md

# Traceability table

Maintained by:
Scope:
Last updated:

This table lists the records that connect a need or requirement to its design,
decisions, work, implementation and verification. Use direct links instead
when people and agents can already follow the complete path easily.

| Requirement / need | Design       | Decision | Work     | Implementation | Verification |
|--------------------|--------------|----------|----------|----------------|--------------|
| FR-012             | Blueprint §7 | ADR-008  | TASK-021 | Pull request #37 | VER-021      |
| FR-013             | Blueprint §8 | -        | TASK-024 | Pull request #42 | VER-024      |

## Open traceability gaps
- <requirement or change missing a design, work, implementation or evidence link>

ADEL responsibility

Traceability across the six layers

Possible format

Traceability table, matrix or linked system view

Use it when

People need one maintained view connecting requirements to design, decisions, work items, implementation and verification evidence.

Use an existing source instead when

People can still follow the complete path through direct links and project rules do not require a shared table.

You can change the filename, headings and fields.

See why direct links were enough

Optional repository organization

If you keep project records beside the code

These two examples show concise and more separated directory layouts. They are not required ADEL structures. Keep the project’s existing organization when people and agents can find the sources of truth they need.

concise project

project/
|-- README.md
|-- AGENTS.md
|
|-- docs/
|   |-- project-principles.md     # A short list of principles is enough
|   |-- prd.md                    # As short as the intent allows
|   |-- blueprint.md              # As short as the design allows
|   |-- adr/                      # Added when important design decisions need a record
|   |-- tasks/                    # Added when work-item details must remain available
|   `-- verification/             # Added when results must remain available
|
|-- src/
`-- tests/

Governance principles, product intent and requirements, and the approved design each use one short file. Decision, work-item and verification directories are added only when work creates a continuing need for those records.

From blank structure to completed record

See completed records in one project.

Work with ADEL shows how prompts, human decisions and project conditions turn these blank structures into completed records. It also shows why some optional records are not created.

Follow Work with ADEL Read the Framework guidance →