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: proposed
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;
- **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

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

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

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

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

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