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.
3.1 KiB
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:
- keep as-is — IDs are durable interfaces and already drafted;
- renumber to
security.*— consistent prefixes, but breaks IDs; - split the navigation domain into
securityandgovernance.
Decision: option 3. See the OQ-2 decision record in
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.