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