Defence digital content and writing standard

The rendered wiki is an internal digital knowledge service. Apply the Ministry of Defence (MOD) Defence Service Manual requirement to use GOV.UK content principles and styles for digital services, including services for internal users.

The Issue, Recommendation, Timing, Background and Presentation paper is a staffed document rather than a transactional service. Apply the same plain-English, accessibility and reader-centred principles, while preserving its approved Defence format, terminology, security marking and current internal writing authority.

Authority and precedence

Use the following order when guidance overlaps:

1. current internal Joint Service Publication (JSP) 101, the approved staff-work template and the issuing authority's instructions control the formal paper;
2. the MOD guidance on writing for services in Defence controls user-facing digital service content;
3. the MOD accessibility guidance and GOV.UK content standards define accessible page structure, language, links and interface copy;
4. the Development, Concepts and Doctrine Centre (DCDC) Writers' Handbook supplies useful general Defence writing and terminology principles, but its DCDC-specific house rules take precedence only for DCDC publications; and
5. older or historical material, including the 2008 MOD acronym list, is a lookup aid and must not override current Defence terminology, policy or a source's time-specific wording.

The current internal JSP 101, local template, classification, staffing route and approval authority are not held in this repository. Confirm them before issuing a formal paper.

Required content rules

Requirement	Wiki application	IRTB(P) application
Start with the user need	State the page purpose, scope and current answer before background detail.	State the issue, decision required and recommendation early.
Include only necessary content	Keep evidence that changes interpretation, confidence or action; link to detail instead of repeating it.	Keep the main body decision-focused and move supporting evidence into the annexes.
Use plain English	Prefer familiar, precise words and explain unavoidable technical or military terms.	Make complex evidence understandable to a senior reader in one reading without weakening caveats.
Keep writing short and direct	Use short sentences, one main idea per sentence and short paragraphs. Put important words first.	Use numbered paragraphs and concise option, risk, dependency and action statements.
Use active voice	Name the responsible service, authority or owner wherever evidence permits.	State who decides, owns, assures, delivers, reviews or accepts each action.
Use consistent labels	Use the canonical capability, component, cohort, evidence-status and option labels.	Keep option numbers, capability groups, owners and assurance gates consistent across the body and annexes.
Write for the audience	Use guidance-facing language on synthesis pages and technical language only where the route or evidence depends on it.	Write for the approving authority; do not assume that architecture shorthand is understood.
Check the work	Build, proofread, test links and diagrams, and check the rendered page with assistive use in mind.	Proofread, verify cross-references and evidence, and check A4 pagination, accessibility and the issued file.

Page structure and accessibility

For every new page and every page that is materially rewritten:

• use one clear, unique H1 that describes the page;
• use heading levels in sequence and do not use bold text as a substitute for a heading;
• use sentence case for headings, labels and interface text unless a proper name, formal document title or protected military term requires another form;
• make link text meaningful out of context; do not use click here, here, more or a raw URL as the visible label where a descriptive title is available;
• do not rely on colour, shape, size or page position alone to convey meaning;
• provide useful alternative text for informative images and omit redundant descriptions for decorative images;
• provide captions or transcripts for audio and video where used;
• keep labels, status terms and commands consistent; and
• use simple, specific error or limitation messages that tell the reader what happened or what evidence is missing.

These rules come from the MOD content-designer accessibility guidance and the GOV.UK service-manual guidance on writing for user interfaces.

Acronyms and Defence terminology

• Avoid unfamiliar acronyms where the full term is clearer.
• Expand an unfamiliar acronym on its first use on every rendered page. Do not assume the reader remembers an expansion from another page.
• Maintain the Glossary, build-time first-use expansion rules and browser fallback together for recurring project terms.
• Do not use a new acronym merely to shorten a term that appears once or twice.
• Keep diagrams understandable when separated from the surrounding page. Expand terms in node labels or provide a concise legend where space requires acronyms.
• Preserve the authoritative spelling and meaning of agreed military and North Atlantic Treaty Organization terminology. Do not simplify a protected term into a different meaning.
• Use capitals where required for operation names, Royal Navy ship names, military exercises and security classifications. Confirm project, programme and unit capitalisation with the responsible authority.
• Preserve source wording where programme names change over time, including Programme Cortisone, Programme CORTISONE and Op CORTISONE.

The GOV.UK style guide exempts a small set of widely understood terms, including NHS and UK, from first-use expansion. Project-specific clinical, technical and Defence acronyms still require expansion unless user evidence supports an exception.

Security and publication

Everyone working in Defence must classify and mark information correctly. Apply the current Defence rules for OFFICIAL, OFFICIAL-SENSITIVE, SECRET and TOP SECRET, and check the rules on publishing content online before release.

This public-source wiki must not contain protectively marked, personal, operationally sensitive, commercially sensitive or otherwise restricted information. A public source does not remove the need to assess how combined information could affect security or safety.

Linked official guidance

Guidance	Project use
Writing for services in Defence	Controlling MOD digital-content requirement: GOV.UK style, simple language, acronym handling, military terms and capitalisation.
Content designers: accessibility	Plain English, unique titles, semantic headings, accessible links, alternative text, captions, consistency and errors.
GOV.UK style guides	Current government content and publishing conventions.
GOV.UK A to Z style guide	First-use expansions, active voice, UK English, capitalisation, punctuation and term-specific rules.
Writing for user interfaces	Short and direct copy, cognitive load, inclusive wording, headings, links, labels and URLs.
DCDC Writers' Handbook	Supporting Defence plain-English, audience, planning, terminology, reference, lexicon and publication checks.
MOD acronyms and abbreviations	Legacy lookup aid only; verify a term against current Defence terminology before relying on it.
Development, Concepts and Doctrine Centre	Public contact route for Defence Futures and doctrine/terminology context; MODNET Defence terminology remains the internal route named by the service manual.
Security classifications	Current MOD entry point for classification, marking and online-publication controls.

Project application

Apply these rules when creating or materially revising wiki pages, diagrams, tables, navigation labels, summaries, generated documents and interface copy. Do not create unrelated wording churn across the whole wiki during a narrow evidence pass; record broad consistency work separately and correct high-risk ambiguity, inaccessible links or misleading terminology immediately.

Use IRTB(P) Construction (internal reference) for the document-specific format, option and assurance rules.