Website Publishing Guide

Category: website Sources: live Field Note and Guide reading templates (finalised 2026-08-10), website system, voice guide, current Guides and Recall Watch Confidence: high Last Updated: 2026-08-10

Purpose

This guide defines how to create a Guide, Field Note or Recall Watch update that feels native to the Trace website.

Read Website, Voice Guide, Banned Words and the relevant technical source material before drafting. Inspect a current built page before writing markup. The live Field Note and Guide templates are the authority for the reading-page system below.

Do not publish to fill a calendar. Publish when the piece resolves a real question or improves a real decision.

Shared editorial standard

Every piece must:

  1. answer one clear reader question
  2. state the useful answer early
  3. separate verified fact from Glen's interpretation
  4. define specialist terms at first use
  5. explain what the reader should check or do next
  6. state scope and limitations
  7. link to primary or authoritative sources where the claim depends on them
  8. use British English and the Trace voice
  9. avoid invented facts, urgency, clients, results or statistics
  10. connect to no more than one relevant service action

Never imply that Trace issues certificates, controls an independent decision or guarantees compliance, certification, approval or market access.

Source standard

Use the strongest available source:

  1. legislation, regulator or official public record
  2. current published standard or official standards-body material
  3. certification-body or test-house documentation for their own process
  4. verified Trace experience, clearly presented as experience or judgement
  5. reputable secondary explanation only when no primary source answers the point

For regulations, standards, recalls and current public bodies, verify the source on the day of publication. Record:

  • source title
  • issuing organisation
  • direct URL
  • publication or record date
  • access date
  • what claim the source supports

Do not copy long passages. Quote only where exact wording materially matters, and keep the excerpt short.

Required page metadata

Prepare this before layout:

Field Requirement
Title direct, specific, accurate
Browser title title plus Trace Technical Compliance
Description 140 to 160 characters stating the reader benefit
Slug short, lowercase, hyphenated
Publication date ISO date plus readable date
Updated date include when a factual change is made
Category one approved channel category
Sources complete source list
Service bridge one service or none
Disclaimer appropriate to the subject

Do not use a clever title that hides the question.

Shared reading-page standard

Field Notes and Guides use the same reading system:

  • quiet-grey page ground
  • one white reading sheet, maximum 920px wide
  • 20px sheet radius on desktop; full-bleed on mobile
  • body text at 16px with approximately 1.72 line height
  • restrained title scale, approximately 28 to 37px
  • section headings approximately 19 to 22px
  • running text in Body Grey; headings and meaningful bold text in Ink
  • roughly 60 to 70 characters per line
  • spacing carried by heading and paragraph rhythm, not empty elements or arbitrary gaps

The header order is:

  1. clear "All field notes" or "All guides" back control
  2. category and publication date where relevant
  3. yellow "Field Note" identifier at the top right on Field Notes only
  4. title, with deliberate separation from the metadata
  5. one short deck
  6. body

The deck is the only introductory lead. The first body paragraph uses ordinary body styling. Do not create a second lede, an oversized opening paragraph or a disconnected introductory block.

Eyebrows and callout labels use sentence case. Do not use small lowercase labels that blend into body copy, or inconsistent all-capital labels.

Approved content treatments

Editorial callout

Use for the short answer, a governing consequence, or one sentence worth retaining.

  • thick left Ink border
  • no filled background
  • no rounded card
  • label in sentence case
  • body-sized or only slightly enlarged text
  • usually one short paragraph

Do not use small eyebrow text such as "The cost of missing it" floating above body copy. If the phrase matters, make it a proper heading or integrate it into the callout sentence.

Margin note

A quiet grey box may be used for genuinely supporting context.

  • use sparingly
  • one neutral surface
  • compact padding
  • body-sized text
  • never stack several margin notes together

Signature framework

A signature framework is editorial content, not a special visual component. Style it like an ordinary article section:

  • normal H2
  • ordinary paragraphs
  • meaningful bold only where required
  • no yellow background
  • no reduced-width text block
  • no floating "Signature framework" eyebrow

The content may still name a framework, but its visual treatment must not interrupt the reading flow.

Lists

Use semantic <ul> and <ol> markup. Never type numbers manually into paragraphs. Unordered lists use normal bullets; ordered lists use the shared numbered treatment.

To-do or checklist unit

Use when a Field Note ends with a practical sequence:

<section>
  <h3>[Checklist title]</h3>
  <ol>
    <li>[Action]</li>
    <li>[Action]</li>
  </ol>
  <p>[One short closing instruction, if needed]</p>
</section>

The template styles this as a keyed sequence on a single left ink rule, the same rule family as the editorial callout, not a bordered box: title, numbered steps and a closing line share one continuous keyline. Keep steps short and executable. Do not put ordinary narrative paragraphs inside the checklist.

Guide

Job

A Guide gives a stable, plain-English answer to a foundational or product-specific question. It should help a reader understand the issue without having to contact Trace.

Design pattern

A Guide uses:

  • the shared grey-ground and white-sheet reading system
  • a question-led or direct title
  • one concise deck
  • an early short-answer callout using a thick left Ink border
  • clear, restrained H2 sections
  • properly marked-up lists
  • one practical check
  • one concise service bridge
  • a quiet disclaimer
  • the shared subscription footer

The short answer is an editorial callout, not a rounded grey or yellow card. It should normally contain one label and one short paragraph.

Do not place sources, related reading, CTA and disclaimer inside one large closing container. The close remains visually open: concise text, one button and small disclaimer copy.

Structure

Use this order where it suits the question:

  1. direct title
  2. concise deck
  3. ordinary introductory paragraph
  4. short-answer callout
  5. definition or scope
  6. what the evidence or rule actually establishes
  7. what it does not establish
  8. examples or decision points
  9. one practical check
  10. one service bridge
  11. disclaimer and sources

Do not force every Guide into the same number of sections. Stop when the question has been answered properly.

Field Note

Job

A Field Note turns a real recurring situation into practical judgement. It is not a teaser, short blog post or disguised sales story.

A Field Note returns only when the full piece is complete and approved. Do not publish provisional notes.

Approved categories

  • How the system actually works
  • Avoidable mistakes
  • From live to covered
  • More hands, not more safety

Add a category only when several future notes genuinely need it.

Design pattern

A Field Note uses:

  • the shared grey-ground and white-sheet reading system
  • "All field notes" as the back control
  • category and date in the metadata row
  • a distinct yellow "Field Note" identifier at the top right
  • one concise deck
  • ordinary body copy with restrained headings
  • no mandatory yellow consequence panel
  • one professional editorial callout where useful
  • one compact to-do or checklist unit where the action genuinely benefits from steps
  • one service bridge
  • a quiet disclaimer and confidentiality note
  • the shared subscription footer

The Guiding Progress mark or the Field Note badge identifies the channel. Do not repeatedly label blocks "Field Note", "Signature framework" or similar inside the article.

Structure

  1. recognisable situation
  2. why the assumption looked reasonable
  3. where the product, evidence, certificate or claim stopped matching
  4. what followed
  5. what would have caught it earlier
  6. reusable decision rule
  7. practical action or checklist
  8. one natural service bridge
  9. disclaimer and confidentiality note

The opening situation should move directly into the first section. Avoid the sequence of a deck, a second large introductory paragraph and another large section gap: that makes the opening feel disconnected.

Evidence and confidentiality

  • Use a public record, Glen's direct experience or a clearly labelled composite pattern.
  • Remove client, product and supplier identifiers unless written permission exists.
  • Do not combine details in a way that makes an unnamed client identifiable.
  • Do not imply a product was unlawful, unsafe or non-compliant unless an authoritative source says so.
  • Record the internal evidence source even when the published note must remain anonymised.

Ending rule

The ending of a reading page must not become a stack of a grey consequence box, a second CTA panel, a subscription panel and a disclaimer box.

Instead:

  • incorporate the strongest consequence into the service bridge
  • use one heading or bold opening line
  • explain the service connection in one short paragraph
  • use one button, without a decorative arrow
  • place the disclaimer underneath as quiet text
  • leave subscription to the shared footer

The service bridge must name only one service. Cut duplicated consequence copy instead of repeating it in a separate grey box.

Length guidance

Word counts are orientation, not targets.

  • Guides commonly fall between 700 and 1,600 words.
  • Field Notes commonly fall between 700 and 1,300 words.

A shorter complete article is better than a padded one. Do not add sections, examples or frameworks merely to reach a word count.

Footer and subscription

Field Notes, Guides and Recall Watch use the shared subscription footer, headed:

Get notified when a new field note is released

The email input sits beneath or alongside that line according to the responsive layout. Article authors must not add a second subscription form inside the article body or close.

CRM markup contract for Field Notes

Field Note body HTML may use:

  • ordinary p, h2, h3, ul, ol and section
  • .reading-intro for the first ordinary paragraph only
  • .reading-callout for one editorial callout
  • .margin-note for occasional supporting context
  • .note-verdict only when needed for legacy CRM compatibility; it renders as an ordinary section
  • .reading-next for the single service bridge
  • .reading-disclaimer for the closing boundary

Do not add inline spacing, empty paragraphs, repeated <br> elements, custom widths, arbitrary background colours or one-off card classes. The template owns spacing and presentation.

Questions this raises (Field Note FAQ)

Every Field Note ends with a short "Questions this raises." block: two questions a reader still has after the note, each with a concise, bounded answer in the Trace voice. The second answer may bridge to one Trace service as an inline link.

The FAQ is not body markup. It is structured data on the article's content_objects.faq column, a JSON array of { question, answer, service?: { href, label, suffix } }, written by the article generator or by hand and rendered by the template as the note's editorial ending. Because the FAQ is the ending, the in-body .reading-next service bridge and .reading-disclaimer are suppressed on Field Notes; Guides still use the service bridge and disclaimer.

Reading-page QA (Field Notes and Guides)

Before publishing a Field Note or Guide, verify:

  • the back control clearly looks interactive
  • the title has enough separation from the metadata
  • there is only one deck
  • the first body paragraph does not become a second lede
  • body, headings and lists form one continuous reading rhythm
  • no heading or paragraph is oversized
  • no unexplained large vertical gaps remain
  • eyebrow and callout labels use sentence case
  • all lists use semantic markup
  • the signature framework reads like a normal section
  • any checklist is compact and executable
  • the close contains only one service bridge and one button
  • no decorative arrow appears on the CTA
  • the subscription form appears only in the footer
  • the page works at 1366px, 768px, 390px and 320px
  • the white sheet becomes full-bleed on mobile without horizontal overflow

Recall Watch

Job

Recall Watch turns the public record into questions a PPE product team can apply to its own range. It is not a claim that Trace investigated the product or reached an independent legal conclusion.

Entry fields

Every record entry needs:

Field Requirement
Record date date shown by the public source
Product public product name or clear description
Product group consistent category label
Market UK, EU or other relevant jurisdiction
Public source issuing authority and direct record link
Public finding careful summary of what the source actually says
Pattern the failure mode or evidence issue the record illustrates
Check prompt one question for the reader's own product or evidence
Verified on date the link and wording were rechecked

Source rules

  • Prefer the official recall, safety alert or market-surveillance record.
  • Preserve the authority's level of certainty. Do not strengthen words such as may, could or risk.
  • If the record is corrected, withdrawn or moved, update the entry and note the verified date.
  • Do not infer the cause of a recall when the record does not state it.
  • Link directly to the record, not to a search result.

Annual structure

  • current year labelled Running
  • completed years retained as separate tabs
  • year tabs use Arrow Left, Arrow Right, Home and End
  • each year opens with one primary statistic and two context statistics
  • definitions and collection limits stay visible
  • entries accumulate through the year
  • completed years are not silently rewritten to tell a neater story

Design pattern

Desktop uses the existing record table. Mobile converts every row to a labelled card. Never introduce horizontal table scrolling. Use Trace Yellow for the running or primary statistic, not every number.

Disclaimer

Recall Watch must state that it is general information based on the cited public record. It is not legal advice, a product-specific compliance determination or evidence that an uncited product has the same issue.

Quality test

Every entry should give the reader a defensible source and a useful question without making a stronger claim than the public record.

Writing and design workflow

  1. Choose the channel based on the reader's job:
    • stable explanation: Guide
    • reusable judgement from a situation: Field Note
    • public-record pattern: Recall Watch
  2. Gather and record sources.
  3. Write the one-sentence answer or decision rule.
  4. Draft in the approved structure.
  5. Check claims and boundaries.
  6. Edit into Glen's voice.
  7. Add the page using the closest approved source page as the template.
  8. Update the hub and navigation only where required.
  9. Build and test against the reading-page QA above.
  10. Publish to a Cloudflare preview before production.

Eleventy implementation

Current source lives in digital-home/frontend/src/.

For a Guide:

  1. duplicate the closest complete Guide HTML file
  2. rename it to the approved slug
  3. replace title, description, visible content and current navigation state
  4. add the new Guide to src/guides.html

For a Field Note (backend-driven since 2026-08-09; this supersedes any by-hand process for this channel only):

Field Notes are not individual HTML pages. They are rows in the Digital Home backend's content_objects table, fetched by src/_data/articles.js at build time (status = 'published', content_type = 'article') and rendered by src/insights.njk's loop. There is no file to create or add to a hub by hand.

  1. Draft the note in the approved structure and voice, then create it as a content_objects row in the CRM with status: draft (fields: slug, title, subtitle, excerpt, body, author_name, published_at, featured_image_url, semantic_tags, faq). Body HTML follows the CRM markup contract above; the faq is the separate structured field described under "Questions this raises".
  2. Approve it, then flip status to published in the CRM. This is the actual publish action.
  3. Trigger a site rebuild to make it appear (push a commit or redeploy manually in Cloudflare Pages). The deploy hook that would do this automatically on publish is not wired yet (see Infrastructure).
  4. insights.njk handles the empty-state-to-notes-grid swap and ordering (published_at.desc) automatically. Nothing to edit there per note.

Guides and Recall Watch are hand-built pages per the steps above.

For Recall Watch:

  1. add the record to the current year's panel in src/recall-watch.html
  2. keep the table headers and mobile data-label values aligned
  3. update the current-year statistics only from the verified record set

Source pages may use the existing relative .html links. Eleventy rewrites them to extension-free production URLs. Assets use the existing assets/ paths and receive content hashes during the build.

Run:

npm run build
node scripts/check-approved-links.mjs

Then inspect the production output at desktop, tablet and mobile sizes. Check the new page, its hub card, previous and next reading links, navigation, focus order, console and the 404 path.

Prompt for Codex or Claude

This prompt is for old-website content operations only (Guides, Field Notes, Recall Watch updates, and landing pages published to the current live site while the redesign is still in progress). It does not apply to redesign work — see Website Redesign Direction, which explicitly rules out cloning the old site's system into the redesign. Once the redesign ships, retire this prompt or re-scope it to the new system.

Use this when asking an agent to create a new page on the old website:

Create a new Trace website [Guide / Field Note / Recall Watch update / landing page]. Read brand-wiki/wiki/website/website.md, brand-wiki/wiki/website/publishing-guide.md, the voice guide and the current production source before making changes. For a Guide or Field Note, follow the shared reading-page standard and the approved content treatments: editorial callout as a thick left Ink border, signature framework as an ordinary section, no yellow consequence panel, one service bridge, subscription only in the shared footer. Reuse the closest approved page and the existing tokens and components. Do not invent a new visual system, add stock imagery, introduce another font, turn every section into a card, or use Trace Yellow beyond the page's one priority. Preserve British English, Trace boundaries and source wording. Verify against the reading-page QA at 1366x900, 768x1024, 390x844 and 320x800, including keyboard and mobile-menu behaviour.

Related Articles