# SCOPE

Reviewed: 2026-09-20 (Europe/Berlin), after [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md).

## Current repository scope

Bootstrap. The repository carries governance files — INTENT, SCOPE, AGENTS,
repo classification — the [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md)
boundary decision, the Mode of Authority review in `history/`, and one active
workplan. The only content is the Mode of Authority v0.1 research draft, not yet
promoted into a canon artifact. There is no service code, and by decision there
will be none.

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

- the CARING access governance standard and its Kubernetes RBAC benchmark,
  the access-control model, and the identity model — **InfoTechCanon**, by
  SEC-ADR-001 D1 and D3
- any CLI, HTTP API, or validation service — **InfoTechCanon's service surface**,
  by SEC-ADR-001 D4; integration is via the canon-federation interface card
- 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 near-term deliverable is the architecture-layer vocabulary, not a migration.

| Deliverable | Task |
| --- | --- |
| Mode of Authority promoted to a checkable Tier-1 artifact | `SECURITY-WP-0001-T06` |
| Terminology separation from CARING and the access-control model | `SECURITY-WP-0001-T07` |
| Federation interface card declaring Auth Mode as an export | `SECURITY-WP-0001-T04` |
| Orientation surfaces: vocabulary card, design heuristic, disambiguation page | `SECURITY-WP-0001-T06` |

InfoTechCanon artifacts this canon **references rather than absorbs**:

| Path in info-tech-canon | Relationship |
| --- | --- |
| `infospace/standards/caring/` | implementation layer; imports the vocabulary |
| `infospace/models/access-control/` | owns Subject, Principal, IdentityReference |
| `infospace/models/identity/` | shared root; stays upstream |
| `infospace/models/security/` | boundary under review in `SECURITY-WP-0001-T02` |
| `infospace/models/devsecops/` | boundary under review in `SECURITY-WP-0001-T02` |

Open questions, answered under SECURITY-WP-0001 and no longer carried:

- the security and DevSecOps models stay in InfoTechCanon. Both were the only
  remaining migration candidates and neither cleared the bar of demonstrably
  helping both canons (SECURITY-DEC-2026-003);
- the small-saas profile's security artifacts stay whole in InfoTechCanon. A
  SecurityCanon example references them by id across the federation interface
  rather than relocating them;
- the Actor/Subject naming question, analysed in
  [the implications note](docs/260920-actor-subject-implications.md) and decided
  under `SECURITY-WP-0001-T07`: the on-behalf-of dimension is `AuthorityContext`
  and no upstream concept is redefined.

Concept placement across the boundary — one owning canon and one import
direction per shared concept — is recorded in
[concept-placement.md](infospace/interfaces/concept-placement.md), with the
supporting survey of InfoTechCanon's existing authority vocabulary in
[infotechcanon-authority-survey.md](infospace/mappings/infotechcanon-authority-survey.md).

## Exclusions and evolution

No service surface is in scope, now or later: SEC-ADR-001 D4 settles that
SecurityCanon reuses InfoTechCanon's service rather than shipping its own. A
check that does not exist is a change request against InfoTechCanon.

A dedicated identity or personhood canon may eventually be right. It is deferred
and belongs to no current workplan.