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

---
id: INFO-WP-0027
type: workplan
title: "Close the concept-declaration gap so ownership conflicts are detectable"
domain: infotech
repo: info-tech-canon
status: finished
owner: claude
topic_slug: canon-federation
created: "2026-09-20"
updated: "2026-09-20"
flavor: quality
state_hub_workstream_id: "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

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

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

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

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

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

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

```task
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.