security-canon/docs/adr-001-securitycanon-boundary.md

---
id: SEC-ADR-001
decision_record: SECURITY-DEC-2026-001
type: adr
title: "SecurityCanon boundary: abstraction layers, not content extraction"
repo: security-canon
status: accepted
decided: "2026-09-20"
decided_by: repository owner
supersedes_assumption: "SECURITY-WP-0001 as originally drafted"
---

# SEC-ADR-001 — SecurityCanon boundary

Owner decision of 2026-09-20, answering questions 1, 2, 4 and 5 of the
[Mode of Authority assessment](../history/260920-mode-of-authority-and-canon-structure.md).
Question 3 remains open and is treated in §6.

## Context

SecurityCanon was bootstrapped on the assumption that it is a destination for
IT-security material extracted from InfoTechCanon. Reviewing
`ModeOfAuthorityCanon-v0.1.md` showed that assumption was incomplete: the draft
is a native contribution, and it collides on terminology with InfoTechCanon's
CARING standard. Four questions were put to the owner.

## Decision

### D1 — CARING stays in InfoTechCanon

CARING is not migrated. It imports eleven InfoTechCanon models, and moving it
would cost more than it returns.

The governing principle the owner stated:

> SecurityCanon should help, not hinder, keeping InfoTechCanon practical.

Content migration is therefore **not urgent and not a goal in itself**. An
artifact moves only when moving it makes both canons more practical, and the
burden of proof is on the move.

### D2 — Auth Mode and CARING are different layers of abstraction

Mode of Authority is about **architecture**. CARING is about **implementation**.

| | Mode of Authority | CARING |
| --- | --- | --- |
| Question | In what relationship to a system is authority exercised? | How is this access-control implementation actually composed? |
| Layer | architecture / design reasoning | implementation analysis and governance |
| Use | describing intent before a system exists | describing and prescribing systems that exist |
| Home | SecurityCanon | InfoTechCanon |

They are not competitors and neither subsumes the other. The assessment's
"dimension collision" is therefore **not resolved by merging** but by keeping the
layers distinct.

**Direct terminology overlap must nonetheless be avoided.** Two different layers
may legitimately need related concepts, but they must not use the same word for
different things, nor silently define the same thing twice. The rule:

1. Where a concept is genuinely shared (Scope, Subject), one canon defines it and
   the other imports it. InfoTechCanon owns the shared roots, so shared concepts
   are defined there.
2. Where the concepts are genuinely different, the names must be visibly
   different. `Operator` (CARING lifecycle role) and `OPERATE` (auth mode) are
   the clearest offender and need explicit disambiguation, not renaming by
   reflex.
3. Where one layer refines the other — MoA's Actor/Subject split against
   CARING's single Subject — the relationship is recorded as a mapping, not a
   redefinition. See §6.

### D3 — Identity is a shared root and stays in InfoTechCanon

Pulling identity into SecurityCanon would collapse too much into security.
Identity reaches into personhood and its philosophical underpinnings, which are
not security concerns.

A dedicated identity or personhood canon may eventually be right. That is
explicitly **deferred**, not rejected, and is not in scope for any current
workplan.

SecurityCanon imports identity concepts from InfoTechCanon. MoA's Principal Type
dimension is a security-side classification that references those concepts; it
does not define identity.

### D4 — No duplicated service surface

The requirement is **uniform integration**, not independent tooling:

> All the specific canons should integrate with InfoTechCanon properly and in
> the same way — commerce-canon, interface-canon, security-canon alike — and be
> referenced by InfoTechCanon in the same way.

Consequences:

- SecurityCanon ships **no** CLI, HTTP API, or validation service of its own.
- Integration uses the existing canon-federation interface card mechanism
  (`infospace/interfaces/federation.yaml`, schema owned by InfoTechCanon,
  authority `CUST-ADR-006`), exactly as CommerceCanon and InterfaceCanon do.
- InfoTechCanon's service surface is the single place canons are inspected and
  validated. If SecurityCanon needs a check that does not exist, the change
  belongs in InfoTechCanon's service, not in a second service here.
- Any divergence in how the three canons tie in is a defect to fix, not a local
  choice. Coordinate through prj-canon-federation.

## Consequences

**The repository's purpose changes shape.** SecurityCanon is an
architecture-layer vocabulary canon that InfoTechCanon references, not an
extraction destination. Its first deliverable is the Mode of Authority
vocabulary and its federation card — not a migration.

**SECURITY-WP-0001 is re-scoped.** The disposition review narrows from "what
moves" to "where does each concept belong, and what is imported". The migration
handoff task is cancelled; nothing currently justifies a migration workplan.

**InfoTechCanon is not destabilised.** No artifact is removed from it under this
decision, so the invariant that InfoTechCanon validates clean is satisfied
trivially rather than by careful slicing.

## Open — Q3, the Actor/Subject split

Not decided. The owner asked for review and discussion of the implications
before deciding whether MoA's Actor/Subject split should change CARING's single
Subject dimension.

Under D2 the question is narrower than it first appeared: because the two are
different layers, the split does not have to propagate. The live options are a
mapping at the boundary, an additive relation field in CARING, or an upstream
change to a release-candidate standard. This is carried by
`SECURITY-WP-0001-T07` and treated in
[the Actor/Subject implications note](260920-actor-subject-implications.md).