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

id	type	title	domain	repo	status	owner	topic_slug	created	updated	flavor	state_hub_workstream_id
INFO-WP-0028	workplan	Make import-manifest name resolution a standing check	infotech	info-tech-canon	proposed	claude	canon-federation	2026-09-20	2026-09-20	quality	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

id: INFO-WP-0028-T01
status: todo
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

id: INFO-WP-0028-T02
status: todo
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

id: INFO-WP-0028-T03
status: todo
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

id: INFO-WP-0028-T04
status: todo
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.