Skip to main content
DraftIndicative placeholder for the section owner — amend, replace, or confirm as the first definitive version.

Doc owner: DDE

Edit in git: full-featured drafting and revisions

Use this path when you are comfortable with Git, markdown, and pull requests. You get local editing, your own branching model, and full revision history before merge.

Structure, IDs, filenames, front matter, and rationale rules — see Handbook standards. Tone and plain English — see Writing style.

1. Create a branch​

Create a feature branch from main for your changes:

git checkout -b your-name/short-description

2. Make changes with clear commits​

  • Use descriptive commit messages
  • One logical change per commit where practical
  • Reference related decisions or policies in commit messages when relevant

3. Follow the structure​

  • Strategy — Definitive intent only; drafts belong in Drive
  • Policy — Use the front-matter template; assign policy IDs (POL-<DOMAIN>-<NUMBER>)
  • Operations — Programmes and portfolio under operations/; see Operations
  • Governance — Decision records in decision-log/; use the template
  • Procedures — How-to steps; add only when policy requires them
  • Templates — Checklists and forms; support procedures
  • Systems — Function definitions, interfaces, tooling conventions
  • Handbook design context — rationale/ mirror and automation: Handbook standards — Rationale and Rationale

4. Titles, IDs, and file names​

Canonical rules live in Handbook standards (titles, POL-* / DEC-*, filenames, strategy YAML, lists/tables). This section only reminds Git authors to apply them before opening a PR.

5. Update indexes​

When adding policies or projects, update the relevant index:

  • policy-index.md
  • operations/portfolio/portfolio-index.md

6. Submit for review​

  • Open a pull request
  • Request review from the relevant owner (see policy/project front-matter)
  • Address feedback before merge