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](docs/adr-001-securitycanon-boundary.md),
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.