Bootstrap security-canon governance and extraction plan

Scaffold the repository to the repo-manager standard and establish its
governance surface: INTENT declaring the Taxonomy-layer claim and boundary
against NetKingdom, flex-auth, key-cape, OpenBao and whitehat-security; GOAL
with migration invariants and success gates; SCOPE listing the extraction
candidates and the unresolved boundary questions; AGENTS repo identity; repo
classification.

Add SECURITY-WP-0001 covering registration, the disposition review of
InfoTechCanon's security material, the reference-impact survey, the federation
interface card, and the handoff to a migration workplan. No canon content is
moved yet — the migration waits on the reviewed disposition.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AUkN13CAqtXWPXuEiEtmJj

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 36656@bnt-lap001
Assistant-Session: 66d6eece-d245-43ca-85e8-68a1b5970a67

.repo-classification.yaml

@@ -0,0 +1,11 @@
+repo_classification:
+  standard: Repo Classification Standard
+  version: '1.0'
+  classified_at: '2026-09-20'
+  classified_by: agent
+  category: project
+  domain: infotech
+  secondary_domains: []
+  capability_tags: [canon, security, access-governance, terminology, knowledge]
+  business_stake: [technology, product, operations]
+  business_mechanics: [coordination, operation]

AGENTS.md

@@ -0,0 +1,30 @@
+# Agent instructions — security-canon
+
+## Repo Identity
+
+**Purpose:** Orthogonal vocabulary and canonical model for security-related concepts, extending InfoTechCanon.
+
+**Domain:** infotech
+**Repo slug:** security-canon
+**Topic ID:** `fe2aaa78-9c20-4feb-b3d2-4fe0529572a3`
+**Workplan prefix:** `SECURITY-WP-`
+**Upstream canon:** info-tech-canon
+
+Orient: INTENT.md → GOAL.md → SCOPE.md → workplans/.
+
+
+## State Hub Integration
+
+<!-- BEGIN STATE-HUB-ACCESS -->
+| Context | URL |
+|---------|-----|
+| Local workstation | `http://127.0.0.1:8000` |
+| Remote (railiance01, in-cluster) | `http://10.43.68.154:8000` |
+| Optional local edge relay | `http://127.0.0.1:18080` |
+
+Do not instruct a remote agent to use `http://127.0.0.1:18000`. That reverse tunnel is retired; on railiance01 reach the hub at the in-cluster address above.
+<!-- END STATE-HUB-ACCESS -->
+
+## Cross-repo waits
+
+If blocked on another repo, look for a `prj-` driver workplan and follow `coordination-engine` `spec/cross-owner-wait-mode-v0.1.md`. Do not mint a stranded `wait`, implement `flavor: residual`, or message `ops-warden` for secrets.

GOAL.md

@@ -0,0 +1,49 @@
+---
+repo: security-canon
+repo_flavor: project
+project_status: draft
+started: "2026-09-20"
+---
+
+# Goal — security-canon
+
+## 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.

INTENT.md

@@ -0,0 +1,90 @@
+# 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.

README.md

@@ -1,3 +1,26 @@
 # security-canon
 
-Othogonal vocabulary and canonical model for security related concepts.
+Orthogonal vocabulary and canonical model for security-related concepts.
+
+SecurityCanon extends InfoTechCanon with a focused security domain model, in the
+same architectural role that [CommerceCanon](../commerce-canon) holds for
+commercial terminology and [InterfaceCanon](../interface-canon) for interface
+terminology. Its initial content is the IT-security material extracted from
+InfoTechCanon: the security, access control, and DevSecOps models, the CARING
+access governance standard, and the CARING Kubernetes RBAC benchmark.
+
+| | |
+| --- | --- |
+| **Flavor** | project |
+| **Domain** | infotech |
+| **Workplan prefix** | `SECURITY-WP-` |
+| **Upstream canon** | [InfoTechCanon](../info-tech-canon) |
+
+Start with [INTENT.md](INTENT.md), [GOAL.md](GOAL.md), and [SCOPE.md](SCOPE.md).
+Agent instructions are in [AGENTS.md](AGENTS.md); active work is in
+[workplans/](workplans/).
+
+## Status
+
+Bootstrap. The repository is registered and governed, but holds no migrated
+canon content yet. See [SECURITY-WP-0001](workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md).

SCOPE.md

@@ -0,0 +1,52 @@
+# SCOPE
+
+Reviewed: 2026-09-20 (Europe/Berlin).
+
+## Current repository scope
+
+Bootstrap. The repository carries governance files — INTENT, GOAL, SCOPE,
+AGENTS, repo classification — and one active workplan. It holds no canon
+content and no service code yet.
+
+## Ownership and boundaries
+
+Following [INTENT.md](INTENT.md), SecurityCanon occupies the Taxonomy layer and
+owns security concept definitions and their cross-canon mappings. It imports
+shared roots from InfoTechCanon and does not redefine them.
+
+Out of scope, with the owner named:
+
+- security architecture and standards of record for the estate — NetKingdom
+- authorization decisions — flex-auth
+- login, OIDC, MFA — key-cape / Keycloak
+- secret custody and credential issuance — OpenBao, ops-warden
+- adversarial evidence and findings practice — whitehat-security
+- shared artifact/ownership/mapping/profile mechanisms — InfoTechCanon
+- consumer runtime state, enforcement, observation, and adoption evidence — the consumers
+
+## Planned scope
+
+The extraction candidates in InfoTechCanon, pending the disposition review in
+`SECURITY-WP-0001-T02`:
+
+| Source path in info-tech-canon | Kind |
+| --- | --- |
+| `infospace/models/security/` | model |
+| `infospace/models/access-control/` | model |
+| `infospace/models/devsecops/` | model |
+| `infospace/standards/caring/` | standard |
+| `infospace/standards/caring/benchmarks/kubernetes-rbac/` | benchmark |
+
+Open boundary questions the disposition review must answer, not assume:
+
+- whether `infospace/models/identity/` is security terminology or a shared root
+  that stays in InfoTechCanon;
+- how the small-saas profile's security artifacts (policy, control, evidence,
+  incident) split between the two canons;
+- which InfoTechCanon concepts become declared imports rather than moves.
+
+## Exclusions and evolution
+
+No service surface, CLI, HTTP API, or validation tooling is in scope until the
+canon content exists and a demand for them is recorded. Whether SecurityCanon
+reuses InfoTechCanon's Python service or ships its own is deferred.

workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md

@@ -0,0 +1,104 @@
+---
+id: SECURITY-WP-0001
+type: workplan
+title: "Bootstrap security-canon and plan the InfoTechCanon security extraction"
+domain: infotech
+repo: security-canon
+status: active
+owner: claude
+topic_slug: security-canon
+created: "2026-09-20"
+updated: "2026-09-20"
+---
+
+# Bootstrap and extraction plan
+
+The repository owner asked on 2026-09-20 to refine InfoTechCanon by moving its
+IT-security material into a dedicated canon. This workplan establishes
+SecurityCanon as a governed, registered repository and produces the reviewed
+disposition that the migration itself will follow.
+
+Scope is bootstrap and planning. The migration of artifacts is deliberately not
+in this workplan: it depends on the disposition review in T02 and gets its own
+workplan once the boundary is settled. See [INTENT.md](../INTENT.md) for the
+layer claim and [GOAL.md](../GOAL.md) for the success gates.
+
+## Establish repository governance and registration
+
+```task
+id: SECURITY-WP-0001-T01
+status: done
+priority: high
+```
+
+Clone the Forgejo stub to the workstation, scaffold the repository to the
+repo-manager standard, and write the governance files: INTENT, GOAL, SCOPE,
+AGENTS with repo identity, README, and repo classification. Register the
+repository and this workplan in the State Hub by committing the files and
+running `statehub fix-consistency` — never by hand.
+
+## Disposition review of InfoTechCanon security material
+
+```task
+id: SECURITY-WP-0001-T02
+status: todo
+priority: high
+```
+
+Produce a reviewed disposition record naming, for every security artifact in
+InfoTechCanon, whether it moves to SecurityCanon, stays, or splits — with
+rationale and the resulting import declarations. Candidates are the security,
+access control, and DevSecOps models, the CARING access governance standard, and
+its Kubernetes RBAC benchmark.
+
+Resolve the open boundary questions rather than assuming them: whether the
+identity model is security terminology or a shared root; how the small-saas
+profile's policy, control, evidence, and incident artifacts split; and which
+InfoTechCanon concepts become declared imports instead of moves. Record the
+answers as a decision, since they bind both canons.
+
+## Reference-impact survey
+
+```task
+id: SECURITY-WP-0001-T03
+status: todo
+priority: medium
+```
+
+Enumerate every inbound reference to the extraction candidates — InfoTechCanon
+relationships, indexes, generated views, agent briefs, profiles, evaluations,
+mappings, and its Python validation checks — plus references from other repos.
+The survey sizes the migration and is the checklist that keeps InfoTechCanon
+validating clean after each slice.
+
+## Federation interface card and reciprocal navigation
+
+```task
+id: SECURITY-WP-0001-T04
+status: todo
+priority: medium
+```
+
+Publish SecurityCanon's interface card with actual imports, available exports,
+source authority, maturity, and peer references, following the pattern
+CommerceCanon and InterfaceCanon established. Add reciprocal navigation with
+InfoTechCanon and pass the canon-federation validator. Coordinate with
+prj-canon-federation rather than amending federation governance here.
+
+## Migration workplan handoff
+
+```task
+id: SECURITY-WP-0001-T05
+status: wait
+priority: medium
+```
+
+With the disposition (T02) and reference survey (T03) reviewed, draft the
+migration workplan — slice order, provenance handling, and the per-slice
+validation gate for both canons. Waits on T02 and T03.
+
+## Out of scope
+
+No canon content is authored or moved under this workplan. No service surface,
+CLI, HTTP API, or validation tooling is built for SecurityCanon; whether it
+reuses InfoTechCanon's Python service is deferred until content exists.