TenantAtlas/specs/236-canonical-control-catalog-foundation/research.md

Research: Canonical Control Catalog Foundation

Decision 1: Keep the first catalog product-seeded and config-backed

• Decision: Model the first canonical control catalog as a product-seeded registry in repository configuration plus narrow value objects and resolvers, not as an operator-managed DB CRUD domain.
• Rationale: The current release needs one stable control identity more than it needs authoring workflow, lifecycle UI, or workspace-specific customization. A config-backed seed catalog keeps the control core small, reviewable, versioned with the code, and easy to exercise across multiple governance consumers.
• Alternatives considered:
  • DB-backed control management UI: rejected because the current release has no operator workflow that requires live authoring, approval, archiving, or per-workspace overrides.
  • Feature-local arrays inside each consumer: rejected because that would preserve the current semantic fragmentation.

Decision 2: Separate platform-core control definitions from provider-owned Microsoft bindings

• Decision: Canonical control identity, taxonomy, detectability, evaluation semantics, and evidence suitability stay platform-core, while Microsoft workload, subject-family, and signal relationships remain provider-owned binding metadata.
• Rationale: The product is Microsoft-first today, but this spec exists partly to stop Microsoft semantics from becoming silent platform truth. The separation keeps the catalog framework-neutral and provider-neutral without inventing a speculative multi-provider runtime.
• Alternatives considered:
  • Use Microsoft subject identifiers as the primary control key: rejected because it would make the provider the platform core.
  • Create a generic provider-plugin framework now: rejected because there is only one real provider case today.

Decision 3: Make ambiguity explicit in the shared resolution contract

• Decision: The shared resolver returns explicit resolved, unresolved, or ambiguous outcomes instead of guessing when one subject or signal could imply multiple controls.
• Rationale: A guessed mapping would silently misclassify governance meaning and poison later findings, review outputs, or evidence narratives. Explicit ambiguity is safer and easier to test.
• Alternatives considered:
  • Always return the first matching control: rejected because ordering would become hidden truth.
  • Allow consumers to choose different local fallback rules: rejected because it would recreate semantic drift.

Decision 4: Encode detectability, evaluation strategy, and evidence archetypes directly on each control

• Decision: Each canonical control definition carries detectability class, evaluation strategy, evidence archetypes, and artifact suitability instead of leaving those semantics to later presentation layers.
• Rationale: The control core must explain what the product can prove, partially infer, attest, or only reference externally. Deferring that meaning to later overlays would force downstream consumers to invent their own truth.
• Alternatives considered:
  • One generic verification flag: rejected because it collapses materially different control types into one misleading boolean.
  • Consumer-specific interpretation rules: rejected because those rules would diverge immediately.

Decision 5: Keep first-slice consumer adoption derived rather than persistence-first

• Decision: First-slice consumers resolve canonical control metadata on read through the shared contract instead of requiring immediate schema expansion across baseline, finding, evidence, exception, and review records.
• Rationale: The current need is control convergence, not a broad storage migration. Derived adoption proves the catalog against real workflows while keeping rollout narrow.
• Alternatives considered:
  • Add canonical_control_key columns everywhere up front: rejected because it forces a broad migration before the model is proven.
  • Leave all consumers untouched until a later reporting slice: rejected because then the catalog would exist without proving cross-domain value.

Decision 6: Start with a bounded seed catalog of high-value governance families

• Decision: Seed only the control families already implied by the current product and roadmap, such as strong authentication, conditional access, privileged access, endpoint hardening or compliance, sharing boundaries, audit retention, and delegated admin boundaries.
• Rationale: The goal is a reviewable bridge layer, not exhaustive coverage. A bounded seed catalog is easier to validate and keeps the spec proportional.
• Alternatives considered:
  • Exhaustive control library in the first release: rejected because it imports compliance-program scale before the control core is proven.
  • Framework-shaped seeds such as CIS or NIS2 first: rejected because frameworks are downstream overlays, not the primary control ontology.