security-canon/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
SECURITY-WP-0001	workplan	Bootstrap security-canon and establish the Mode of Authority vocabulary	infotech	security-canon	finished	claude	security-canon	2026-09-20	2026-09-20	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 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 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: 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

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

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

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

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

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

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

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 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 v0.2.0, with machine-readable auth-modes.yaml and dimensions.yaml. The v0.1 draft moved verbatim to 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, the ten-question design heuristic promoted to §3 of the artifact, and the role/plane/mode disambiguation page. The cross-layer mapping 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: 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 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 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 links the peer cards, and InfoTechCanon carries the SecurityCanon boundary review 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.