QUICK ANSWER
What should a content brief template include?
A content brief template should define one content item, its aggregate reader job, dated search and content intent, non-duplicative query cluster, desired reader action, coverage questions, ordered outline, source and claim registers, internal-link roles, media and accessibility requirements, metadata proposals, reviewer roles, evidence cutoff, review expiry, boundaries, and a testable definition of done.
A content brief should give one writer and the accountable reviewers a shared pre-draft contract for one article or page: who the reader is, what they need to do, which dated query evidence is relevant, which questions the content must answer, which claims the sources can support, and what the finished draft must contain before review.
This downloadable pack includes canonical starter and completed fictional JSON, deterministic Markdown, outline-and-question CSV, source and claim CSV registers, a closed Draft 2020-12 schema, and a dependency-free validator with mutation tests. It does not own a sitewide content plan, creative campaign direction, keyword research, editorial schedule, final prose, publishing, qualified approval, or search and business outcomes.
Build one evidence-backed content brief
Start with the reader task and accountable owners, then make every editorial requirement traceable. Keep the brief small enough to review before drafting and explicit about the work it cannot authorize.
Set the one-content-item boundary
Assign a stable brief ID, revision, one canonical URL, page type, owner role, reviewer roles, evidence cutoff, and review date. Reference a website content plan or creative brief when they exist, but do not copy their sitewide inventory, information architecture, campaign concept, message hierarchy, channels, or production direction into this record.
Sources: [content-brief-pack], [govuk-plan-new-content]
Record the aggregate reader job
Describe who needs the content, their context, the task or problem, the primary question, and the useful next action. State explicit non-jobs and keep names, contact details, raw responses, and other personal data outside the portable brief.
Sources: [content-brief-pack], [govuk-identify-user-needs], [ico-data-minimisation]
Reference a dated intent snapshot
Use one primary query plus a distinct supporting cluster, a search-intent label, a content-intent statement, a dated observed-result pattern, and a research reference. Do not add keyword volumes together, invent difficulty, specify density thresholds, stuff variants, or forecast rankings.
Sources: [content-brief-pack], [google-helpful-content], [google-seo-starter]
Map questions to bounded sources and claims
Give every coverage question a stable ID, priority, answer boundary, source references, and claim references. Write factual statements only when a current in-scope source supports them, label inference for review, and preserve unsupported ideas as blocked claim questions rather than invented facts.
Sources: [content-brief-pack], [govuk-identify-user-needs], [google-helpful-content]
Design the outline and presentation requirements
Order sections and connect each to its questions, sources, claims, internal links, planned media, and accessibility note. Treat title, description, H1, canonical, and schema types as proposals. Link text, headings, text equivalents, captions, disclosures, and rights still need accountable implementation and review.
Sources: [content-brief-pack], [google-seo-starter], [wcag-22], [google-structured-data-guidelines]
Expire evidence and test the handoff
Make source and claim expiry visible, keep review and change history ordered, and give each definition-of-done item an owner role, evidence reference, and non-outcome status. Run the closed-shape, reference, chronology, reserved-domain, injection, and projection-parity checks before the drafting handoff.
Sources: [content-brief-pack], [json-schema-2020-12], [rfc-2606], [owasp-csv-injection]
The content brief boundary
Use the brief to plan evidence and editorial coverage for one draft. Preserve references to adjacent owner records instead of turning this file into a site plan, campaign brief, content calendar, research database, or publishing system.
Included
- One versioned article or page, one canonical URL, owner and reviewer role aliases, evidence cutoff, review expiry, and change history
- Aggregate reader job, desired action, explicit non-jobs, dated intent snapshot, one primary query, and a non-additive supporting query cluster
- Stable coverage-question, outline-section, source, claim, internal-link, media, and definition-of-done IDs with resolved references
- Source scope and limitations, factual statements, labeled inference, blocked unsupported questions, review dates, and explicit outcome boundaries
- Metadata and schema proposals, media purpose, text-equivalent plan, caption, disclosure, rights reference, and accessibility notes
- Canonical starter and fictional JSON, deterministic Markdown and CSV projections, closed schema, dependency-free validator, mutation tests, and reproducible ZIP
Not included
- Sitewide content inventory, URL or page-purpose map, information architecture, sitemap, lifecycle governance, migration, redirects, or domain-wide strategy
- Campaign concept, communication objective, message hierarchy, brand direction, deliverables, channels, media plan, creative production, or multi-format approval
- Current keyword volume, difficulty, click estimates, SERP ownership, query-demand addition, density thresholds, stuffing rules, ranking forecasts, or research-tool authority
- Final copy, design, plagiarism checking, complete fact checking, CMS entry, editorial assignment, schedule, workflow, publication, distribution, or maintenance execution
- Raw user-research responses, names, email addresses, credentials, personal data, private source content, legal advice, or sensitive evidence copied into portable files
- Legal or compliance approval, accessibility conformance, accuracy or helpfulness certification, source authentication, provider eligibility, indexation, ranking, traffic, or conversion claims
DOWNLOADABLE RESOURCE
Download the content brief template pack
Start with the canonical JSON, use the generated Markdown for collaborative review, use the three CSV registers when a spreadsheet view helps, and run the included checks before handing the brief to a writer or workflow owner.
Content brief template pack
A one-content-item editorial contract with a starter and completed fictional example, question and outline map, source and claim registers, internal-link roles, media and accessibility requirements, metadata proposals, evidence expiry, review history, and definition of done.
Format: Markdown, CSV, JSON, JSON Schema, validator, and tests in one reproducible ZIP archive
Locally reproduced August 1, 2026. SHA-256: 03adb4eecc8145f4f53afc0059cc732f64cfe7501f77265524ad3d93802391b0
Included
- Deterministic blank and completed fictional Markdown briefs generated from canonical JSON
- Starter and completed fictional JSON plus six spreadsheet-ready CSV projections for outline and questions, sources, and claims
- Closed JSON Schema Draft 2020-12 and a dependency-free validator for stable IDs, references, chronology, boundaries, reserved data, CSV safety, and exact projection parity
- One hundred twelve deterministic positive and mutation tests plus a fifteen-file reproducible ZIP allowlist
Verification boundary
Validated both canonical briefs, regenerated and matched all eight Markdown and CSV projections, ran 112 tests, copied an exact fifteen-file allowlist, stripped ZIP metadata, fixed timestamps, checked clean extraction, and reproduced the archive across timezones.
Three parts of a bounded content brief
The fictional example plans one guide about a team intake form. It demonstrates traceability without pretending to supply final prose, workflow design, qualified approval, or measured outcomes.
Reader job and intent snapshot
Use when: One aggregate reader group has a task and a dated query-research snapshot can clarify how people seek an answer.
The fictional brief connects an operations lead's request-design task to one primary query, two distinct supporting queries, an observed result pattern, a research reference, and an explicit non-additive boundary.
Structure
- Audience, context, problem, primary question, desired action, and non-jobs define the editorial task without storing raw research
- Search observations are dated inputs only; the brief contains no invented volume, density target, ranking forecast, or performance promise
Watch for: A query cluster does not prove demand, audience fit, indexation, rank, traffic, conversion, or content usefulness. Refresh it through the accountable keyword-research process.
Sources: [content-brief-pack], [govuk-identify-user-needs], [google-helpful-content], [google-seo-starter]
Source and claim register
Use when: The writer needs to distinguish source-backed factual statements, editorial inference that needs review, and unsupported ideas that must stay blocked.
Three fictional sources support two bounded facts, one clearly labeled inference remains under review, and one completion-outcome question remains blocked because no study exists.
Structure
- Every source states its scope, limitations, check time, and review expiry, while every claim resolves to one or more current source IDs
- A blocked question has no statement and no assessed confidence, preventing the draft from silently converting speculation into fact
Watch for: Reference integrity cannot authenticate a source or prove that a reviewer interpreted it correctly. Qualified human review remains necessary.
Sources: [content-brief-pack], [json-schema-2020-12], [ico-data-minimisation]
Outline and accountable handoff
Use when: The coverage is ready to arrange into sections before a writer drafts or a workflow owner implements anything.
Three ordered outline sections map all four questions to sources, claims, internal-link roles, a planned table, accessibility notes, reviewers, expiry, and non-outcome completion items.
Structure
- Section requirements make coverage inspectable without prescribing finished prose, a campaign concept, or a publishing schedule
- Media, link, metadata, rights, disclosure, and text-equivalent proposals expose work that still needs accountable implementation and review
Watch for: A ready-for-review item records handoff state only. It is not final content approval, accessibility conformance, publication authority, or search-result eligibility.
Sources: [content-brief-pack], [wcag-22], [google-structured-data-guidelines], [owasp-csv-injection], [rfc-2606]
Decide what belongs in the brief
Prefer the narrowest record that helps one writer produce one reviewable draft. Link out whenever a decision belongs to a site planner, researcher, creative lead, calendar owner, qualified reviewer, or publishing workflow.
The requirement applies across many pages, URLs, or a site lifecycle.
Choose: Move it to the website content plan and keep only the one-page reference, canonical URL, and page role needed by this brief.
Tradeoff: The writer follows one extra reference, but sitewide inventory, information architecture, migration, and governance retain a single owner.
The requirement defines campaign concept, message hierarchy, channels, or creative direction.
Choose: Move it to the creative brief and reference the reviewed decision instead of duplicating it here.
Tradeoff: Creative context stays external, but this article brief remains a precise editorial and evidence contract rather than a second campaign brief.
The input reports keyword volume, difficulty, or a current result-page observation.
Choose: Store it in the dated keyword-research snapshot and record only the research reference, checked time, intent, and non-duplicative query cluster here.
Tradeoff: Current metrics require another source, but the brief does not freeze volatile data or turn related queries into additive demand.
A proposed factual statement lacks a current in-scope source.
Choose: Convert it to a blocked claim question with a limitation and review date, or remove it from the outline.
Tradeoff: The draft may say less, but speculation is not laundered into confident copy or an auto-generated citation.
A requirement assigns dates, writers, CMS steps, publication, distribution, or ongoing operations.
Choose: Move execution to the editorial calendar or workflow and keep only the relevant owner or evidence reference in the brief.
Tradeoff: The handoff spans records, but drafting requirements do not become a stale production tracker.
A field implies approval, conformance, eligibility, indexation, ranking, traffic, or conversion.
Choose: Set the corresponding authority or outcome flag false and route verification to the accountable qualified reviewer or provider tool.
Tradeoff: The portable record proves fewer things, but a clean validation result cannot be mistaken for real-world assurance.
From brief to editorial workflow
Build the review tool your content team needs
Use Playcode to turn a reviewed content-brief structure into an internal tool with the roles, evidence links, review states, and handoff boundaries your process requires.
Explore internal toolsAdapt permissions, evidence access, security, privacy, retention, and approval boundaries before connecting real content records.
See how Playcode supports internal toolsThe product page describes the current builder; it does not write, verify, approve, publish, or rank content.
What this template cannot prove
A strict content brief can expose gaps, conflicting references, and expired evidence before drafting. It cannot judge the truth or usefulness of the final content or take authority from its real owners.
- The validator checks closed shapes, values, references, chronology, safe example data, and projection parity; it does not authenticate sources or decide whether evidence is sufficient.
- A supported claim records declared source coverage. It does not prove factual accuracy, fair interpretation, completeness, originality, helpfulness, or qualified approval.
- An inference remains `needs_review`, and a blocked question has no statement. Neither state supplies evidence or authorizes the writer to publish the idea as fact.
- The dated intent snapshot does not combine demand, select a keyword automatically, approve search strategy, prescribe density, or guarantee discovery, indexing, ranking, traffic, or conversion.
- Metadata and schema types are proposals. Valid markup alone does not guarantee provider eligibility or a search feature, and this pack does not test a deployed page.
- Accessibility notes, alternative-text plans, captions, and media disclosures are planning fields, not WCAG conformance, accessibility testing, or approval.
- Reserved URLs, role aliases, no-personal-data flags, and injection checks make the fictional files safer to share; they do not secure a spreadsheet, CMS, evidence store, or production workflow.
- The brief does not replace the website content plan, creative brief, keyword research, editorial calendar, finished draft, plagiarism check, fact check, legal review, or publishing record.
- This ordinary informational article does not grant AI signup credits. The linked product page follows its own current eligibility and limits.
Sources and verification record
The local pack is the source for its fictional model and tests. External sources support selected content-design, search, accessibility, data-minimisation, schema, reserved-domain, and CSV-safety decisions; they do not endorse this template or certify a finished brief.
[content-brief-pack] Playcode:Completed fictional content brief example
Checked August 1, 2026. Supports: The locally reviewed one-content-item identity, reader job, dated intent snapshot, question and outline map, source and claim register, internal-link roles, media requirements, metadata proposals, review history, definition of done, boundaries, and deterministic tests. Public availability remains unverified until deployment.
[govuk-identify-user-needs] GOV.UK Content and Publishing Guidance:Identify user needs
Checked August 1, 2026. Supports: Guidance to define who a user is, the task they need to complete, the reason, supporting evidence, and acceptance criteria. Its rules govern GOV.UK and are used here as content-design precedent, not a universal mandate.
[govuk-plan-new-content] GOV.UK Content and Publishing Guidance:Plan new GOV.UK content
Checked August 1, 2026. Supports: Planning precedent for deciding whether and where content belongs, matching content to a user task, avoiding duplication, choosing a content type, and separating campaign activity. GOV.UK publishing procedures do not apply to this fictional pack.
[google-helpful-content] Google Search Central:Creating helpful, reliable, people-first content
Checked August 1, 2026. Supports: Google-specific self-assessment questions about audience, purpose, originality, sourcing, expertise, authorship, and avoiding search-engine-first content. It does not provide a ranking formula or certify helpfulness.
[google-seo-starter] Google Search Central:SEO Starter Guide
Checked August 1, 2026. Supports: Google-specific guidance for clear titles, useful organized content, reader search terms, links, images, and avoiding keyword stuffing. Google states that there is no automatic first-place ranking formula and no guarantee of indexation.
[wcag-22] World Wide Web Consortium:Web Content Accessibility Guidelines 2.2
Checked August 1, 2026. Supports: The normative accessibility requirements that inform planned headings, link purpose, structure, alternatives, and presentation. Recording a note in this brief does not establish page-level conformance.
[google-structured-data-guidelines] Google Search Central:General structured data guidelines
Checked August 1, 2026. Supports: Google-specific eligibility guidance and the explicit limit that correct markup does not guarantee appearance in search results. Schema proposals in the pack remain unverified planning notes.
[ico-data-minimisation] Information Commissioner's Office:Principle (c): Data minimisation
Checked August 1, 2026. Supports: UK regulatory guidance that personal data should be adequate, relevant, and limited to what is necessary for the purpose. This page does not provide legal advice or assess a real processing activity.
[json-schema-2020-12] JSON Schema:JSON Schema Draft 2020-12
Checked August 1, 2026. Supports: The schema dialect declared by the downloadable closed JSON Schema.
[rfc-2606] RFC Editor:RFC 2606 Reserved Top Level DNS Names
Checked August 1, 2026. Supports: Use of the reserved `.test` top-level domain for fictional content, planning, research, evidence, rights, review, and workflow references.
[owasp-csv-injection] OWASP Foundation:CSV Injection
Checked August 1, 2026. Supports: The risk that formula-leading CSV cells may be interpreted by spreadsheet software. The local generator rejects formula-leading values; this does not secure an importing application.
Content brief template questions
What is included in this content brief template?
It includes one content-item identity, aggregate reader job, dated intent snapshot, query cluster, coverage questions, ordered outline, source and claim registers, internal-link roles, media and accessibility requirements, metadata proposals, reviewers, evidence expiry, definition of done, explicit boundaries, starter and example files, schema, validator, and tests.
What is the difference between a content brief and a website content plan?
A content brief plans evidence and editorial coverage for one article or page. A website content plan owns the sitewide page inventory, URL and page-purpose map, information architecture, lifecycle, migration, and governance. This brief may store a reference and one canonical URL, but it should not duplicate that sitewide ledger.
What is the difference between a content brief and a creative brief?
A content brief maps one draft to reader questions, search intent, outline, sources, and claims. A creative brief owns campaign or creative direction, communication objective, message hierarchy, deliverables, channels, brand constraints, rights, and multi-format review. Reference a creative brief when needed; do not rebuild it inside the editorial contract.
Does the brief own keyword research or SEO outcomes?
No. The keyword-research record owns current volume, difficulty, SERP observations, and method. This brief references a dated snapshot and a non-duplicative query cluster. It does not add search volumes, set keyword density, stuff variants, forecast ranking, or promise indexation, traffic, leads, or conversion.
How should unsupported claims appear in the brief?
Keep an unsupported idea as a claim question with a null statement, `type: question`, `evidenceStatus: blocked`, `confidence: not_assessed`, source references to investigate, a limitation, and a review date. Do not let an outline or drafting tool silently convert the question into a factual statement.
Does a validated content brief approve the final article?
No. Validation checks the portable record and its relationships. A review-history entry can acknowledge scope or request changes, but `finalContentApproval` remains false. The finished prose, complete fact check, plagiarism check, legal or qualified review, accessibility testing, CMS work, and publication remain with their accountable owners.
Can metadata and structured-data fields guarantee a search feature?
No. They are proposals with measured planning widths and schema-type names. The pack locks provider eligibility and ranking guarantees false. A deployed page still needs technically correct markup, visible-content parity, provider-specific testing, and ongoing review, and even valid markup may not appear as a search feature.
Are the CSV files safe to open in any spreadsheet?
The generator rejects formula-leading values and the tests verify canonical JSON parity, which reduces one known injection risk. That does not secure a spreadsheet application, import pipeline, macro setting, connected data source, or downstream workflow. Apply the destination system's own security controls.
What does the validator check?
It checks exact closed shapes, stable and unique IDs, all false authority flags, normalized UTC timestamps, chronology, source and claim expiry, non-additive queries, cross-record references, complete outline coverage, blocked-claim states, reserved domains, credential and personal-data patterns, formula-leading cells, and exact Markdown and CSV projection parity.
Create the next step
Turn a reviewed brief into a usable content system
Describe the brief, evidence, review, or editorial workflow you need and build a first version with Playcode.
Build an internal toolThis ordinary informational article does not grant AI signup credits. Current product eligibility and limits apply.