# 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.