info-tech-canon/infospace/interfaces/manifests/manifests.yaml

# Registered partner import manifests.
#
# These are provenance-preserving copies, owned by the partner repository and
# retrieved from it. Do not edit a copy to make a check pass: correct it in the
# partner repository and retrieve it again, recording the new revision here.
# The copies exist so that drift is caught when InfoTechCanon changes, not only
# when a partner happens to look.
#
# Decided under INFO-WP-0028-T02.
manifests:
  - partner: security-canon
    file: security-canon.json
    retrieved_from: infospace/vocabulary/mode-of-authority/imports.json
    partner_revision: e159fe7a1b2b9172fc979a284c4de88e4d08b933
    retrieved_at: "2026-09-20"
    boundary: ../security-canon-boundary.md
  - partner: interface-canon
    file: interface-canon.json
    retrieved_from: infospace/models/interface/imports.json
    partner_revision: 37fbe245bfd00fb1271af368eec7f0161247d57f
    retrieved_at: "2026-09-20"
    boundary: ../interface-canon-boundary.md
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 2026-09-20 23:43:34 +02:00			`# Registered partner import manifests.`
			`#`
			`# These are provenance-preserving copies, owned by the partner repository and`
			`# retrieved from it. Do not edit a copy to make a check pass: correct it in the`
			`# partner repository and retrieve it again, recording the new revision here.`
			`# The copies exist so that drift is caught when InfoTechCanon changes, not only`
			`# when a partner happens to look.`
			`#`
			`# Decided under INFO-WP-0028-T02.`
			`manifests:`
			`- partner: security-canon`
			`file: security-canon.json`
			`retrieved_from: infospace/vocabulary/mode-of-authority/imports.json`
			`partner_revision: e159fe7a1b2b9172fc979a284c4de88e4d08b933`
			`retrieved_at: "2026-09-20"`
			`boundary: ../security-canon-boundary.md`
			`- partner: interface-canon`
			`file: interface-canon.json`
			`retrieved_from: infospace/models/interface/imports.json`
			`partner_revision: 37fbe245bfd00fb1271af368eec7f0161247d57f`
			`retrieved_at: "2026-09-20"`
			`boundary: ../interface-canon-boundary.md`