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
2 KiB
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, 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.