tegwick
680ed8b4b1
Security & Governance splits into `security` (secrets, keys, policy, vulnerability) and `governance` (evidence, lifecycle). Every capability id is unchanged — domains are navigation_only, so this is a table-of-contents change, not a concept change. - capabilities.yaml: 41 capabilities across 9 domains - ITC-CAP §8 catalog table and promotion gate updated - OQ-2 closed; decision record added to ASSIMILATION.md - canon 0.2.0 -> 0.2.1 (patch) + CHANGELOG entry - ITC-WP-0014 T01 done, workplan active make validate: ok. make test: 22 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
54 lines
2.7 KiB
Markdown
54 lines
2.7 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.
|
|
|
|
## 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.
|