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

# 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.