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 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 3588@bnt-lap001 Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
This commit is contained in:
parent
d6b3a289f1
commit
d1254aabe6
2 changed files with 150 additions and 0 deletions
|
|
@ -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 |
|
||||
|
|
|
|||
145
workplans/INFO-WP-0028-import-manifest-resolution.md
Normal file
145
workplans/INFO-WP-0028-import-manifest-resolution.md
Normal file
|
|
@ -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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue