tegwick 28d5824362

CI Smoke / host-smoke (push) Successful in 0s

Details

CI Smoke / container-smoke (push) Successful in 1s

Details

Assimilate ITCC v0.1 as Capability Model; canon 0.2.0

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>

2026-08-14 20:54:32 +02:00

2.8 KiB

Raw Blame History

Open Questions — ITCC v0.1 assimilation

OQ-1 — Is the capability set a model or a standard?

Resolved for now as a model (broad domain structure). If capability contracts later grow enforcement rules and conformance levels for consumers, part of it may split into a standard. Review trigger: first consumer conformance request.

OQ-2 — The `governance.*` prefix inside the Security & Governance domain

Six capabilities sit in navigation domain security but two use a governance. ID prefix (governance.evidence, governance.lifecycle). Options:

keep as-is — IDs are durable interfaces and already drafted;
renumber to security.* — consistent prefixes, but breaks IDs;
split the navigation domain into security and governance.

Capability IDs are durable interfaces, so this must be settled before promotion beyond proposed. Preference: option 3 — it preserves every ID and removes the inconsistency. Owner: canon owner. Blocks: promotion to draft/release-candidate.

OQ-3 — Should the intended/declared/applied/observed/assessed state qualifier be canon-wide?

The source proposes it for maturity claims (a provider may claim D5 while an assessment concludes D4). The same distinction would be useful for controls, access maps, and network policy. Adopting it inside the capability model alone would create a local dialect. Deferred: raise as kernel-level (Core) pressure, not a capability-model decision.

OQ-4 — Who owns continuity and service recovery?

operations.recovery and operations.continuity have no strong canon owner: Security owns incidents, Observability owns health, Data owns backup assets, but business continuity and recovery objectives sit between them. Mapping confidence is low. Candidate: a Governance or Landscape extension.

OQ-5 — Do `commerce.` and `intelligence.` need their own domain models?

Both are canon-new surface with no anchoring model. Today they are capability IDs with no owner behind them, which is acceptable for a capability catalog but weak if consumers start requiring structural semantics (invoices, entitlements, prompts, evaluations). Review trigger: the first consumer demand that needs structure rather than ability.

OQ-6 — How are capability requirements validated against provisions?

The source sketches a validator (§18) comparing product requirements to provider maturity. That belongs to the service surface (ITC-WP-0002) and needs the contract schema first. Deferred: ITC-WP-0014.

OQ-7 — Relationship between `CapabilityProfile` and canon `Profile`

Named and distinguished, but not yet formally related. A canon Profile (e.g. small-saas) will plausibly select capability profiles. Deferred: ITC-WP-0014 alongside the small-SaaS requirement set.

2.8 KiB Raw Blame History