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.