tegwick
1ac4f56783
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
52 lines
2 KiB
Markdown
52 lines
2 KiB
Markdown
# 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.
|