From d1254aabe65e99689a07a84087a5e569c280c744 Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 20 Sep 2026 23:38:09 +0200 Subject: [PATCH] Plan a standing check for import-manifest name resolution (INFO-WP-0028) Federation partners pin an artifact path, a blob hash and a list of concept names. Every review so far 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 ran the second check until INFO-WP-0027-T04, which found nine failures across the two accepted boundaries, none of them a contested concept and all of them a citation naming the wrong artifact or a name this canon never used. The workplan adds a reusable import-review command in the shape emission-review already uses, registers accepted manifests so drift is caught when this repository changes rather than when a partner happens to look, generalises the re-verification section into the review kit so an acceptance cannot again record matching hashes as evidence of correct citation, and closes the two open pins InterfaceCanon still owns. Drift against a registered manifest is a warning, not an error: a stale partner pin is not this repository's file to fix and must not fail its build. Status is proposed: drafted from the INFO-WP-0027 findings, not yet reviewed by the owner. Co-Authored-By: Claude Opus 5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 3588@bnt-lap001 Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da --- WORK-RECORDS.md | 5 + ...INFO-WP-0028-import-manifest-resolution.md | 145 ++++++++++++++++++ 2 files changed, 150 insertions(+) create mode 100644 workplans/INFO-WP-0028-import-manifest-resolution.md diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md index a474d50..bed4531 100644 --- a/WORK-RECORDS.md +++ b/WORK-RECORDS.md @@ -19,6 +19,7 @@ | workplan | INFO-WP-0025 | finished | — | workplans/INFO-WP-0025-federation-interface.md | | workplan | INFO-WP-0026 | finished | — | workplans/INFO-WP-0026-interface-canon-boundary-review.md | | workplan | INFO-WP-0027 | finished | — | workplans/INFO-WP-0027-concept-declaration-coverage.md | +| workplan | INFO-WP-0028 | proposed | — | workplans/INFO-WP-0028-import-manifest-resolution.md | | workplan | ITC-WP-0001 | finished | — | workplans/ITC-WP-0001-infospace-scaffold-and-seed-placement.md | | workplan | ITC-WP-0002 | finished | — | workplans/ITC-WP-0002-service-surface-cli-json-api.md | | workplan | ITC-WP-0003 | finished | — | workplans/ITC-WP-0003-validation-indexes-and-generated-views.md | @@ -72,6 +73,10 @@ | task | INFO-WP-0027-T05 | done | — | workplans/INFO-WP-0027-concept-declaration-coverage.md | | task | INFO-WP-0027-T06 | done | — | workplans/INFO-WP-0027-concept-declaration-coverage.md | | task | INFO-WP-0027-T07 | done | — | workplans/INFO-WP-0027-concept-declaration-coverage.md | +| task | INFO-WP-0028-T01 | todo | — | workplans/INFO-WP-0028-import-manifest-resolution.md | +| task | INFO-WP-0028-T02 | todo | — | workplans/INFO-WP-0028-import-manifest-resolution.md | +| task | INFO-WP-0028-T03 | todo | — | workplans/INFO-WP-0028-import-manifest-resolution.md | +| task | INFO-WP-0028-T04 | todo | — | workplans/INFO-WP-0028-import-manifest-resolution.md | | task | ITC-WP-0001-T01 | done | — | workplans/ITC-WP-0001-infospace-scaffold-and-seed-placement.md | | task | ITC-WP-0001-T02 | done | — | workplans/ITC-WP-0001-infospace-scaffold-and-seed-placement.md | | task | ITC-WP-0001-T03 | done | — | workplans/ITC-WP-0001-infospace-scaffold-and-seed-placement.md | diff --git a/workplans/INFO-WP-0028-import-manifest-resolution.md b/workplans/INFO-WP-0028-import-manifest-resolution.md new file mode 100644 index 0000000..c669059 --- /dev/null +++ b/workplans/INFO-WP-0028-import-manifest-resolution.md @@ -0,0 +1,145 @@ +--- +id: INFO-WP-0028 +type: workplan +title: "Make import-manifest name resolution a standing check" +domain: infotech +repo: info-tech-canon +status: proposed +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: 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 + +```task +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 + +```task +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 + +```task +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.