Publication Surface Map
The publication surface map defines what the public site is expected to contain before the final information architecture is treated as stable. It separates pages that describe authority, pages that publish artifacts, and pages that provide local utilities. The map is not a promise that every route will contain public records immediately. It is a control document for preventing the site from growing as a set of disconnected pages.
A route belongs on the public site when it answers a user question that should not require private context. If the answer depends on embargoed evidence, internal review notes, or unresolved vendor communication, the route can describe the public boundary but must not expose the private material. This distinction lets the site grow without turning work-in-progress into public obligation.
Surface Families
| Family | Public Role | Primary User | Current State |
|---|---|---|---|
| Policy | Defines authorization boundaries, reporting expectations, data handling, and coordination model | Researchers, vendors, reviewers | Active public reference |
| Operations | Explains intake, evidence review, redaction, release, and publication controls | Researchers, maintainers, vendors | Active public reference with additional workflow pages planned |
| Research | Defines methodology, severity analysis, and publication assumptions | Researchers, defenders, vendors | Active public reference |
| Advisories | Publishes issue-specific coordinated disclosure records | Defenders, vendors, researchers | Stable namespace with empty-state listings until first advisory |
| Reports | Publishes broader research reports and sanitized methodology records | Researchers, defenders, partners | Stable namespace with templates and methodology |
| Data | Publishes schemas, aggregate metrics, and citable datasets | Researchers, tooling users, maintainers | Schema-first, publication surface reserved |
| Tools | Provides local browser utilities and later signed downloadable tooling | Researchers, maintainers | Browser-local tools active; downloads reserved |
| Examples | Shows sanitized publication patterns without authorizing new activity | Researchers, vendors, reviewers | Active example library |
Route Planning Standard
Every route should have a clear job. A route that only says that something exists should either become an index with useful routing context or be merged into the nearest stronger page. Pages that publish artifacts need stable identifiers, status language, citation behavior, and a correction path. Pages that explain process need inputs, decisions, outputs, and escalation boundaries.
Future routes should be introduced in three steps. First, define the intended record type and the user question it answers. Second, add the route to the surface map and sidebar only if it has enough content to stand alone. Third, add a validator or schema when the route begins publishing repeatable records. This keeps the site from accumulating empty headings that look complete but cannot guide action.
Dependency On Information Architecture
The IA can be simplified only after the surface inventory is known. Navigation decisions made too early tend to reflect the implementation history of the site rather than the way users evaluate it. The working assumption is that a visitor arrives with one of five tasks: report something, understand boundaries, use a tool, read a publication, or verify trust material. The final IA should optimize for those tasks after enough content exists to show which surfaces are real.