coulomb/security-canon
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Close the bootstrap and vocabulary workplan

Browse source 
All tasks resolved: T01, T02, T03, T04, T06 and T07 done, T05 cancelled. The
workplan delivered the governed 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.

It also concluded that the migration it was preparing should not happen. The
material this canon was meant to receive is load-bearing where it sits, and
SecurityCanon's real contribution is an architecture-layer vocabulary that
InfoTechCanon does not have, so it is an extension canon rather than a
destination for extracted material. Nothing moves; the boundary holds by
declared imports, twelve InfoTechCanon concepts pinned and nine owned here.

SCOPE.md carries the three open questions to their answers rather than leaving
them carried, and points at the placement record and the survey.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
This commit is contained in:
tegwick 2026-09-20 22:48:23 +02:00
parent 2f22ddf7d3
commit eeb3e88af7
2 changed files with 54 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

20
SCOPE.md
View file

@ -53,14 +53,24 @@ InfoTechCanon artifacts this canon **references rather than absorbs**:
| `infospace/models/security/` | boundary under review in `SECURITY-WP-0001-T02` |
| `infospace/models/devsecops/` | boundary under review in `SECURITY-WP-0001-T02` |
Open questions, carried and not assumed:
Open questions, answered under SECURITY-WP-0001 and no longer carried:
- whether the security and DevSecOps models are better placed here or upstream —
the only remaining migration candidates, and neither is urgent;
- how the small-saas profile's security artifacts relate to this canon;
- the security and DevSecOps models stay in InfoTechCanon. Both were the only
remaining migration candidates and neither cleared the bar of demonstrably
helping both canons (SECURITY-DEC-2026-003);
- the small-saas profile's security artifacts stay whole in InfoTechCanon. A
SecurityCanon example references them by id across the federation interface
rather than relocating them;
- the Actor/Subject naming question, analysed in
[the implications note](docs/260920-actor-subject-implications.md) and decided
under `SECURITY-WP-0001-T07`.
under `SECURITY-WP-0001-T07`: the on-behalf-of dimension is `AuthorityContext`
and no upstream concept is redefined.
Concept placement across the boundary — one owning canon and one import
direction per shared concept — is recorded in
[concept-placement.md](infospace/interfaces/concept-placement.md), with the
supporting survey of InfoTechCanon's existing authority vocabulary in
[infotechcanon-authority-survey.md](infospace/mappings/infotechcanon-authority-survey.md).
## Exclusions and evolution

40
workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md
View file

@ -4,7 +4,7 @@ type: workplan
title: "Bootstrap security-canon and establish the Mode of Authority vocabulary"
domain: infotech
repo: security-canon
status: active
status: finished
owner: claude
topic_slug: security-canon
created: "2026-09-20"
@ -332,3 +332,41 @@ 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.