Editorial depth standards for Zeph Tech briefs

Our briefs must provide enough depth that operators can brief executives and execution teams without chasing additional sources. Editors should verify every new entry in zephtech-site/content/feed/ against the depth controls below before submitting a pull request.

Depth thresholds

Requirement	Minimum	Notes
Word count (word_count)	1,100 words	Count after templating; automatic checks read the stored word_count field and block thin briefs from publishing.
Estimated reading time (reading_time_minutes)	At least five minutes	Aligns with the word-count floor; anything shorter must be expanded before entering the feed.
Structured sections (<h3> headings)	At least three	Organise the narrative across execution priorities (e.g., compliance checkpoints, operational moves, enablement).
Source citations (sources)	Two or more	Link to official regulations, vendor notices, or authoritative research—no press summaries or secondary commentary.

Failing any requirement blocks CI. Use the headings to distribute detail evenly; avoid dumping long paragraphs under a single section.

Outlines should target 1,200–1,800 words so the finished brief comfortably clears the five-minute minimum while leaving room for actionable details and sourcing. When refreshing legacy briefs, expand any sub-five-minute entries before redeploying the feed so operators receive consistent depth.

Validation workflow

Run the validators locally whenever you update or add feed content:

python scripts/check_feed_lengths.py --base-ref origin/main
        python scripts/check_brief_depth.py --baseline scripts/tests/fixtures/feed_depth_baseline.json
        

The commands print any failing slugs and exit with a non-zero status when a brief breaks the thresholds. The length guardrails diff against the base branch by default; use --all if you are intentionally re-editing historical briefs and want to audit the full catalogue. The depth baseline file tracks historical briefs that still need rewriting; do not add new slugs to the baseline. Instead, expand the brief until it meets the standard and remove the slug from the baseline once the content passes. CI will also fail if a slug remains in the baseline but now satisfies the checks—this nudge keeps the backlog up to date.

Source expectations

• Citations must point to first-party or regulatory material that fully supports the claims in the brief.
• Summaries should include specific regulatory deadlines, enforcement expectations, or engineering tasks readers can action immediately.
• When referencing enforcement policies, confirm the effective dates and scope in the primary source before publishing.

Aligning with these thresholds keeps nightly briefings “longer, more in-depth, and unique” so leadership can act on them without additional research.