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 giving its IT-security material a dedicated home.

Reviewing the Mode of Authority draft changed what that means. SecurityCanon's first contribution is architecture-layer security vocabulary of its own, not a transfer of InfoTechCanon's content. Per SEC-ADR-001, content migration is neither urgent nor a goal in itself:

SecurityCanon should help, not hinder, keeping InfoTechCanon practical.

An artifact moves only when moving it makes both canons more practical, and the burden of proof is on the move. Anything that does move keeps its provenance.

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.
• access-engine (formerly the repository 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. There is one decision point.
• 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. It also keeps CARING, the access-control model, and the identity model: CARING because it is implementation-layer and imports eleven InfoTechCanon models, identity because it is a shared root reaching into personhood rather than a security concern. A dedicated identity or personhood canon is deferred, not rejected.
• 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.

It adds one stance of its own: architecture, not implementation. SecurityCanon describes the relationships in which authority is exercised, before and independently of the mechanisms that enforce them. CARING occupies the implementation layer in InfoTechCanon. The two are different layers of abstraction, and neither subsumes the other — but they must not use the same word for different things.

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. Direct terminology overlap with InfoTechCanon is avoided: where a concept is shared it is defined once upstream and imported; where concepts genuinely differ, the names must visibly differ.
4. Mappings to external bodies of knowledge are explicit, versioned, scoped, and justified.
5. Migrated artifacts preserve provenance and their InfoTechCanon history.
6. Profiles constrain standards for concrete implementation contexts.
7. Artifacts are useful to both humans and agents.
8. Evolution preserves provenance, compatibility information, and rationale.
9. Integration with InfoTechCanon is uniform with the other domain canons, and the service surface is never duplicated.

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.

It also ships no service surface of its own — no CLI, HTTP API, or validation service. InfoTechCanon's service is the single place canons are inspected and validated, and SecurityCanon ties into it through the same canon-federation interface card mechanism that CommerceCanon and InterfaceCanon use. A check that does not exist yet is a change to InfoTechCanon's service, not a second service here.

Direction of travel

The repository should first promote the Mode of Authority draft into a checkable architecture-layer vocabulary with its orientation surfaces, publish its federation interface card declaring that vocabulary as an export, and publish the mapping that relates it to InfoTechCanon's access-control model and CARING.

Only then, and only where it demonstrably helps both canons, does content move. Stable promotion requires reviewed mappings and concrete consumer evidence.

Outcome

SecurityCanon is a coherent architecture-layer security vocabulary that InfoTechCanon references: Mode of Authority published as a checkable artifact with declared imports, a federation interface card declaring it as an export, orientation surfaces that let a reader or agent find the right term, and a mapping that relates it cleanly to InfoTechCanon's access-control model and CARING — with InfoTechCanon left more practical than before, not less.

Invariants

• InfoTechCanon remains valid and remains practical: make check passes and its validation reports zero errors, and no change here makes working in InfoTechCanon harder.
• Any migrated artifact keeps its provenance and its InfoTechCanon history; a move is a move with recorded lineage, never 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.
• No word means one thing here and a different thing in InfoTechCanon.
• Integration stays uniform with CommerceCanon and InterfaceCanon; no service surface is duplicated.
• 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, by the same mechanism the other canons use.
2. Mode of Authority promoted into a checkable artifact with machine-readable modes and dimensions, and its open questions on CONSTRUCT-versus-GOVERN and substrate authority answered.
3. A published mapping relating the vocabulary to InfoTechCanon's access-control model and CARING, with no term colliding across the two canons.
4. Orientation surfaces present: the vocabulary card, the design heuristic as the entry point, and the role/plane/mode disambiguation page.
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 vocabulary is abandoned or absorbed upstream. On success this repository does not retire — it becomes a standing canon and its project flavor is reconsidered, as CommerceCanon and InterfaceCanon were.