---
id: SECURITY-WP-0001
type: workplan
title: "Bootstrap security-canon and establish the Mode of Authority vocabulary"
domain: infotech
repo: security-canon
status: finished
owner: claude
topic_slug: security-canon
created: "2026-09-20"
updated: "2026-09-20"
state_hub_workstream_id: "72c0e8f7-c904-59bd-9a7f-55d6de8ac715"
---

# Bootstrap and extraction plan

The repository owner asked on 2026-09-20 to refine InfoTechCanon by moving its
IT-security material into a dedicated canon. This workplan establishes
SecurityCanon as a governed, registered repository and produces the reviewed
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 the success gates.

**Revised twice on 2026-09-20.** First 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.
Then again after the owner's decision, recorded as
[SEC-ADR-001](../docs/adr-001-securitycanon-boundary.md): CARING stays in
InfoTechCanon, identity stays a shared root, Mode of Authority is architecture
while CARING is implementation, and no service surface is duplicated.

**Content migration is no longer a goal of this workplan.** SecurityCanon's
deliverable is the architecture-layer vocabulary and its clean integration; an
artifact moves only where moving it makes both canons more practical. T05 is
cancelled accordingly.

## Establish repository governance and registration

```task
id: SECURITY-WP-0001-T01
status: done
priority: high
state_hub_task_id: "9eabbe55-3529-5821-a248-d05c57a3556f"
```

Clone the Forgejo stub to the workstation, scaffold the repository to the
repo-manager standard, and write the governance files: INTENT, GOAL, SCOPE,
AGENTS with repo identity, README, and repo classification. Register the
repository and this workplan in the State Hub by committing the files and
running `statehub fix-consistency` — never by hand.

## Boundary and terminology review

```task
id: SECURITY-WP-0001-T02
status: done
priority: high
state_hub_task_id: "8b9e4cd0-9905-5ae8-9a23-8957110d72e4"
```

Narrowed by SEC-ADR-001, which already settles CARING, identity and the
access-control model as staying in InfoTechCanon. What remains is to establish,
for each concept rather than each file, **where it belongs and what is imported**.

Required output is the concept-placement table: one row per concept that appears
in both layers, naming the single owning canon and the import direction.
Assessment section 3 holds the first draft.

Two artifacts are still genuinely open and are the only remaining migration
candidates: the security model and the DevSecOps model. Neither is urgent.
Recommend for each, with rationale, and default to leaving it upstream unless
moving it demonstrably helps both canons.

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
InfoTechCanon concepts become declared imports instead of moves. Record the
answers as a decision, since they bind both canons.

## Reference-impact survey

```task
id: SECURITY-WP-0001-T03
status: done
priority: medium
state_hub_task_id: "dd8bc579-6a89-5b77-bfd8-3acdb4a4f472"
```

Enumerate where InfoTechCanon already speaks about authority — the access-control
model, CARING, the security and DevSecOps models, profiles, evaluations and the
generated surfaces — so the vocabulary is published against what exists rather
than beside it. With migration off the table this is a survey for correct
referencing and non-collision, not a migration sizing exercise.

## Federation interface card and reciprocal navigation

```task
id: SECURITY-WP-0001-T04
status: done
priority: medium
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. 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.

## Migration workplan handoff — cancelled

```task
id: SECURITY-WP-0001-T05
status: cancel
priority: medium
state_hub_task_id: "387bfae1-c7a1-5826-856e-f5364121f849"
```

Cancelled by SEC-ADR-001. With CARING, identity and the access-control model
staying in InfoTechCanon, there is no migration large enough to need its own
workplan. If T02 later recommends moving the security or DevSecOps model, that is
a bounded change handled under a new task, not a migration programme.

## Promote Mode of Authority into a canon artifact

```task
id: SECURITY-WP-0001-T06
status: done
priority: high
state_hub_task_id: "de5fc42c-2e18-5f03-b86c-a5ad45a9bb0a"
```

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.

Publish the three-way mapping table relating the vocabulary to InfoTechCanon's
access-control model and CARING — section 5 of the
[Actor/Subject implications note](../docs/260920-actor-subject-implications.md)
holds the first draft.

Close the two open questions that block stability: whether CONSTRUCT is always
distinct from GOVERN under policy-as-code, and 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 terminology separation

```task
id: SECURITY-WP-0001-T07
status: done
priority: high
state_hub_task_id: "4a0d3df9-d8a2-51c4-a4bc-72488d866068"
```

SEC-ADR-001 D2 settles the principle — the two are different layers of
abstraction and must not share a word for different things. This task applies it
concretely and records the result as a decision, because it binds both canons.

The unavoidable case is **Actor/Subject**. InfoTechCanon's access-control model
already owns both words and binds them as "Subject is the access-control view of
an actor"; Mode of Authority uses the same two words for two distinct parties.
The [implications note](../docs/260920-actor-subject-implications.md) analyses
this and recommends renaming MoA's second party to `Authority Context`. Decide
it, and answer the owner's request to discuss what follows for CARING §32.

Also resolve, in the same decision: `Operator` role versus `OPERATE` mode,
Activation versus CARING Condition, Capability versus AccessOperations, Build
Plane versus CONSTRUCT, and Audit Plane versus Evidence Boundary — in each case
by separating names or declaring an import, never by redefining upstream.

Reserve the `sec-authority:` namespace for the vocabulary. `itc-caring:` stays
with InfoTechCanon.

## Out of scope

No canon content is authored or moved under this workplan. No service surface,
CLI, HTTP API, or validation tooling is built for SecurityCanon; whether it
reuses InfoTechCanon's Python service is deferred until content exists.

## Result — 2026-09-20 (T06, T07)

Mode of Authority promoted to
[`sec-authority:ModeOfAuthority`](../infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md)
v0.2.0, with machine-readable [`auth-modes.yaml`](../infospace/vocabulary/mode-of-authority/auth-modes.yaml)
and [`dimensions.yaml`](../infospace/vocabulary/mode-of-authority/dimensions.yaml).
The v0.1 draft moved verbatim to
[`research/260920-mode-of-authority-v0.1.md`](../research/260920-mode-of-authority-v0.1.md)
as provenance; it had been sitting in `spec/`, which the Repository Layout
Standard reserves for implementation guidance.

Orientation surfaces published: the [vocabulary card](../docs/vocabulary-card.md),
the ten-question design heuristic promoted to §3 of the artifact, and the
[role/plane/mode disambiguation page](../docs/disambiguation.md). The cross-layer
[mapping](../infospace/mappings/mode-of-authority-to-infotechcanon.md) records
entity and dimension correspondences, mode-to-plane and mode-to-role affinities,
and the import direction.

Terminology separation decided as
[SECURITY-DEC-2026-002 / SEC-ADR-002](../docs/adr-002-terminology-separation.md):
`Subject` becomes `AuthorityContext`; `Operator`/`OPERATE`, Build Plane/`CONSTRUCT`,
Policy Plane/`GOVERN`, Audit Plane/`EvidenceBoundary` and Condition/`Activation`
are separated rather than merged; Scope, AccessOperations, Purpose and
PrincipalType are declared imports; namespace `sec-authority:` reserved.

Two v0.1 open questions closed in the artifact §10. CONSTRUCT stays distinct from
GOVERN, with the test being the object of authority — the artifact versus the
constraint it must satisfy — so that "who may edit the policy" and "who decides
what it must say" remain separable. Substrate authority is modelled as a
`DOMINATES` relation between Authority Realms carrying `dominance_kind`,
`observable` and `evidence_boundary`, which makes A5 checkable. Q1 and Q4–Q7
remain open.

Generalising CARING §32 beyond non-human subjects was deliberately **not** bundled
in; it is InfoTechCanon's to accept as a demand signal.

## Result — 2026-09-20 (T04)

[Federation interface card](../infospace/interfaces/federation.yaml) published at
version 0.1.0, validating against InfoTechCanon's `interface-card.schema.yaml`.
It declares one export surface, `sec-authority`, carrying the Mode of Authority
vocabulary and its machine-readable catalogs, and names InfoTechCanon,
InterfaceCanon, CommerceCanon and the Custodian as peers under CUST-ADR-006.

Imports are pinned in
[`imports.json`](../infospace/vocabulary/mode-of-authority/imports.json) against
InfoTechCanon `e1f98da0`, recording the path and SHA-256 of each source. All five
hashes were verified to match Git blobs at that commit with the sources unchanged
in the review checkout.

Reciprocal navigation runs both ways: this repository's
[interfaces README](../infospace/interfaces/README.md) links the peer cards, and
InfoTechCanon carries the
[SecurityCanon boundary review](../../info-tech-canon/infospace/interfaces/security-canon-boundary.md)
with its own README link, following the InterfaceCanon precedent.

Evidence. The prj-canon-federation G7 validator passes — three cards, six
reciprocal peer links, 33 navigation links checked, no upstream changes since
review. InfoTechCanon `make check` passes with 46 tests, clean validation and a
passing small-saas profile after refreshing the generated indexes for the added
file. No InfoTechCanon concept was transferred or removed. None of the seven
concepts this canon declares appears in any InfoTechCanon `owned_concepts`
declaration, so there is no ownership conflict.

Limits. The G7 validator pins card paths for info-tech-canon, commerce-canon and
the-custodian only, so this card is written to the same contract but is not yet
registered there; adding it is prj-canon-federation's change to make, and the
card records that. The boundary acceptance is an agent review, not human
sign-off, and records no consumer adoption or conformance claim.

## Result — 2026-09-20 (T02)

Concept placement decided and recorded as SECURITY-DEC-2026-003 in
`decisions/decisions.md`, with the full record at
`infospace/interfaces/concept-placement.md`.

The placement table carries 25 rows: 10 InfoTechCanon concepts declared as
imports (Artifact, Ownership, Relationship, Actor, Subject, Principal,
PrincipalType, Scope, AccessOperations, Purpose), 5 InfoTechCanon CARING and
capability concepts that stay upstream with no SecurityCanon counterpart
(Canonical Role, Plane, Condition, Capability, Audit Plane), and 9 SecurityCanon
concepts (AuthMode, AuthorityContext, AuthorityRealm, AuthorityProvenance,
Activation, EvidenceBoundary, AccessSituation, Environment, Time). The declared
import list is closed at what `imports.json` pins; further needs must be added
there with a blob hash before use.

Both remaining migration candidates stay upstream. The security model is a
posture model of the shared spine with eleven upstream imports and no semantic
gain from moving; the DevSecOps model is delivery vocabulary that is only
incidentally security-flavoured and sits beside the repository-layout standard
and the evidence model. No artifact migrates, consistent with T05 having been
cancelled.

The open boundary questions are answered rather than assumed: the identity model
is a shared root (SecurityCanon imports PrincipalType only); the small-saas
policy, control, evidence and incident artifacts do not split and stay whole,
with any SecurityCanon example referencing them by id across the federation
interface; declared imports replace moves in both directions.

Two residuals are recorded, both InfoTechCanon-internal and neither made here:
R-1, CARING `Scope` and ITC-ACCESS `Scope` are two definitions of one concept
and ITC-ACCESS is named the owner; R-2, the CARING section 32 generalisation
remains an unaccepted InfoTechCanon proposal.

Limits. This is an agent decision recorded on the SecurityCanon side and
reflected in InfoTechCanon's accepted boundary; it is not separate human
sign-off, and it records no consumer adoption or conformance claim.

## Result — 2026-09-20 (T03)

Survey at `infospace/mappings/infotechcanon-authority-survey.md`, against
info-tech-canon `e1f98da`. Fifty-two InfoTechCanon files mention authority, of
which twenty are live canon and thirty-two are preserved assimilation source.

The survey separates three senses of the word already in use: a right held by an
actor (`itc-org:Authority`, ITC-ORG 10.17), an external body compelling
disclosure (CARING 10.7 exposure mode), and the relationship in which authority
is exercised (`sec-authority:AuthMode`). Sense C qualifies sense A and subsumes
nothing.

Four findings. F-1: `itc-org:Authority` is a live concept that no
`owned_concepts` declaration lists, so the boundary review's conflict check
could not see it — no collision, but three SecurityCanon concepts sit adjacent
to it, and it is now a declared import on the existing organization-model entry
with its pinned hash unchanged. F-3: `Environment` was defined in both canons,
which SECURITY-DEC-2026-003 forbids; InfoTechCanon owns it via CARING 21.5,
SecurityCanon imports it, and the `RECOVERY` value is carried as an upstream
value proposal. F-2 and F-4 need no change here: CARING's Authority exposure
mode against `itc-org:Authority` becomes residual R-3, and `itc-ident:Realm`
against `AuthorityRealm` owes the disambiguation page a line but no rename.
AuthorityContext, AuthorityProvenance, Activation, EvidenceBoundary and
AccessSituation collide with nothing in the live corpus.

The two amendments are applied to the placement table and to `imports.json`
through the procedure SECURITY-DEC-2026-003 requires, taking the declared import
list from ten concepts to twelve. No InfoTechCanon file is changed by this
survey; R-3 is InfoTechCanon-internal work.

## Closure — 2026-09-20

All tasks are resolved: T01, T02, T03, T04, T06 and T07 done, T05 cancelled.

The workplan set out to establish SecurityCanon as a governed repository and to
produce the reviewed disposition that a migration would follow. It delivered the
repository, the Mode of Authority vocabulary at v0.2.0, the federation interface
card, three decisions, the concept-placement record and the reference-impact
survey — and it concluded that the migration it was preparing should not happen.
Nothing moves. The boundary holds by declared imports in both directions, twelve
InfoTechCanon concepts pinned in `imports.json` and nine concepts owned here.

That is a change of premise worth stating plainly. The repository owner asked on
2026-09-20 to refine InfoTechCanon by moving its IT-security material into a
dedicated canon. The review found that the material is load-bearing where it
sits — CARING imports eleven upstream models, the security model is a posture
model of the shared spine, the DevSecOps model belongs beside the
repository-layout standard — and that SecurityCanon's real contribution is an
architecture-layer vocabulary that InfoTechCanon does not have. SecurityCanon is
therefore an extension canon, not a destination for extracted material. T05, the
migration handoff, was cancelled rather than deferred.

Two corrections were made against this workplan's own earlier output rather than
being left to stand: `itc-org:Authority` and `Environment` were missing from the
placement table, and `Scope` was attributed to the wrong owner. Both were fixed
through the amendment procedure SECURITY-DEC-2026-003 requires.

Residuals handed to InfoTechCanon: R-1 is resolved there
(ADHOC-2026-09-20-T01); R-2, the CARING section 32 generalisation, and R-3, the
two senses of Authority inside InfoTechCanon, remain open and are that
repository's to decide. A follow-up worth its own workplan: the `owned_concepts`
conflict check cannot see a concept that is live and referenced by qualified id
but undeclared, which is how F-1 escaped the boundary review.

Limits. Everything recorded here is agent review, not human sign-off, and
records no consumer adoption or conformance claim. The G7 validator in
`prj-canon-federation` still does not pin the security-canon card.