A provision can name which other provision satisfies a catalog
dependency. Relation vocabulary is depends_on / may_use only.
Quoted sits below the invoiced/measured peer pair for propagation.
Both requested by info-tech-canon in reply to the ITC-CAP restatement.
EvidenceBasis.md — proposed owner ITC-GOV, imported by CapabilityConsumption.
ITC-GOV §11.34 defines Evidence as an artifact kind; nothing says how a quantity
was obtained, so nothing bounds how far a conclusion computed from it may be
trusted. Closed scale invoiced/measured/quoted/derived/projected/estimated/
assumed/unknown; a derived value resolves to the weakest of its inputs; unknown
carries no quantity and names its owner; proxy_for orthogonal to strength;
decision grades tied to existing Assertion semantics. Strength is a tier, not a
total order — invoiced and measured are peers, which the consumer's first
implementation got wrong and has corrected. invoiced names a fin-hub fact
without originating one, per info-tech-canon's instruction. Placed in GOV rather
than CAP because the consumer already wants it on actuals and thresholds.
ProvisionRelationships.md — ITC-CAP §4.7/§7. A provision cannot say which
provision satisfies a dependency the catalog declares between capabilities. The
consumer recorded "uses security.secrets" as one unit of class P consumption,
which info-tech-canon correctly identified as the wrong kind. That is the
predictable result of the gap: consumes is the only structured list available,
so P drifts back into a dumping ground for "depends on something" and undoes the
narrowing finding C just achieved. Proposes uses_provisions reusing the existing
depends_on / may_use vocabulary, checkable against the capability graph.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
