62 lines
2.6 KiB
Markdown
62 lines
2.6 KiB
Markdown
|
<!--
|
||
|
|
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.>
|