coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
info-tech-canon/infospace/assimilation/it-capability-canon/open-questions.md
tegwick 680ed8b4b1
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
Split capability navigation domains; canon 0.2.1 (OQ-2 resolved) 
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>
2026-08-15 02:43:55 +02:00

2.7 KiB
Raw Blame History

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