tegwick
28d5824362
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>
56 lines
2.8 KiB
Markdown
56 lines
2.8 KiB
Markdown
# 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:
|
|
|
|
1. keep as-is — IDs are durable interfaces and already drafted;
|
|
2. renumber to `security.*` — consistent prefixes, but breaks IDs;
|
|
3. 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.
|