info-tech-canon/workplans/INFO-WP-0027-concept-declaration-coverage.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	flavor	state_hub_workstream_id
INFO-WP-0027	workplan	Close the concept-declaration gap so ownership conflicts are detectable	infotech	info-tech-canon	proposed	claude	canon-federation	2026-09-20	2026-09-20	quality	9df4bb6f-b420-597d-acda-5dc39f00c095

Concept declaration coverage

Why

concept_ownership() in src/info_tech_canon/generation.py builds the ownership index from exactly two sources: each artifact's title, and its owned_concepts frontmatter. A concept that is defined in prose, is referenced elsewhere by qualified id, and is treated by the corpus as owned is invisible to it. concept_ownership_conflict in src/info_tech_canon/service.py can only fire on what that index contains, so the conflict check covers a minority of the concepts the canon actually defines.

Measured on the working tree at 209bb5a:

• the ownership index holds 164 entries — 81 from artifact titles, 83 from owned_concepts frontmatter;
• 12 live models and standards declare nothing at all: access-control, data, devsecops, governance, information-space, landscape, network, observability, security, task, tagging, and the kernel map;
• a single bold-definition pattern (**Name** is|—) finds 519 defined terms across 15 live artifacts that appear in no declaration. That pattern is a lower bound, not a census: it misses numbered-section definitions and table-defined terms.

This is not theoretical. The SecurityCanon boundary review (infospace/interfaces/security-canon-boundary.md) checked SecurityCanon's seven declared concepts against every InfoTechCanon owned_concepts declaration, found no conflict, and recorded that as evidence. It could not have found itc-org:Authority — defined at ITC-ORG section 10.17, assigned to Organization by the kernel map, and referenced by qualified id in the governance model — because ITC-ORG's frontmatter does not list it. The gap was caught by hand in SECURITY-WP-0001-T03 (finding F-1) and would otherwise have shipped as a false clean result.

SCOPE.md already concedes that the calculation "does not establish ownership of every concept in prose". This workplan converts that concession into a measured number and closes the part of it that matters for federation.

What this is not

Not a complete ontology, and not automated concept extraction promoted to canon. Extraction produces candidates for review; a concept becomes owned because a human or a reviewed change declares it, never because a regex found it. No concept is renamed, moved or removed by this workplan.

Establish the true denominator

id: INFO-WP-0027-T01
status: todo
priority: high
state_hub_task_id: "1e139d9a-8883-59af-a163-1c6da903dad6"

Write a candidate extractor over live artifacts (excluding assimilation/ and seeds/, which preserve source rather than define canon). Cover at least the bold-definition form, the numbered-section-heading form used by ITC-ORG section 10.17 and ITC-IDENT section 2.10, and terms defined in a table's first column.

Output is a review report under history/, listing per artifact: declared concepts, extracted candidates, and the difference. No corpus change and no frontmatter edit in this task. The report is the input to T02 and the baseline the coverage check in T03 measures against.

Declare concepts for the twelve silent artifacts

id: INFO-WP-0027-T02
status: todo
priority: high
state_hub_task_id: "b086abf1-3b36-5b05-a8a8-c8b12c9ab280"

Add reviewed owned_concepts frontmatter to the twelve live artifacts that declare none, working from the T01 candidates rather than from the regex output directly. Each declared concept must be one the artifact genuinely defines, not one it merely mentions or imports.

Order by federation exposure, not by file size: access-control, security, devsecops and governance first, since those are the surfaces SecurityCanon, InterfaceCanon and the small-saas profile reference. The kernel map is a different case and may end up declaring nothing — it assigns concepts to owners rather than defining them, and that judgment should be recorded either way.

Expect this task to surface genuine conflicts once the index grows. A conflict found here is the workplan working, not a regression; resolve each by naming one owner, as ADHOC-2026-09-20-T01 did for Scope.

Report coverage instead of asserting completeness

id: INFO-WP-0027-T03
status: todo
priority: medium
state_hub_task_id: "48dbd089-a0bf-5d02-b574-b1acf554f658"

Extend the validation coverage report added by INFO-WP-0019 with a concept-declaration coverage metric: per artifact, declared concepts against extracted candidates, and a corpus total. Wire the extractor from T01 in as the measurement, so the number moves when the corpus does.

Decide and record the enforcement level. The recommendation is a warning with an explicit threshold rather than an error: a hard failure on undeclared prose terms would fail the corpus today for 519 terms, most of which are legitimately undeclared prose, and would train reviewers to ignore it. An error is appropriate for one narrower case — an artifact that declares nothing while defining concepts that another artifact references by qualified id.

Re-verify the federation boundaries against the enlarged index

id: INFO-WP-0027-T04
status: todo
priority: medium
state_hub_task_id: "b9313ad5-7cb0-5be6-bc28-196f84640895"

Re-run the ownership-conflict check against the enlarged declaration set and re-verify the two accepted extension boundaries: SecurityCanon's nine owned concepts and twelve declared imports, and InterfaceCanon's. Record the result in each boundary file, including the correction if the earlier clean result no longer holds.

Notify security-canon and interface-canon through the State Hub inbox if either boundary's evidence changes. This is the task that converts the fix into restored trust in the earlier reviews.

Resolve R-3 as the first real use

id: INFO-WP-0027-T05
status: todo
priority: low
state_hub_task_id: "eb02c948-6401-5ef7-a341-4563ee73e00c"

Residual R-3 from the SecurityCanon review: Authority carries two live senses inside InfoTechCanon — the recognized right held by an actor (ITC-ORG section 10.17) and an external body compelling disclosure (CARING section 10.7 exposure mode). Declaring both under T02 forces the question rather than leaving it in prose.

Resolve by disambiguation, not by rename: CARING's exposure mode is a demand from an authority, and saying so in one sentence is likely enough. The test is that a reader arriving from sec-authority:AuthMode can tell which sense a given section means.

Residual R-2 — the proposal to generalise CARING section 32 beyond non-human subjects — is explicitly not in this workplan. It is a semantic change to a release-candidate standard and needs its own review.

Done when

The ownership index is built from declarations that cover every concept the twelve silent artifacts define; coverage is reported as a number that moves with the corpus; the enforcement level is recorded with its rationale; and both accepted extension boundaries carry a conflict result re-verified against the enlarged index.