Check import manifests by hash and name together (INFO-WP-0028 T01-T03)

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

Accepted manifests are registered under infospace/interfaces/manifests/ as
provenance-preserving copies owned by the partner, with the partner revision and
retrieval date recorded. Editing a copy to make a check pass is forbidden in the
file itself. Validation re-resolves them and reports drift as
federation_import_drift, a warning naming the partner rather than an error,
because a stale partner pin is not this repository's file to fix.

The review kit gains an extension-boundary-review template requiring hash count,
resolution count and conflict count as three separate lines, and an operating
rule saying one is never evidence of another. Both boundary files carry the
standing-check result.

Verified live: security-canon resolves 11 of 11, interface-canon 23 of 25 with
the two known Interface and Endpoint pins. make check passes with 58 tests,
clean validation and those two warnings.

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

infospace/agent/review-kit/review-kit.yaml

@@ -20,6 +20,7 @@ components:
   model_selection_guide: review-kit/alignment/model-selection-guide
   schema: review-kit/alignment/schema
   consumer_workplan_template: review-kit/alignment/workplan-template
+  extension_boundary_template: agent/templates/extension-boundary-review.template.md
 required_outputs:
   - repository_context
   - selected_canon_surfaces
@@ -33,3 +34,4 @@ operating_rules:
   - Evidence quality and confidence must be recorded separately from reviewer judgment.
   - INTENT, SCOPE, and PURPOSES should be checked before proposing alignment work.
   - Namespace, role, scope, tenant, evidence, and purpose terms must not be conflated across native systems and canon concepts.
+  - An import manifest must be checked twice, by pinned blob hash and by name resolution against the ownership index. A hash proves the reviewed file is the pinned file; only resolution proves the concept named in the manifest exists in it. Record both counts, never one as evidence of the other.

infospace/agent/templates/extension-boundary-review.template.md

@@ -0,0 +1,61 @@
+<!--
+Template for accepting an extension canon's boundary against InfoTechCanon.
+Created by INFO-WP-0028-T03.
+
+Both questions below are required. Every boundary review before 2026-09-20
+recorded matching blob hashes as evidence of correct citation, and nine import
+declarations across two accepted boundaries named concepts their pinned artifact
+does not define. A hash proves the reviewed file is the pinned file; only name
+resolution proves the concept named in the manifest exists in it.
+
+Run, and paste the counts:
+  info_tech_canon import-review <partner manifest path>
+-->
+
+# <Partner> extension boundary
+
+Status: <accepted | accepted with findings | not accepted> for the semantic
+boundary documented below, reviewed by <reviewer> in the InfoTechCanon
+repository on <date>. State whether this is an agent review or human sign-off.
+
+Review target: <partner> <version> at `<partner commit>`.
+InfoTechCanon review base and import source: `<itc commit>`.
+
+## Accepted dispositions
+
+<One bullet per concept-level decision. Name the layer separation, what is
+imported rather than redefined, and any concept that looks like a duplicate but
+is not. State explicitly which InfoTechCanon concepts are transferred — usually
+none.>
+
+## Evidence
+
+**Hash verification.** <N of N> pinned SHA-256 values match Git blobs at the
+declared InfoTechCanon source revision, and those files are unchanged in the
+review checkout.
+
+**Name resolution.** <N of N> declared import names resolve in the InfoTechCanon
+ownership index to the artifact the manifest pins. List every one that does not,
+with what it resolves to instead and whether it is a citation error, a name
+InfoTechCanon never used, or a contested concept. Only the third is a boundary
+question; the first two are manifest corrections.
+
+**Ownership conflict.** <N> of the partner's owned concepts collide with an
+InfoTechCanon declaration. Name any that do.
+
+## Limits
+
+- Scope: which partner version, and that no stable promotion is asserted.
+- What the acceptance does not record: consumer adoption, runtime claims,
+  conformance statements.
+- Any proposal the partner references that this review does **not** accept.
+- Resolution proves a name exists and names one owner. Whether the partner uses
+  the concept as its owner defines it is a semantic question this review must
+  answer in the dispositions above, not something the check can settle.
+
+## Re-verification
+
+<Date and workplan of each re-run against a changed ownership index, with what
+changed. A registered manifest under `infospace/interfaces/manifests/` is
+re-resolved on every `make check`, and drift is reported as a warning naming the
+partner.>