Skip to main content

Documentation

Documentation is the public control surface for how PunchCard Labs receives, reviews, coordinates, and publishes security research. The goal is not to make the process sound complicated. The goal is to make the boundaries clear enough that researchers, vendors, and reviewers can understand what is allowed, what is prohibited, and what evidence is appropriate for each stage.

The documentation set is organized around operational use rather than marketing categories. Policy pages define authority and public boundaries. Operations pages describe how intake, redaction, evidence review, and release decisions are handled. Research pages describe methodology and severity analysis. Templates provide publication structures that can be reused without re-inventing the process for every report.

Reading Order

Start with policy when evaluating whether an activity belongs under PCL coordination. Use operations material when preparing or reviewing evidence. Use research material when documenting impact or severity. Use templates only after scope, authorization, and handling constraints are already understood.

This section should give readers enough context to act without guessing. If it cannot define the input, output, boundary, or next step, it should be merged into a stronger page or expanded before publication.

Maintenance Standard

Public process documents should be specific enough to guide behavior without exposing internal-sensitive workflow details. When a page becomes stale, incomplete, or superseded, it should be marked as such rather than left to imply current authority.

This section should give readers enough context to act without guessing. If it cannot define the input, output, boundary, or next step, it should be merged into a stronger page or expanded before publication.

Surface Planning

The documentation set now includes a publication surface map and a content lifecycle standard. Those pages describe what the site is expected to contain before the final navigation model is treated as stable. They are useful when deciding whether a new route should exist, whether a thin page should be merged, or whether a future artifact needs a schema before it becomes public.