info-tech-canon/workplans/INFO-WP-0028-import-manifest-resolution.md

---
id: INFO-WP-0028
type: workplan
title: "Make import-manifest name resolution a standing check"
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: "c55e827d-05ab-5911-8206-81cab1d5a329"
---

# Import-manifest name resolution

## Why

Federation partners declare what they import from InfoTechCanon in a manifest:
an artifact path, a pinned SHA-256 of that file's blob, and a list of concept
names. Every review so far has verified the hash and recorded the match 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.

Nobody had run the second check until INFO-WP-0027-T04, and it failed in nine
places across the two accepted boundaries:

- **SecurityCanon: five of twelve.** `Artifact` resolved to the DevSecOps build
  artifact, because Core defines `CanonArtifact` and not `Artifact`.
  `Relationship` is the identity model's, not Core's. `Ownership` is the
  Organization Model's. `AccessOperations` is a compaction of ITC-ACCESS
  `Operation`. `PrincipalType` appears nowhere upstream.
- **InterfaceCanon: four of twenty-five.** Two were this repository's omission,
  since `SoftwareSystem` and `SoftwareComponent` sat in a seed-concept list that
  extraction could not read. Two more, `Interface` and `Endpoint`, are pinned to
  Landscape while the Network Model declares them.

None of those was a contested concept. Every one was a citation naming the wrong
artifact, or a name InfoTechCanon never used. They are cheap to find and cheap to
fix — once something looks.

Two conditions make the check possible now that were not true before.
INFO-WP-0027 gave every defining artifact an `owned_concepts` declaration, so the
ownership index resolves 718 concepts rather than 164. And the index moves when
the corpus moves, so a partner's pins can go stale without anyone editing the
partner's file.

## What this is not

Not a claim that a resolving manifest is a correct one. Resolution proves the
name exists and names one owner; whether the partner uses the concept as its
owner defines it is a semantic question that stays with boundary review. Not an
enforcement surface over partner repositories either — the check reports, the
partner decides.

## Reusable manifest review

```task
id: INFO-WP-0028-T01
status: done
priority: high
state_hub_task_id: "7c4e8a21-51a9-5658-b56f-01204e4cba34"
```

Add a read-only `import-review` command taking a path to any partner manifest,
in the shape `emission-review` already uses for source-owned cadence
declarations: the canon validates a file it does not own and returns JSON.

Per declared concept, report whether the name resolves in the ownership index,
which artifact owns it, and whether that is the artifact the manifest pins.
Per entry, re-check the pinned SHA-256 against the blob at the declared source
commit, so hash and name are checked in one pass and neither can be recorded
without the other.

Exit non-zero on a failed resolution so a partner can run it in CI. The command
must work against an arbitrary manifest path without registering it, and must
not require the partner repository to be checked out beside this one.

## Accepted manifests as a standing check

```task
id: INFO-WP-0028-T02
status: done
priority: high
state_hub_task_id: "7491a8ac-1f96-5f2e-a9eb-f3995c528cae"
```

A partner-run command catches errors when the partner runs it. It does not catch
the case that produced two of the nine findings: InfoTechCanon changes, and pins
that were correct become stale without the partner touching anything.

Register the manifests of accepted boundaries under `infospace/interfaces/`, as
copies with their source repository, revision and retrieval date recorded, and
resolve them on every `make check`. A concept that stops resolving, or resolves
to a different owner than the manifest pins, is a **warning** naming the partner
and the concept — not an error, because it is not this repository's file to fix
and a stale partner pin must not fail the canon's own build.

Decide and record whether a registered manifest copy is provenance-preserving
source, like `seeds/`, or a generated artifact refreshed from the partner. The
answer determines who may edit it.

## Record resolution in boundary reviews

```task
id: INFO-WP-0028-T03
status: done
priority: medium
state_hub_task_id: "20eab825-8236-583e-b246-cbe86122cc7c"
```

Make the resolution result part of what a boundary review states, alongside the
hash result, so an acceptance cannot again record "all hashes match" as though it
were evidence of correct citation. The SecurityCanon and InterfaceCanon boundary
files already carry a T04 re-verification section in roughly the right shape;
generalise it into the review kit under `infospace/agent/` so the next boundary
review starts from a template that asks both questions.

## Close the two open partner findings

```task
id: INFO-WP-0028-T04
status: done
priority: medium
state_hub_task_id: "cdf31f69-7a2e-5be0-a988-145dee48c063"
```

InterfaceCanon's `Interface` and `Endpoint` pins resolve to the Network Model
rather than Landscape. The accepted boundary already treats those as contextual
mappings rather than exact aliases, so this is a citation fix, not a semantic
dispute. It was raised with interface-canon by State Hub message
`13d355f2-554b-4a3a-a0ef-3f69eeafeae9` on 2026-09-20; follow it up and confirm
the correction, or record their decision to qualify the pins in place instead.

Re-run T01 against both partner manifests afterwards and record the result in
each boundary file.

## Done when

Any partner manifest can be checked by one command that verifies hash and name
together; accepted manifests are re-resolved on every `make check` with drift
reported as a warning that names the partner; the review kit asks for both
results; and no open resolution finding remains against either accepted
boundary.

### Result — 2026-09-20 (T01, T02, T03)

`import-review` takes any manifest path and returns JSON: per concept, whether
the name resolves in the ownership index and to which artifact; per entry,
whether the pinned SHA-256 matches the blob at the declared source commit. Both
checks run in one pass, so neither can be recorded without the other. It exits
non-zero on a finding, reads JSON or YAML, and needs no partner checkout. It
also carries its own limit in the payload: resolution proves a name exists and
names one owner, and nothing more.

Manifests are registered under `infospace/interfaces/manifests/` with
`manifests.yaml` recording the partner, the source path, the partner revision
and the retrieval date. **They are provenance-preserving copies, owned by the
partner** — the decision T02 asked for. Correcting a copy to make a check pass
is explicitly forbidden in the file itself: fix it in the partner repository and
retrieve it again. `validate` re-resolves them and reports drift as
`federation_import_drift`, a warning naming the partner, never an error.

Both accepted boundaries carry a standing-check section with the current result.
The review kit gains `extension-boundary-review.template.md`, which requires
hash count, resolution count and conflict count as three separate lines, and an
operating rule stating that one is never evidence of the other.

Verified against both live manifests: security-canon resolves 11 of 11 with six
hashes matching; interface-canon resolves 23 of 25 with seven hashes matching,
the two exceptions being the known `Interface` and `Endpoint` pins. The check
finds exactly what the T04 audit found by hand, which is the point.

### Result — 2026-09-20 (T04)

Corrected in interface-canon at `20d7bfc2`, on the owner's instruction rather
than by waiting for the unanswered message.

The cause was a third instance of one pattern. `Interface` and `Endpoint` were
pinned twice, to ITC-LAND and to ITC-NET, because ITC-LAND section 13.2 lists
them in a seed-concept block while the Network Model defines them. A list of
names was read as a definition — the same mistake as CARING's Scope ladder
(R-1), CARING's Environment values (F-3), and the Landscape seeds that hid
`SoftwareSystem` and `SoftwareComponent` (T04 of INFO-WP-0027). The ITC-LAND
pins are dropped, and Landscape section 13.2 now states in InfoTechCanon that
`Interface`, `Endpoint` and `API` are pointers and that the Network Model owns
the first two, so the next reader does not repeat it.

No disposition changes on either side; the mapping tables citing ITC-LAND
section 13.2 as a related seed stand. The registered copy is refreshed to the
corrected revision, both boundaries now resolve completely — security-canon 11
of 11, interface-canon 23 of 23 — and `make check` carries no drift warnings.

## Closure — 2026-09-20

All four tasks are done. Any partner manifest can be checked by one command that
verifies pinned hash and concept-name resolution together; accepted manifests are
registered as provenance-preserving partner-owned copies and re-resolved on every
`make check`, with drift reported as a warning naming the partner; the review kit
requires both counts and says that one is never evidence of the other; and no
resolution finding remains open against either accepted boundary.

The pattern worth naming, since it recurred four times in one day: a canon lists
concept names in one artifact and defines them in another, and every consumer of
the list treats the listing as ownership. Declarations and this check make that
visible, but the underlying habit is a documentation one, and no check will stop
it being written again.