Example Catalog
The example catalog defines what examples are expected to show. Examples are useful because they make abstract policy easier to apply. They are risky when they look like real authorization, real vendor evidence, or reusable exploit material. The example library should stay synthetic or sanitized and should identify the lesson each artifact is meant to teach.
An example should be narrower than a report and safer than an advisory. It can demonstrate structure, redaction style, timeline formatting, severity rationale, or tool output interpretation. It should not contain live targets, real secrets, unpatched exploit steps, or claims that depend on private context.
Example Families
| Family | Purpose | Boundary |
|---|---|---|
| Advisory Summary | Demonstrates public advisory structure | Synthetic identifiers or reviewed historical-safe material |
| Sanitized Report | Shows how to organize findings and evidence | No credentials, live logs, or third-party private data |
| Tooling Pattern | Shows how browser tool output can support a note | Output is illustrative, not a verdict |
| Redaction Pattern | Shows before/after handling without sensitive content | Synthetic values or irreversible redaction |
| Timeline Pattern | Shows how coordination events are recorded | No private participant detail without approval |
Usage Rule
Examples are not templates for unauthorized testing. They are examples of documentation and handling quality. A reader should be able to copy the structure without copying any sensitive technical act. If an example cannot make that distinction clear, it belongs in private training material rather than the public site.
Maintenance
Examples should be reviewed when the related template, schema, or policy changes. An example that no longer reflects the current advisory or report model should be updated or marked deprecated. Public examples are part of the site’s trust surface because they reveal the standard that future publications will be held to.