Measure the concept-declaration gap (INFO-WP-0027-T01)

Adds maintenance.concept_candidates() and the concept-coverage CLI command,
which measure concepts an artifact defines in prose against the concepts it
declares. Extraction covers the bold form, the numbered-heading form that hid
itc-org:Authority, and the concept-table form the kernel map uses; preserved
source under assimilation, seeds and incoming is excluded. Candidates are review
input, never ownership.

Baseline over 31 live artifacts: 113 concepts declared against 690 defined,
leaving 637 defined but undeclared, about 16 percent coverage. The workplan's
519 counted the bold form alone.

Two corrections to the workplan's framing, applied there. Thirteen artifacts
declare nothing rather than twelve: kernel/itc-core defines 57 concepts across
two forms and declares none, and it is the artifact every other artifact imports
from, so it goes first in T02. The gap also reaches further than obscure terms —
Actor is undeclared in the organization model although SecurityCanon imports it
from there by name against a pinned hash.

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

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

history/2026-09-20_230456+0200-concept-declaration-baseline.md

@@ -0,0 +1,128 @@
+# Concept declaration coverage — baseline measurement
+
+Date: 2026-09-20 23:04 (Europe/Berlin)
+Task: INFO-WP-0027-T01
+Measured at: working tree on `37ad0c9`, before any declaration change
+Command: `info_tech_canon concept-coverage`
+
+## What was measured
+
+`concept_ownership()` builds the ownership index from two sources only: each
+artifact's title, and its `owned_concepts` frontmatter. This report adds a third
+view — concepts an artifact *defines in prose* — so the gap between what the
+canon defines and what it declares can be counted rather than estimated.
+
+Extraction covers three forms, over live artifacts only. Preserved source under
+`assimilation/`, `seeds/` and `incoming/` is excluded: it records what others
+wrote, not what this canon owns.
+
+- **bold** — `**Name** is|—|defines|denotes|identifies|represents`
+- **heading** — a numbered section heading whose title is restated as a bold
+  definition within five lines. This is the form `itc-org:Authority` (ITC-ORG
+  10.17) and `itc-ident:Scope` (ITC-IDENT 2.10) use, and the form that made
+  finding F-1 invisible.
+- **table** — rows of a table whose first column is headed Concept, Term, Name
+  or Entity. Only the kernel map uses it, appropriately: it assigns concepts to
+  owners rather than defining them.
+
+Candidates are review input, never ownership. A concept becomes owned by being
+declared, not by being matched here.
+
+## Result
+
+| Measure | Count |
+| --- | --- |
+| Live artifacts measured | 31 |
+| Concepts declared by those artifacts | 113 |
+| Concepts defined in their prose | 690 |
+| Defined but undeclared | **637** |
+| Artifacts with no `owned_concepts` frontmatter at all | **13** |
+
+Declaration coverage is about 16 percent of what the measured artifacts define.
+The workplan estimated 519 undeclared terms from the bold form alone; adding the
+heading and table forms raises it to 637, and nine artifacts each carry forty or
+more undeclared definitions.
+
+The thirteen silent artifacts: `kernel/itc-core`, `kernel/itc-kernel-map`,
+`model/access-control`, `model/data`, `model/devsecops`, `model/governance`,
+`model/information-space`, `model/landscape`, `model/network`,
+`model/observability`, `model/security`, `model/task`, `standard/tagging`.
+This is one more than the twelve the workplan named — `kernel/itc-core` declares
+`owned_concepts` nowhere despite defining 36 concepts by heading and 21 by bold
+form, and it is the artifact every other artifact imports from.
+
+## Per-artifact
+
+| Artifact | Declared | Defined | Undeclared | Declares frontmatter |
+| --- | --- | --- | --- | --- |
+| `model/network` | 1 | 79 | 78 | no |
+| `model/information-space` | 1 | 72 | 71 | no |
+| `model/observability` | 1 | 68 | 67 | no |
+| `model/devsecops` | 1 | 63 | 62 | no |
+| `model/data` | 1 | 53 | 52 | no |
+| `model/security` | 1 | 53 | 52 | no |
+| `model/task` | 1 | 53 | 52 | no |
+| `model/access-control` | 1 | 49 | 48 | no |
+| `model/governance` | 1 | 46 | 45 | no |
+| `kernel/itc-core` | 1 | 37 | 36 | no |
+| `model/organization` | 3 | 28 | 25 | yes |
+| `standard/tagging` | 1 | 26 | 25 | no |
+| `kernel/itc-kernel-map` | 1 | 11 | 11 | no |
+| `model/landscape` | 1 | 7 | 6 | no |
+| `standard/caring` | 16 | 5 | 5 | yes |
+| `model/capability` | 14 | 3 | 2 | yes |
+| `comparison/repo-scoping/consumer-workplan-brief` | 1 | 0 | 0 | no |
+| `comparison/repo-scoping/report` | 1 | 0 | 0 | no |
+| `concept-area/family` | 2 | 0 | 0 | yes |
+| `conformance/railiance-fabric/consumer-workplan-brief` | 1 | 0 | 0 | no |
+| `evaluation/user-engine/consumer-workplan-brief` | 1 | 0 | 0 | no |
+| `model/evidence` | 5 | 4 | 0 | yes |
+| `model/identity` | 24 | 23 | 0 | yes |
+| `model/purpose-demand-extension` | 10 | 9 | 0 | yes |
+| `pattern/intent-scope-purposes` | 2 | 0 | 0 | yes |
+| `practice-pattern/agentic-drives-functional` | 4 | 0 | 0 | yes |
+| `practice-pattern/interface-deprecation-strangler` | 1 | 0 | 0 | no |
+| `review-kit/alignment/workplan-template` | 1 | 0 | 0 | no |
+| `scheme/practice-pattern` | 3 | 0 | 0 | yes |
+| `standard/emission-cadence` | 6 | 0 | 0 | yes |
+| `standard/repository-layout` | 5 | 1 | 0 | yes |
+## Findings
+
+**F-1 reproduces.** `Authority` appears in `model/organization`'s undeclared
+list. The SecurityCanon boundary review compared seven SecurityCanon concepts
+against every `owned_concepts` declaration and recorded a clean result; this
+measurement shows why that result was structurally unable to see the conflict
+candidate that SECURITY-WP-0001-T03 later found by hand.
+
+**`Actor` is undeclared too.** The Organization Model declares three concepts —
+`Community`, `Household` and its title — while defining 28. `Actor` is among the
+undeclared, yet SecurityCanon imports `Actor` from this artifact by name, with a
+pinned hash, and the identity model lists it as an ITC-ORG concept. The corpus
+treats it as owned; the machine-readable declaration does not say so. The same
+holds for `Ownership`, `Membership`, `Role` and `Accountability`.
+
+**The silent artifacts are the exposed ones.** Access control, security and
+DevSecOps are precisely the surfaces that federation partners reference. The
+artifacts with the best declarations — identity, CARING, the Purpose and Demand
+extension — are the ones that have been through a boundary review. Declaration
+quality tracks review history, not importance.
+
+**Extraction quality is good enough to review from, and not good enough to
+trust.** Spot-checking `model/organization` returns Accountability, Actor,
+Agent, Assignment, Authority, CollectiveActor, Competence, Group, Membership,
+Organization, OrganizationEntity, Position — all real concepts. But the
+heading form will also catch section titles that merely restate a defined term,
+and no extractor can tell a concept this canon *owns* from one it *imports and
+re-explains*. That judgment is T02's work, per artifact, by hand.
+
+## What this does not measure
+
+Ownership of concepts defined only in tables outside the kernel map, in YAML
+payloads, or in prose that defines without the bold form. The 637 is a floor.
+
+## Next
+
+T02 declares concepts for the silent artifacts, ordered by federation exposure:
+access control, security, DevSecOps, governance. `kernel/itc-core` should be
+added to that order at the front — it was missed when the workplan was written,
+and it is the most-imported artifact in the corpus.