Publication Release Process

1. Purpose

The release process prevents broken links, accidental sensitive-data publication, unsupported claims, and unstable public references. Every public artifact should be durable enough to cite and safe enough to archive.

2. Release Classes

Class	Examples	Required review
Policy	RoE, disclosure policy, data handling	policy owner and technical review
Advisory	vulnerability advisory	evidence, coordination, severity, redaction
Report	research report, methodology note	technical, editorial, redaction
Dataset	schema, aggregate data	privacy, schema, provenance
Tool	browser utility, validator	security, accessibility, no-network behavior
Example	sanitized advisory/report example	exploitability and clarity review

3. Required Pre-Release Checks

Before release:

• page has a stable URL;
• title and description are accurate;
• status is clear;
• owner is identified;
• date and version are current where applicable;
• sensitive content review is complete;
• exploitability review is complete;
• links resolve;
• sitemap data is updated if needed;
• npm run check passes;
• local preview is reviewed;
• rollback path is known.

4. Security Checks

Confirm:

• no raw case evidence;
• no credentials or tokens;
• no private keys;
• no unapproved personal data;
• no unapproved vendor correspondence;
• no exploit-ready payloads;
• no external script or asset dependency unless approved;
• no unsafe SVG content;
• no accidental authorization language;
• no stale policy date;
• no unsupported public claim.

5. Content Checks

Confirm:

• the document says who it is for;
• facts and assumptions are separated;
• severity claims are supported;
• limitations are stated;
• remediation status is accurate;
• vendor names, product names, and versions are consistent;
• attribution is approved;
• language is professional and restrained;
• public value is clear.

6. Routing Checks

Stable pages should use trailing-slash HTML routes:

• /docs/policy/rules-of-engagement/;
• /reports/methodology/;
• /advisories/published/advisory-id/.

Static public files should use durable file paths:

• /docs/policy/documentid.pdf;
• /data/schemas/schemaid.json;
• /reports/published/reportid.pdf.

Do not silently break old public URLs. Use redirects when replacing routes.

7. Build and Validation

Run:

npm run check

For local preview:

npm run serve

Review the rendered page, not only Markdown source.

8. Publication States

Use clear status language:

• Draft: not public, not citeable;
• Staged: public route may exist but content is not final;
• Coordinating: vendor or maintainer process active;
• Published: final public artifact;
• Revised: published artifact updated with material change;
• Archived: retained for history, not current guidance;
• Withdrawn: removed or replaced due to accuracy, safety, legal, or coordination issue.

9. Post-Release Monitoring

After release:

• verify production URL;
• verify security headers where relevant;
• verify sitemap and llms files if affected;
• check obvious rendering problems;
• confirm redirects;
• record publication time;
• monitor for correction requests.

10. Corrections and Withdrawals

Corrections should preserve transparency. If an error materially affects security interpretation, add a revision note instead of silently editing.

Withdraw when publication creates unacceptable harm, contains sensitive data, is legally constrained, or is materially inaccurate. Preserve a stable landing page with a short removal note when possible.