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	finished	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;
• 13 live artifacts declare nothing at all (T01 measured one more than this estimate): itc-core, the kernel map, access-control, data, devsecops, governance, information-space, landscape, network, observability, security, task, and tagging;
• 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: done
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.

Result — 2026-09-20 (T01)

Extractor added as maintenance.concept_candidates() with the CLI command concept-coverage, covering the bold, numbered-heading and concept-table forms over live artifacts, with assimilation/, seeds/ and incoming/ excluded as preserved source. Baseline report: history/2026-09-20_230456+0200-concept-declaration-baseline.md.

Measured over 31 live artifacts: 113 concepts declared against 690 defined in prose, leaving 637 defined but undeclared — about 16 percent declaration coverage. The workplan's 519 was the bold form alone; the heading form, which is what hid itc-org:Authority, raises it.

Two corrections to the workplan's own framing. The silent artifacts number thirteen, not twelve: kernel/itc-core declares nothing while defining 57 concepts across two forms, and it is the artifact every other artifact imports from, so T02 should take it first. And the gap is wider than ownership of obscure terms — Actor itself is undeclared in model/organization, though SecurityCanon imports it from there by name with a pinned hash.

Three tests cover the extractor, including one that asserts Authority appears in the organization model's undeclared list, so the F-1 blind spot now has a regression test. make check passes with 49 tests.

Declare concepts for the thirteen silent artifacts

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

Add reviewed owned_concepts frontmatter to the thirteen 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: kernel/itc-core first, since every other artifact imports from it, then access-control, security, devsecops and governance, 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.

Result — 2026-09-20 (T02)

Declarations written for twelve of the thirteen silent artifacts, plus the map-assigned concepts the Organization Model was missing and the Landscape seed concepts the extractor could not see. The ownership index goes from 164 entries to 750, and undeclared prose definitions fall from 637 to 57, with zero ownership conflicts. The 57 that remain are the overlaps this round assigned to another owner: they are imports, and each is recorded in a boundary review.

kernel/itc-kernel-map declares nothing, deliberately. It assigns concepts to owners rather than defining them, and it is now the only silent artifact — which the test suite asserts, so a future artifact that declares nothing fails.

The kernel map's concept-owner table was used as the arbiter wherever it assigns an owner, which resolved most overlaps without new judgment. Fifteen concepts it does not assign were decided in this round and recorded with rationale.

itc-org:Authority — the concept whose absence produced finding F-1 — is now declared, along with Actor, Ownership, Membership, Role, Responsibility and Accountability, which SecurityCanon and the identity model already treat as organization-owned. The regression test asserts the kernel map's assignment and the declaration agree.

One concept is deliberately left undeclared. The kernel map assigns Profile to Core, but the identity model owns Profile under accepted CUST-ADR-006, and Observability defines a runtime performance profile that the identity boundary review already disambiguates. Declaring Core's sense would have created the first real conflict; resolving three senses needs a decision, not a declaration. It is recorded as open in the kernel boundary review.

Boundary reviews

id: INFO-WP-0027-T06
status: done
priority: medium
state_hub_task_id: "61ad08c4-d76c-59b9-b8ff-f44500df4bc7"

Every artifact that gained a declaration and has an overlap now carries a boundary-review.md beside it, in the shape the identity model has used since INFO-WP-0021: one row per overlapping concept, naming the owner, the resolution and whether the kernel map or this review decided it. Eleven were written — kernel, access-control, data, devsecops, governance, information-space, network, observability, security, task and tagging. Landscape gained declarations without overlaps and needs none.

The largest finding is in the kernel review. Core and the Information Space model restate eight provenance concepts — Activity, AgentReference, Alias, DecisionRecord, ExternalReference, Influence, Namespace and Source — in nearly identical words. Core owns them with the provenance family; Information Space imports. Four more were decided by disambiguation rather than transfer: Label (Core, with Tagging's display sense kept), Drift (Core, with Network's configuration drift kept), Summary (Information Space, with Observability's metric aggregation kept) and Attribute (Data, with Access Control importing for attribute-based decisions). Exposure and Investigation go to Security; Subject stays with ITC-ACCESS as SECURITY-DEC-2026-003 records.

Report coverage instead of asserting completeness

id: INFO-WP-0027-T03
status: done
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.

Result — 2026-09-20 (T03)

validation-coverage now carries a concept_declaration block: declared, defined in prose, undeclared, the ratio, the silent artifacts, and the extraction limit in words. It reports 699 declared against 690 extracted, a ratio slightly above one, because Landscape's seed-concept lists and concepts defined in YAML payloads are declared but not extractable. The limit is stated in the report rather than hidden in the number. not_proven no longer claims ownership of prose concepts is unproven wholesale; it names the forms extraction does not read.

Enforcement is recorded as two checks with different weights, as recommended:

• concept_declaration_missing — error. An artifact that defines concepts and declares none. kernel/itc-kernel-map is exempt by name, with the reason in the code: it assigns concepts to owners rather than defining them. Zero today, and a new artifact added without declarations fails.
• concept_defined_without_owner — warning. A concept defined in prose that no artifact declares. A name another artifact owns is an import, not a gap, so imports do not warn — which is what keeps the check from firing 57 times and training reviewers to ignore it.

Three warnings today, and they are real: model/organization defines Assignment, Availability, Capacity, CollectiveActor, Competence, Group, OrganizationEntity, OrganizationalCapability, Post, ReportingLine and Skill that nobody owns; standard/caring defines Effective Access, Declared Access, Derived Capability and Capability Profile, which are central CARING concepts; model/capability defines Supply and Capacity behaviour. These are the check's first real finding and are carried as T07 rather than declared here — declaring them without a boundary review would repeat the mistake this workplan exists to fix.

Declare the concepts nobody owns

id: INFO-WP-0027-T07
status: done
priority: medium
state_hub_task_id: "f2f23e8e-542b-5b37-82fd-95cd694af493"

Seventeen concepts are defined in prose and declared by no artifact, surfaced by the concept_defined_without_owner warning added in T03. Declare them to their defining artifact where that is right, with a boundary review for each artifact touched, and resolve the ones that are not — Capacity in the Organization Model against Capacity behaviour in the Capability Model is one concept or two, and the answer decides who declares it.

CARING is the priority: Effective Access and Declared Access carry the standard's central distinction, they are referenced by the Kubernetes RBAC benchmark, and they are undeclared.

Re-verify the federation boundaries against the enlarged index

id: INFO-WP-0027-T04
status: done
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: done
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.

Result — 2026-09-20 (T04)

Both accepted extension boundaries were re-run against the enlarged index, and the re-verification is recorded in each boundary file.

Neither boundary has an ownership conflict. None of SecurityCanon's nine owned concepts and none of InterfaceCanon's collides with an InfoTechCanon declaration now that declarations cover the corpus. The central claim of both acceptances holds.

But name resolution had never been checked, and it fails in nine places. Both original reviews verified their import manifests by file hash; every hash matched, and that was recorded as evidence. A hash proves the reviewed file is the pinned file. It says nothing about whether the concept named in the manifest exists in it. The enlarged index makes that second check possible for the first time.

SecurityCanon: five of twelve imports named concepts their pinned artifact does not define. Artifact resolves to the DevSecOps build artifact because Core defines CanonArtifact; Relationship belongs to the identity model, not Core, which defines RelationshipDefinition; Ownership belongs to Organization; AccessOperations is a compaction of ITC-ACCESS Operation; PrincipalType appears nowhere upstream. All five are corrected on the SecurityCanon side, which now declares eleven imports. No concept is contested and no disposition changes.

InterfaceCanon: twenty-one of twenty-five resolve exactly. Two of the four failures were InfoTechCanon's own omission — SoftwareSystem and SoftwareComponent are Landscape seed concepts that extraction cannot read, and they are now declared here, making InterfaceCanon's pins correct. The other two, Interface and Endpoint, resolve to the Network Model rather than Landscape, which the accepted clarifications already treat as contextual rather than exact aliases; re-pointing or qualifying those pins is InterfaceCanon's change.

The method limit is the finding worth carrying: hash verification and name resolution are two different checks, and federation reviews were running only the first. Worth making the second a standing check rather than a one-off, which is not in this workplan's scope.

Result — 2026-09-20 (T05)

Residual R-3 resolved by disambiguation, as recommended, with no rename. CARING section 10.7 now states that its Authority exposure mode names a demanding party rather than a right, links to ITC-ORG section 10.17, and says that an Authority in that section holds no organizational authority over the system it compels — it compels from outside. ITC-ORG section 10.17 carries the reciprocal sentence and adds that SecurityCanon's AuthMode qualifies the exercise of this right rather than redefining it.

The test the residual asked for — that a reader arriving from sec-authority:AuthMode can tell which sense a section means — is met by both sections naming the other.

Result — 2026-09-20 (T07)

All seventeen concepts that no artifact declared are now declared, and the concept_defined_without_owner warning is at zero. The Organization Model takes eleven (Assignment, Availability, Capacity, CollectiveActor, Competence, Group, OrganizationEntity, OrganizationalCapability, Post, ReportingLine, Skill), CARING four and the Capability Model two.

The question the task flagged is answered: Capacity in the Organization Model and Capacity behaviour in the Capability Model are two concepts. One is how much work an actor or group can absorb; the other is whether a capability's supply is elastic or fixed as demand grows. Neither moves.

Two of CARING's four were not new concepts. Capability Profile and Derived Capability are the prose spellings of the declared CaringCapabilityProfile and CaringDerivedCapability; both spellings are now declared to the same owner so the name a reader meets in the text resolves, with no conflict. Effective Access and Declared Access are genuinely central and were genuinely undeclared.

Three boundary reviews are added — organization, caring and capability — which brings the count to fourteen.

Closure — 2026-09-20

All seven tasks are done. Final state: the ownership index holds 718 declared concepts against 690 the extractor can see, zero ownership conflicts, zero declaration errors and zero unowned-concept warnings. kernel/itc-kernel-map is the only artifact declaring nothing, by design and by exemption in the code.

What the workplan set out to do, it did: the gap that let itc-org:Authority pass a federation conflict check unseen is closed, measured, reported and enforced, and both accepted extension boundaries were re-verified against the enlarged index.

What it found on the way is worth more than what it fixed. Hash verification and name resolution are two different checks, and every federation review so far had run only the first — which is why nine import declarations across two boundaries named concepts their pinned artifact does not define. Making name resolution a standing check is not in this workplan's scope and deserves its own.

Residual R-2, the proposal to generalise CARING section 32, remains open and untouched, as this workplan said it would.

Limits. Extraction reads three definition forms; seed-concept lists and YAML payload concepts are declared but not extracted, which is why the ratio exceeds one. A declaration records that an artifact claims a concept, not that the concept is well defined. Everything here is agent review, not human sign-off.