info-tech-canon/infospace/assimilation/it-capability-canon/open-questions.md

# 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 — **RESOLVED 2026-08-15 (canon 0.2.1)**

Six capabilities sat in navigation domain `security` but two used 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`.

**Decision: option 3.** See the OQ-2 decision record in
[`ASSIMILATION.md`](ASSIMILATION.md). No longer blocks promotion.

## 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.

**Partial fire, 2026-08-15.** `demand/CapabilityProvisionEconomics.md` needed
structure for *consumption of* intelligence (native unit `token`, quality
dimension `intelligence_intensity`, class `I` as substitute for `H`). That
structure landed in ITC-CAP 0.2.0 as resource-class and provision semantics, not
as a new intelligence domain model. Invoices, entitlements, prompts, and
evaluations still have no owning model. The trigger remains open for those.

## 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.