Operations

Operations documents describe the work that happens between receiving a security report and publishing a controlled public record. This section is deliberately procedural: it is meant to reduce ambiguity, not to advertise capability.

The operational model assumes that sensitive material may appear during intake and review. Evidence should be minimized, handled according to classification, and reduced before publication. Reports should be triaged for authorization, scope, affected-party risk, exploitability, and remediation path before any public claim is made.

Intake And TriageReport intake checks, quality gates, duplicate handling, and routing.Evidence ReviewEvidence sufficiency, handling boundaries, and review triggers.Redaction StandardPublic sanitization expectations for screenshots, logs, tokens, and identifiers.Release ProcessPublication states, approvals, and post-release corrections.

Operating Principle

Operational discipline should be visible in the final artifact. A reader should not need to be told that evidence was handled carefully; the absence of unnecessary secrets, live identifiers, exploit-ready payloads, and unsupported claims should make that clear.

Operational pages should describe a reviewable process. A maintainer should be able to identify the required input, decision point, output, escalation rule, and record produced by each step.

Planning And Lifecycle Controls

Operations now includes the planning documents that keep the public site coherent as it grows. The publication surface map identifies the major public route families before they are finalized into IA. The content lifecycle defines how pages move between active, empty-state, template, example, draft, and deprecated states. Together, they prevent the site from accumulating pages that look official but have no defined job.

Publication Surface MapRoute families, user tasks, and public surface responsibilities.Content LifecyclePage states, review cadence, and retirement rules.