Typed Findings

slug: typed_findings element_type: PRINCIPLE mutability: MUTABLE inline: true current_version: 0 status: seed-draft contentURI: null

Every security finding produced under this Sub-Leviathan — every detection, alert, vulnerability report, incident record, response action, and post-mortem — must conform to a typed schema published in this constitution's schemas/ directory (or inherited from meta). Free-text findings, ad-hoc Slack messages, and unstructured tickets are not findings; they may be raw inputs to a typed finding, but they cannot be cited, acted on, or counted in their unstructured form. The schema for each finding type carries its own version; findings reference the exact schema version they conform to.

Status

Seed-draft, no personal attribution. Cyber Security Sub-Leviathan opening set (2026-05-16). MUTABLE because the schema collection itself is expected to evolve quickly as instances accumulate experience with their domain's signal types; locking would freeze schema evolution.

Why this matters

Security operations historically run on prose — incident reports written in narrative English, alerts described in Slack threads, vulnerabilities tracked in ticket-with-comments. This produces three failure modes:

1. Aggregation impossibility. Five instances with prose findings cannot answer "how many auth-related incidents this quarter?" without expensive manual classification.
2. Cross-instance learning failure. A pattern visible in one instance's prose remains invisible to another instance reading that prose; structured fields are how patterns become detectable across the federation.
3. Long-term degradation. Two-year-old narrative reports become semantically opaque; the analysts who wrote them and the operational context they assumed are gone. Typed findings survive turnover.

Reasoning trail

• Schema versioning is mandatory. A finding from 2026 should still be parseable in 2030 even if the schema has evolved through ten versions. The exact schema version is part of the finding; tooling resolves which interpretation applies.
• "Prose is raw input, not a finding." This is the key boundary. An analyst's narrative observation is valuable; it is the input from which a typed finding is constructed. The construction step is non-optional.
• Schemas live in schemas/ — not buried in code, not in documentation, not in some external tracking system. The schema is constitutional content, versioned alongside terms and rules, ratified through proposal lifecycle.
• Inherited schemas. The Sub-Leviathan inherits any meta-level schemas. Where this Sub-Leviathan defines its own, the inheritance applies as superset rule: domain schemas extend, never weaken, the meta schemas they reference.

Implications

This principle means certain things become impossible:

• A senior engineer cannot file an incident as "I think we got hit, will investigate, gonna check logs"
• An alert cannot be a Slack message with a Grafana screenshot
• A vulnerability cannot be a sentence in a wiki page

All three are valuable as raw inputs that become a typed finding. The principle requires the construction step.

Sub-Leviathan inheritance

MUTABLE. Instances may add their own typed finding schemas; instances may not exempt themselves from the typing requirement. An instance that wishes to maintain prose-based operations is outside this Sub-Leviathan.

Related elements

• term:incident, term:vulnerability, term:threat, term:asset — these terms imply typed schemas
• rule:forensics-immutability — typed findings are how immutability is enforceable
• Inherited from meta: term:evidence (citation format), rule:evidence-required (schema-typed evidence)

Schemas directory

To be populated by domain authors. Initial seed schemas anticipated:

• schemas/incident-record.json
• schemas/vulnerability-report.json
• schemas/detection-alert.json
• schemas/response-action.json
• schemas/post-mortem.json

Each schema follows the standard element format with versioning, mutability tier, and editorial separator. See leviathan-protocol/meta/docs/element-format.md.

Lineage

Direct mapping from aigentone/leviathan-security README: "typed security findings and policy" and the explicit framing as "local-first, typed, policy-driven security control plane." Generalized from instance practice to Sub-Leviathan principle.