Inbound demand against ITC-CAP v0.1.0 from a consumer that has completed a full
procurement-to-control cycle on a real resource. Three findings.
A. typical_resource_classes contradicts the model's own §4.11 ("consumption
attaches to a provision, never to an abstract capability") and carries almost
no information: 29 of 41 capabilities declare an identical C,S,N,P.
B. Quality targets have a supply-side home (ITC-LAND SLOs attach to services) and
no demand-side home. CapabilityRequirement is a capability id plus a minimum
maturity, so a consumer cannot state RPO, retention, or failure-domain
separation before a provider exists — even though ITC-CAP already declares
isolation and geographical_separation as data.backup dimensions.
C. The resource-class set has no human-effort class, and classifies Intelligence
as one more purchased input. Consumer evidence: provider selection inverted on
operator hours (Hetzner cheaper on infrastructure, EUR 29.14/month worse
overall); a self-managed option rejected on recurring hours rather than price;
and a platform repository that delivered effort in hours and explicitly not in
EUR. The consumer argues further that machine intelligence is a substitute for
human effort rather than an ingredient beside it, and that token efficiency is
a primary platform characteristic, so both need native units on a provision.
Also records the criterion used to reject splitting ITC-CAP into supply and
demand canons: split when the sides disagree about what exists, keep one canon
when they agree about what exists and differ only in what they assert about it.
Notes honestly that the consumer does not yet measure token consumption; that
part of the demand is forward-looking. It also offers the backup case, restated
in canon terms, toward ITC-CAP §10 promotion requirement 3.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tegwick
9c7c1e4bdf