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

id	decision_record	type	title	repo	status	decided	decided_by	supersedes_assumption
SEC-ADR-001	SECURITY-DEC-2026-001	adr	SecurityCanon boundary: abstraction layers, not content extraction	security-canon	accepted	2026-09-20	repository owner	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. 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.