tegwick
b69b048dcb
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.
61 lines
3.1 KiB
Markdown
61 lines
3.1 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 — **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.
|