# SCOPE

Reviewed: 2026-10-03 (Europe/Berlin), following the completed vocabulary work and [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md).

## Current repository scope

The repository publishes Mode of Authority draft 0.2.0 vocabulary artifacts,
mode/dimension catalogs, declared imports, a federation interface, cross-canon
mappings and orientation surfaces. SECURITY-WP-0001 is finished. The retained
v0.1 research draft is historical, not the current orientation artifact. There
is no service code; SEC-ADR-001 keeps validation in InfoTechCanon's service.

It also publishes the DevOps Secrets Management Standard (`SEC-DSM` 1.0.0) at
`infospace/standards/devops-secrets-management/`. That standard states the
normative secrets-management practice. It does not operate custody, issue
credentials, or decide authorization. SECURITY-WP-0002 records the insertion.

## 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 — access-engine (runtime/product flex-auth)
- login, OIDC, MFA — key-cape / Keycloak
- credential custody and issuance — secrets-engine over OpenBao; operational
  routing and SSH certificates — ops-warden. The practice those systems follow
  is this canon's DevOps Secrets Management Standard; the operation stays theirs
- 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` |
| DevOps Secrets Management Standard (`SEC-DSM` 1.0.0) | `SECURITY-WP-0002` |

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.