security-canon/INTENT.md

# Intent

SecurityCanon provides an implementation-neutral vocabulary and canonical model
for security-related concepts. It extends InfoTechCanon in the same architectural
role that CommerceCanon serves for commercial terminology and InterfaceCanon for
interface terminology: import shared roots, contribute a focused domain model,
and avoid redefining concepts another canon already owns.

## Origin and demand

The initial demand is the repository owner's 2026-09-20 request to refine
InfoTechCanon by moving its IT-security material into a dedicated canon.
InfoTechCanon has accumulated security content — a security model, an access
control model, a DevSecOps model, the CARING access governance standard, and the
CARING Kubernetes RBAC benchmark — that is orthogonal to its taxonomy-layer role
and better served by a canon with its own review cadence and consumers.

Extraction is a migration, not a rewrite. Source artifacts keep their provenance,
and InfoTechCanon retains the shared roots that security terminology imports.

## Layer and boundary

SecurityCanon declares itself part of the **Taxonomy** layer under the NetKingdom
Security Layer Model. It produces security terminology, semantic contracts, and
compatibility rules for independently owned systems.

SecurityCanon owns security concept definitions and their cross-canon mappings.
It does not own a runtime position, enforcement, or state on which another layer
depends:

- **NetKingdom** owns its security architecture, its standards of record,
  including the security layer model, and any NetKingdom-specific profiles that
  import this canon.
- **flex-auth** owns authorization decisions; **key-cape** and Keycloak own
  login, OIDC, and MFA; **OpenBao** owns secret custody. SecurityCanon describes
  those concepts; it does not perform them.
- **whitehat-security** owns adversarial evidence and findings practice.
- **InfoTechCanon** remains the authority for the shared roots — artifact,
  ownership, relationship, mapping, assimilation, profile, pattern, conformance,
  provenance, and interface mechanisms — that this canon imports.
- Consumers own their own adoption evidence and importing profiles.

A generic security semantic contract belongs here; a security obligation imposed
on a concrete estate belongs to the owner of that estate.

## Primary utility

SecurityCanon helps turn security integration by interpretation into integration
by declared semantic contract. It provides:

- canonical security concepts with clear ownership,
- orthogonal security standards that import rather than redefine,
- mappings to external security standards, frameworks, and regulations,
- benchmarks that test a standard against a concrete native access model,
- application profiles for concrete implementation contexts,
- and retrieval-friendly markdown artifacts for humans, agents, and tools.

## Design stance

SecurityCanon follows InfoTechCanon's stance: markdown-first but machine-readable,
network-shaped rather than purely hierarchical, pattern-oriented rather than merely
taxonomic, externally mappable without being externally constrained, and
orthogonal without becoming isolated.

External standards influence SecurityCanon through mappings and assimilation.
They do not define its internal semantics directly.

## Core commitments

1. Every canonical security concept has a clear owner.
2. Concepts are imported from their owning canon, never redefined.
3. Mappings to external bodies of knowledge are explicit, versioned, scoped, and justified.
4. Migrated artifacts preserve provenance and their InfoTechCanon history.
5. Profiles constrain standards for concrete implementation contexts.
6. Artifacts are useful to both humans and agents.
7. Evolution preserves provenance, compatibility information, and rationale.

## Non-goals

SecurityCanon does not replace external standards such as NIST, ISO 27001, CIS,
OWASP, or MITRE ATT&CK. It does not define one mandatory security model every
system must fully implement, operate consumer systems, enforce policy, issue
credentials, or provide production authorization or detection services.

## Direction of travel

The repository should initially establish the canon skeleton and federation
interface, then receive the security material extracted from InfoTechCanon with
its provenance intact, then publish mappings and at least one worked profile.
Stable promotion requires reviewed mappings and concrete consumer evidence.

## Outcome

InfoTechCanon's IT-security material lives in SecurityCanon as a coherent,
independently reviewable canon: security terminology, the CARING access
governance standard and its Kubernetes RBAC benchmark, published with declared
imports from InfoTechCanon, a federation interface card, and preserved
provenance — while InfoTechCanon retains only the shared roots those artifacts
import and carries no dangling references.

## Invariants

- InfoTechCanon remains valid at every step: `make check` passes and its
  validation reports zero errors before and after each migration slice.
- Migrated artifacts keep their provenance and their InfoTechCanon history;
  extraction is a move with recorded lineage, not a rewrite.
- Concepts are imported from their owning canon, never redefined on both sides.
- No concept is left unowned, and no concept is claimed by two canons.
- The State Hub stays a read model: workplan files here are authoritative and
  are registered by `fix-consistency`, never by hand.

## Success gates

1. Repository registered in the State Hub with a topic, classification, and
   federation interface card; reciprocal navigation with InfoTechCanon passes
   the canon-federation validator.
2. A reviewed disposition record naming, for every security artifact in
   InfoTechCanon, whether it moves, stays, or splits — with rationale.
3. Migration complete: the artifacts dispositioned as `move` are present here
   with provenance, and absent from InfoTechCanon.
4. Both canons validate clean after migration, with no unresolved cross-canon
   references in either direction.
5. At least one worked profile or benchmark demonstrates the canon is usable by
   a consumer, and its scope statement is reviewed against intent.

## Project retirement

Archive this repository only if the extraction is abandoned and the material
returns to InfoTechCanon. On success this repository does not retire — it
becomes a standing canon and its project flavor is reconsidered, as
CommerceCanon and InterfaceCanon were.