Assess Mode of Authority canon and re-order SECURITY-WP-0001

Review of spec/ModeOfAuthorityCanon-v0.1.md, recorded as a timestamped
assessment in history/. Two findings change the plan.

SecurityCanon is not only a recipient of extracted InfoTechCanon material. The
Mode of Authority draft is a native contribution and is plausibly the organizing
spine of the canon, so the vocabulary has to be settled before artifacts are
migrated into it rather than after.

Mode of Authority and CARING independently invented overlapping dimensions.
Scope, Subject, Activation/Condition and Capability/Operations collide by name
while differing in meaning, and CARING's Operator role reads as a synonym for
the OPERATE auth mode without being one. Merging naively would produce a canon
that misleads.

Workplan adapted: T02 becomes a three-way reconciliation with a required
dimension-collision table, T04 must declare Mode of Authority as an export, T05
now waits on the vocabulary being settled, and two tasks are added — T06 to
promote the draft into a checkable Tier-1 artifact with its orientation
surfaces, T07 to resolve the collision as a recorded decision.

The assessment leaves five questions to the owner, including whether CARING
migrates at all and whether Mode of Authority is security terminology or
general information-systems terminology.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AUkN13CAqtXWPXuEiEtmJj

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 36656@bnt-lap001
Assistant-Session: 66d6eece-d245-43ca-85e8-68a1b5970a67

workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md

@@ -22,7 +22,17 @@ disposition that the migration itself will follow.
 Scope is bootstrap and planning. The migration of artifacts is deliberately not
 in this workplan: it depends on the disposition review in T02 and gets its own
 workplan once the boundary is settled. See [INTENT.md](../INTENT.md) for the
-layer claim and [INTENT.md](../INTENT.md) for the success gates.
+layer claim and the success gates.
+
+**Revised 2026-09-20** after reviewing `spec/ModeOfAuthorityCanon-v0.1.md`. The
+[Mode of Authority assessment](../history/260920-mode-of-authority-and-canon-structure.md)
+found that SecurityCanon is not only a recipient of extracted material: the Mode
+of Authority draft is a native contribution and is plausibly the organizing spine
+of the canon. It also found that Mode of Authority and CARING independently
+invented overlapping dimensions — Scope, Subject, Activation/Condition,
+Capability/Operations — that collide by name while differing in meaning.
+Consequently the vocabulary is settled *before* the migration, not after: T06 and
+T07 are new and precede T05.
 
 ## Establish repository governance and registration
 
@@ -54,6 +64,15 @@ rationale and the resulting import declarations. Candidates are the security,
 access control, and DevSecOps models, the CARING access governance standard, and
 its Kubernetes RBAC benchmark.
 
+The review is **three-way**, not two-way: it reconciles the Mode of Authority
+vocabulary, the InfoTechCanon access-control model, and CARING. Required output
+includes the dimension-collision table — one row per overlapping concept, naming
+the single surviving definition and its owning tier. Assessment section 3 holds
+the first draft of that table.
+
+Answer explicitly whether CARING migrates at all. It imports eleven InfoTechCanon
+models, so staying put and importing the vocabulary is a live option.
+
 Resolve the open boundary questions rather than assuming them: whether the
 identity model is security terminology or a shared root; how the small-saas
 profile's policy, control, evidence, and incident artifacts split; and which
@@ -86,7 +105,8 @@ state_hub_task_id: "a844ccdc-f75d-53b6-858e-c92f30aad7ce"
 
 Publish SecurityCanon's interface card with actual imports, available exports,
 source authority, maturity, and peer references, following the pattern
-CommerceCanon and InterfaceCanon established. Add reciprocal navigation with
+CommerceCanon and InterfaceCanon established. The card must declare Mode of
+Authority as a SecurityCanon **export**, not only InfoTechCanon imports. Add reciprocal navigation with
 InfoTechCanon and pass the canon-federation validator. Coordinate with
 prj-canon-federation rather than amending federation governance here.
 
@@ -99,9 +119,58 @@ priority: medium
 state_hub_task_id: "387bfae1-c7a1-5826-856e-f5364121f849"
 ```
 
-With the disposition (T02) and reference survey (T03) reviewed, draft the
-migration workplan — slice order, provenance handling, and the per-slice
-validation gate for both canons. Waits on T02 and T03.
+With the disposition (T02), reference survey (T03), vocabulary promotion (T06)
+and dimension decision (T07) settled, draft the migration workplan — slice order,
+provenance handling, and the per-slice validation gate for both canons.
+Migrating into an unsettled spine is the failure this ordering prevents.
+
+## Promote Mode of Authority into a canon artifact
+
+```task
+id: SECURITY-WP-0001-T06
+status: todo
+priority: high
+```
+
+Turn the v0.1 research draft into a checkable Tier-1 vocabulary artifact:
+frontmatter with artifact id, namespace and `owned_concepts`; machine-readable
+files for the seven auth modes and the supporting dimensions; and the three
+orientation surfaces the assessment names — the one-page vocabulary card, the
+ten-question design heuristic promoted to the front door, and the
+role/plane/mode disambiguation page.
+
+Move the draft verbatim to `research/260920-mode-of-authority-v0.1.md` as
+provenance. It currently sits in `spec/`, which the Repository Layout Standard
+reserves for implementation guidance; a self-declared research draft belongs in
+`research/` until promoted.
+
+Close the two open questions that block stability: Q2, whether CONSTRUCT is
+always distinct from GOVERN under policy-as-code, and Q3, how substrate
+authority is represented. Purpose and Time appear in the Access Situation tuple
+without sections; resolve Purpose as an import from InfoTechCanon's PURPOSES
+extension rather than defining it here.
+
+## Decide the dimension collision
+
+```task
+id: SECURITY-WP-0001-T07
+status: todo
+priority: high
+```
+
+Record a decision — not a task note — resolving each overlapping dimension to
+one definition in one tier, because the outcome binds both canons. At minimum:
+Scope, Subject versus the Actor/Subject split, Activation versus CARING
+Condition, Capability versus AccessOperations, Build Plane versus CONSTRUCT,
+Audit Plane versus Evidence Boundary, and the `Operator` role versus the
+`OPERATE` mode.
+
+Also decide the prior question the assessment raises: whether Mode of Authority
+is security terminology owned here, or general information-systems terminology
+that belongs in InfoTechCanon with SecurityCanon consuming it.
+
+Reserve namespaces as part of the decision. CARING currently owns `itc-caring:`,
+which must be rewritten rather than aliased if it migrates.
 
 ## Out of scope