# Vuln Signal Content Governance

Use this guide before adding or expanding content.

## Page Rule

Every page should have one clear job:

- Decide: help prioritize or choose a next action.
- Validate: help confirm exposure, trust, source, or technical detail.
- Communicate: help explain risk to another audience.
- Act: help parse, calculate, export, detect, patch, or mitigate.

If a page does not fit one of these jobs, keep the idea in notes until the workflow is clearer.

## Naming Rule

Prefer workflow names over vague feature names.

- Good: Patch Window, Detection Starter Pack, Trust Review.
- Risky: Insights, Dashboard, Overview, Advanced.

## Live-Derived Wording

Use clear language when the site infers context from loaded records.

- Say "live-derived" when a view is based on current loaded CVEs/advisories.
- Say "not packet telemetry" for campaign maps or pressure views.
- Say "validate before action" for low-confidence, disputed, or inferred data.

## Beginner-Friendly Standard

Each major page should answer:

- What is this page for?
- Who benefits from it?
- What should I do next?
- What should I not over-trust?

## Additive Feature Checklist

Before adding a feature, confirm:

- It has a unique workflow role.
- It has a route manifest entry if it is a page.
- It appears in Site Map or a relevant hub.
- It has useful metadata for page guidance.
- It has honest empty/unavailable states if data-driven.
- It works on mobile without dense horizontal layouts.

## Copy Style

Keep copy direct, calm, and operational.

- Prefer "Patch now if exposed" over "Critical vulnerability discovered."
- Prefer "Validate affected version" over "Take immediate action."
- Prefer "Source confidence is low" over "This may be wrong."

## Trust Rule

High-risk pages should mention at least one validation step:

- Confirm asset exposure.
- Confirm vendor guidance.
- Confirm affected and fixed versions.
- Confirm source confidence.
- Confirm whether a public PoC or exploitation signal is actually relevant.