Inbound consumer demand from FIN-WP-0007. Asks for a lineage qualifier
on CapabilityConsumption, commerce.entitlement/metering structure, and
dropping cost as an intelligence quality. No model change.
Finish ITC-WP-0013 (AttributeValueType under ITC-DATA) and ITC-WP-0014
T02/T03/T05/T06/T07. Capability contract schemas, live-catalog review
CLI, landscape/kernel-map pointers. Sit on this version.
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.
§10.3 now accepts a consumer record that validates against the live
catalog; resource-control's backup restatement is that proof. ITC-GOV
gains EvidenceBasis in tiers (invoiced and measured are peers) and
ITC-CAP requires it on every consumption row (CAP-R10).
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>
A third front door next to incoming/ and demand/: longitudinal PurposeFit
evidence, not a change request and not a canon artifact. Seeded with the
resource-control backup-cycle mapping.
Accept resource-control demand: move resource classes onto provisions,
let requirements carry targets and constraints, add human-effort class H
with native-unit consumption. Model stays proposed.
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>
Security & Governance splits into `security` (secrets, keys, policy,
vulnerability) and `governance` (evidence, lifecycle). Every capability id
is unchanged — domains are navigation_only, so this is a table-of-contents
change, not a concept change.
- capabilities.yaml: 41 capabilities across 9 domains
- ITC-CAP §8 catalog table and promotion gate updated
- OQ-2 closed; decision record added to ASSIMILATION.md
- canon 0.2.0 -> 0.2.1 (patch) + CHANGELOG entry
- ITC-WP-0014 T01 done, workplan active
make validate: ok. make test: 22 passed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fix-consistency C-06 wrote workplan and task UUIDs back into the workplan
files and regenerated WORK-RECORDS.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Define the intake and assimilation practice (incoming/ drop zone -> frozen
source snapshot -> Minimal Assimilation Profile -> disposition gate -> canon
transformation -> versioned change notes) and run it on the first inputs.
- infospace/assimilation/intake-and-assimilation-practice.md, incoming/README.md
- assimilation/it-capability-canon: frozen source, comparison matrix, 26
mappings, 8 proposed changes, 7 open questions, decision record (adapt)
- new model ITC-CAP with 41-capability machine-readable catalog, anchored to
owning canon models; CILM rejected, Profile renamed, Provision made explicit
- registered in canon.yaml / artifacts index / infospace.yaml; regenerated
briefs, indexes, views; canon version 0.1.0-scaffold -> 0.2.0 + CHANGELOG
- ITC-WP-0014 for promotion work; ITC-WP-0013 added to the workplan registry
make validate: ok (65 artifacts, 0 errors/warnings). make test: 22 passed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Maintainer decision, 2026-07-29: adopts TRSL V1C1 as this repo's
preliminary governing license, per target-revenue's
workplans/TREV-WP-0008-governance-and-pilot-rollout.md T05. Full
specialist legal review is deferred until out of beta (target-revenue
SCOPE.md §1). No Phase is yet declared for this repo.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sync AGENTS.md, CLAUDE.md, and .claude/rules from updated project_rules
templates: workplan-first session protocol, legacy terminology footnote,
and GET /workplans/ examples.
Honest first-pass maturity vector grounded in README/docs/tests present
in this repo; no invented evidence. Flagged for human review before
publish. See reuse-surface history/2026-07-06-coverage-classification.md.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Align agent files with on-disk workplan prefixes (infer from workplan ids)
- Set workplan domain to registered domain_slug; add topic_slug where applicable
- Repair frontmatter delimiter formatting; migrate legacy task status literals
- Regenerate AGENTS.md, CLAUDE.md, and .claude/rules from State Hub templates
Register the InfoTechCanon Repository Layout Standard as a domain standard
(itc-repo-layout), processed from demand through the canon's Purpose/Demand
intake without collapsing existing model concepts.
- Register standard in artifacts/index.yaml, canon.yaml, infospace.yaml;
regenerate indexes, views, briefs, tree, and validation (validate green).
- T04: add reconciliation.yaml (partial/as-is dogfooding, declared core
conformance, recorded tensions); resolve the demand by moving it out of
demand/ to the evaluation pack as source-demand.md and removing demand/.
- T05: add consumer-adoption-brief.md for downstream repos.
- Update test artifact/standard counts (60->61, standards 2->3).
- Mark T03/T04/T05 done; workplan and registry status -> finished.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
