TenantAtlas/specs/203-baseline-compare-strategy/spec.md

Feature Specification: Baseline Compare Engine Strategy Extraction

Feature Branch: 203-baseline-compare-strategy
Created: 2026-04-13
Status: Draft
Input: User description: "Spec 203 - Baseline Compare Engine Strategy Extraction"

Spec Candidate Check (mandatory - SPEC-GATE-001)

• Problem: Baseline compare already works for Intune-backed policy subjects, but the platform still mixes compare orchestration with Intune-specific subject resolution, normalization, and finding projection, so compare cannot expand safely beyond its first domain.
• Today's failure: Baseline scope can become broader through Spec 202, but the compare path still behaves as if every governed subject is an Intune policy flow. That keeps future-domain work trapped behind hidden Intune assumptions and risks misleading compare truth when the platform vocabulary grows.
• User-visible improvement: Operators keep one baseline compare story, one run model, one finding lifecycle, and one trust or outcome model, while unsupported or mixed-domain scope is rejected honestly and current Intune compare behavior stays stable.
• Smallest enterprise-capable version: Extract one platform compare orchestration layer, one explicit compare strategy contract, one deterministic strategy resolver, one stable internal compare-result contract, and one explicit Intune compare strategy without adding a second real governance domain or redesigning compare UI.
• Explicit non-goals: No second compare-capable domain, no multi-strategy-per-run orchestration, no broad backup/restore or inventory generalization, no repo-wide Intune rename, no new compare plugin framework, and no wholesale redesign of findings persistence.
• Permanent complexity imported: One compare strategy contract, one deterministic resolver, one structured per-subject compare-result contract, one explicit Intune strategy boundary, compatibility validation at compare entrypoints, and focused regression coverage.
• Why now: Spec 202 creates the canonical scope vocabulary. Without this extraction, compare remains the strongest Intune-shaped bottleneck and will either block the first non-Intune compare domain or force the platform to carry misleading universal policy semantics longer.
• Why not local: A thin wrapper around the current monolith would preserve the same hidden Intune assumptions in the platform core, leaving future domains to fork the compare path or misuse Intune-shaped artifacts.
• Approval class: Core Enterprise
• Red flags triggered: New abstraction risk and future-domain preparation risk. Defense: compare is already a production-real workflow, the new seam is justified by current compare truth rather than speculative breadth, the first release stays single-strategy-per-run, and existing persistence and UI are preserved wherever possible.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 1 | Produktnaehe: 1 | Wiederverwendung: 2 | Gesamt: 10/12
• Decision: approve

Spec Scope Fields (mandatory)

• Scope: workspace, tenant, canonical-view
• Primary Routes:
  • /admin/baseline-profiles/{record} as the existing workspace baseline detail and compare launch surface
  • /admin/baseline-profiles/{record}/compare-matrix as the existing workspace compare matrix and visible-set fan-out surface
  • /admin/t/{tenant}/baseline-compare as the tenant compare landing and result surface
  • /admin/operations/{run} as the canonical compare-run detail surface
• Data Ownership:
  • Workspace-owned baseline profiles, baseline snapshots, and canonical Baseline Scope V2 remain the reference truth that compare reads.
  • Tenant-owned compare runs, compare findings, and related diagnostics remain the persisted operational truth written by compare.
  • This feature does not require a new top-level persisted compare result artifact. The new compare-result contract is internal to orchestration and may be reflected only through existing run and finding persistence.
• RBAC:
  • Existing workspace baseline view and manage capabilities remain authoritative for workspace baseline detail and compare-matrix launch surfaces.
  • Existing tenant compare and finding capabilities remain authoritative for tenant compare and compare follow-up surfaces.
  • This feature changes orchestration and compare eligibility, not membership boundaries. Non-members remain 404, entitled members without the required capability remain 403, and unsupported strategy or mixed-scope failures are truthful compare-state outcomes rather than authorization shortcuts.

For canonical-view specs, the spec MUST define:

• Default filter behavior when tenant-context is active: Canonical compare-run detail keeps current tenant context in related links when the operator arrived from a tenant route, but the run viewer itself remains explicit to the referenced run and does not widen visibility beyond the entitled tenant.
• Explicit entitlement checks preventing cross-tenant leakage: Canonical run-detail and compare drilldowns must continue to enforce workspace entitlement first and tenant entitlement second. Unsupported or failed strategy details must never reveal hidden tenant identities, hidden scope entries, or cross-tenant compare metadata.

Decision-First Surface Role (mandatory when operator-facing surfaces are changed)

Surface	Decision Role	Human-in-the-loop Moment	Immediately Visible for First Decision	On-Demand Detail / Evidence	Why This Is Primary or Why Not	Workflow Alignment	Attention-load Reduction
Baseline profile detail and compare matrix launch controls	Secondary Context Surface	Decide whether compare can start for the selected baseline scope and visible tenant set	Compare readiness, compatible strategy family, and unsupported or mixed-scope reason when compare cannot start	Deeper domain diagnostics, subject-family detail, and run drilldowns	Not primary because these surfaces prepare compare work rather than serving as the final tenant review surface	Follows baseline definition and workspace compare launch workflow	Prevents operators from starting misleading compare runs and then reconstructing why they failed
Tenant baseline compare landing	Primary Decision Surface	Decide whether the tenant currently matches the baseline, needs follow-up, or needs data or support remediation	Compare summary, trust or completeness state, and explicit unsupported or incomplete meaning when compare could not produce a trustworthy result	Subject-level evidence gaps, detailed diagnostics, and related run history	Primary because this is where tenant compare truth becomes actionable for the operator	Follows the tenant review workflow after compare execution	Keeps unsupported, ambiguous, and incomplete states distinct from calm no-drift results
Canonical compare run detail	Tertiary Evidence / Diagnostics Surface	Inspect why a compare run failed, degraded, or refused to process a given scope	Run outcome, summary counts, high-level compare reason, and next-step guidance	Strategy diagnostics, subject-level diagnostics, and detailed processing context	Not primary because it explains the run after the decision surface, rather than serving as the default governance queue	Follows monitoring and troubleshooting workflow	Keeps raw orchestration or strategy detail secondary until the operator deliberately opens evidence

UI/UX Surface Classification (mandatory when operator-facing surfaces are changed)

Surface	Action Surface Class	Surface Type	Likely Next Operator Action	Primary Inspect/Open Model	Row Click	Secondary Actions Placement	Destructive Actions Placement	Canonical Collection Route	Canonical Detail Route	Scope Signals	Canonical Noun	Critical Truth Visible by Default	Exception Type / Justification
Baseline profile detail	Detail / Workflow hub	Workspace baseline detail	Start compare for one tenant or review compare matrix readiness	Explicit view page	not applicable	Existing header actions and contextual status sections	Existing archive action remains in its current confirmed placement	/admin/baseline-profiles	/admin/baseline-profiles/{record}	Active workspace, baseline profile, canonical scope, compare readiness	Baseline profile / baseline compare	Whether the baseline scope is compare-compatible and whether launch would stay truthful	none
Baseline compare matrix	Matrix / Workspace report	Compare launch and drilldown hub	Compare assigned tenants or inspect tenant follow-up	Explicit page controls and drilldowns	forbidden	Header toolbar and matrix support surfaces	none	/admin/baseline-profiles/{record}/compare-matrix	Same route with focused state, plus tenant compare or run drilldowns	Active workspace, baseline profile, visible tenant set, compare compatibility	Baseline compare matrix	Whether the visible assigned set can be compared through one compatible strategy family	matrix surface remains a narrow custom layout exception
Tenant baseline compare landing	Decision / Review	Tenant compare landing	Compare now or inspect the latest compare truth	Explicit tenant page	forbidden	Header action and contextual compare summary panels	none	/admin/t/{tenant}/baseline-compare	Same route	Active workspace, tenant context, baseline context, compare trust state	Baseline compare	Whether the latest tenant compare result is trustworthy, unsupported, incomplete, or drifted	none
Canonical compare run detail	Evidence / Diagnostics	Operation run detail	Inspect run outcome and root cause	Explicit run detail view	forbidden	Existing navigation and diagnostics sections	none	/admin/operations/{run}	Same route	Workspace context, tenant context when applicable, run outcome, compare summary	Baseline compare run	Why the compare run completed, degraded, or failed and what follow-up is appropriate	canonical evidence detail

Operator Surface Contract (mandatory when operator-facing surfaces are changed)

Surface	Primary Persona	Decision / Operator Action Supported	Surface Type	Primary Operator Question	Default-visible Information	Diagnostics-only Information	Status Dimensions Used	Mutation Scope	Primary Actions	Dangerous Actions
Baseline profile detail and compare matrix launch controls	Workspace baseline manager	Decide whether compare should start for a baseline scope	Secondary context and workflow hub	Can this baseline scope be compared honestly for the intended target set right now?	Scope summary, compatibility readiness, and unsupported or mixed-scope explanation	Detailed domain or subject-family diagnostics	compare readiness, compatibility, rollout or support constraints	simulation only for compare starts	Compare now, Compare assigned tenants, Open compare matrix	Existing archive action only
Tenant baseline compare landing	Tenant operator	Decide whether tenant state requires follow-up or whether compare truth is incomplete or unsupported	Tenant review surface	Can I trust this compare result, and what kind of follow-up is appropriate?	Compare summary, drift status, trust or completeness, and operator-safe unsupported or incomplete meaning	Subject-level diagnostics and detailed evidence-gap context	compare outcome, trust, evidence completeness, actionability	simulation only	Compare now, inspect findings or related evidence	none
Canonical compare run detail	Workspace operator or entitled tenant operator	Inspect run truth and diagnose failure or degraded compare behavior	Canonical evidence detail	Why did this compare run succeed, degrade, or fail?	Run outcome, summary counts, and high-level reason	Per-subject diagnostics, strategy diagnostics, and detailed processing notes	execution outcome, compare completeness, diagnostics severity	read-only	View run context and navigate to related compare surfaces	none

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: no
• New persisted entity/table/artifact?: no
• New abstraction?: yes
• New enum/state/reason family?: yes, but only where compare-result classification or diagnostics must distinguish operator-visible outcomes that already exist implicitly
• New cross-domain UI framework/taxonomy?: no
• Current operator problem: The platform can only guarantee compare truth today because Intune-specific logic is embedded in the same path that owns run lifecycle, findings, and trust semantics. That shape blocks safe scope expansion and makes unsupported future-domain selections hard to reject honestly.
• Existing structure is insufficient because: Current compare orchestration still assumes Intune-style subject resolution and policy-shaped findings at platform level. As Baseline Scope V2 becomes broader, the platform lacks a clean boundary that lets domain logic vary without duplicating or distorting the compare workflow.
• Narrowest correct implementation: Introduce one explicit compare-strategy contract, one deterministic resolver, one strategy-neutral per-subject compare-result contract, and extract the existing Intune compare path behind that boundary. Keep compare single-strategy-per-run, keep current persistence and UI, and avoid generalizing backup, restore, inventory, or multi-domain presentation.
• Ownership cost: Ongoing contract discipline, regression coverage, compare-entrypoint validation, and care to keep strategy outputs structured enough that the platform core does not re-grow hidden domain assumptions.
• Alternative intentionally rejected: A superficial wrapper around the existing monolith, or a broad universal compare plugin framework. The wrapper would not remove the current bottleneck, and the plugin framework would over-abstract before the second real compare domain exists.
• Release truth: current-release platform correctness and controlled future-domain enablement, not speculative ecosystem totalization

User Scenarios & Testing (mandatory)

User Story 1 - Preserve current Intune compare through an explicit boundary (Priority: P1)

As a tenant or workspace operator, I want existing Intune baseline compare behavior to keep working after the extraction so that the platform gains a safer architecture without changing the compare truth I already rely on.

Why this priority: The extraction is only shippable if current Intune compare stays functionally intact. A cleaner abstraction that changes compare truth would be a regression, not an improvement.

Independent Test: Run the current Intune compare paths from the tenant landing and workspace fan-out surfaces, then confirm that drift, no-drift, incomplete, evidence-gap, finding, and summary behavior matches current expectations through the new orchestration path.

Acceptance Scenarios:

1. Given a baseline scope that is fully supported by the current Intune compare path, When an operator starts compare after this feature lands, Then the compare still runs successfully and produces the same core run, summary, and finding semantics through the explicit Intune strategy boundary.
2. Given an Intune compare case that currently resolves to no drift, drift, ambiguous, or incomplete truth, When the extracted compare path evaluates it, Then the operator sees the same category of outcome and the same follow-up meaning as before.

---

User Story 2 - Reject unsupported or mixed-domain compare scope honestly (Priority: P1)

As a workspace baseline manager, I want compare to reject unsupported or mixed-domain scope before work starts so that I do not launch misleading runs that quietly fall back to Intune assumptions.

Why this priority: Honest failure is part of the product value. The compare engine must not imply broader support than the platform actually has.

Independent Test: Attempt compare with canonical scope entries that have no matching strategy or that span more than one strategy family, and verify that the launch surfaces and run semantics fail clearly before compare proceeds.

Acceptance Scenarios:

1. Given a canonical baseline scope whose subject family has no compatible compare strategy, When an operator starts compare, Then the system refuses to start the compare as supported work and explains the unsupported scope clearly.
2. Given a canonical baseline scope that spans more than one strategy family, When an operator starts compare, Then the system rejects the run as incompatible rather than partially processing or silently choosing one family.

---

User Story 3 - Keep one platform compare story while allowing domain-specific logic (Priority: P2)

As a product team preparing the next governance domain, I want a new domain compare path to plug into the existing compare lifecycle so that future expansion does not require copying the current Intune monolith or pretending every governed subject is a policy.

Why this priority: This is the strategic reason for the feature. Without it, the platform keeps paying an increasing cost for Intune-first assumptions.

Independent Test: Register a non-Intune test strategy against canonical scope and verify that the compare entrypoint can resolve it, execute through the same orchestration lifecycle, and produce structured compare outputs without policy-only platform defaults.

Acceptance Scenarios:

1. Given a registered compare capability for a different domain family, When the compare entrypoint receives matching canonical scope, Then the platform can orchestrate the run through the same lifecycle and summary flow without reusing Intune-only assumptions.
2. Given the strategy returns structured subject results, When the platform writes summaries and findings, Then it does not have to invent missing domain meaning from raw strategy internals or policy-only defaults.

---

User Story 4 - Preserve truthful degraded and failed states (Priority: P2)

As an operator reviewing compare truth, I want unsupported, incomplete, ambiguous, and failed conditions to remain distinct so that the new boundary does not blur trust semantics.

Why this priority: The product's operator value depends on calm but accurate truth. Regression here would undermine confidence faster than a small functional bug.

Independent Test: Exercise strategy failure, unsupported subject family, missing baseline state, missing current state, and ambiguous subject matching cases, then verify that run detail and compare landing surfaces keep those meanings distinct from no drift.

Acceptance Scenarios:

1. Given a compare strategy fails after the run has started, When the operator opens the compare landing or run detail, Then the product shows a truthful failed or degraded outcome with meaningful diagnostics rather than collapsing into no-drift or silent partial success.
2. Given a subject cannot be compared because evidence is incomplete or identity is ambiguous, When the compare completes, Then the operator can distinguish that state from unsupported scope and from confirmed no-drift.

Edge Cases

• A canonical scope contains only supported Intune subject families but includes an inactive subject type that should be rejected before compare starts.
• A canonical scope contains entries that individually look valid but resolve to different strategy families when combined.
• A strategy matches the requested family at run start but later returns a subject result marked unsupported or indeterminate for a subset of discovered subjects.
• Baseline state exists for a subject but current state does not, and the strategy must distinguish evidence absence from true missing-drift semantics.
• Strategy diagnostics are available for troubleshooting, but default compare surfaces must not expose raw internal detail as the primary explanation.
• Workspace fan-out compare surfaces select a visible tenant set whose baseline scope is incompatible with the single-strategy-per-run rule.

Requirements (mandatory)

Constitution alignment (required): This feature reuses existing baseline compare run and finding flows. It does not introduce a new provider path or a new long-running workflow type, but it does introduce a new compare abstraction because current compare truth already needs a clean boundary between platform orchestration and domain logic.

Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001): The abstraction is justified by current-release compare truth, not speculative framework-building. A narrower wrapper would keep hidden Intune assumptions inside platform compare. No new top-level persistence, no general workflow plugin system, and no multi-strategy-per-run architecture are allowed in this release.

Constitution alignment (OPS-UX): Existing baseline_compare runs remain the canonical operational truth. Toasts remain intent-only, progress remains on existing run surfaces, and terminal notification behavior remains initiator-aware. Run status and outcome transitions remain service-owned. Any compare summary counts added or updated by this feature must stay numeric-only and lifecycle-safe. Strategy failure or unsupported-scope outcomes must remain visible through the same run truth rather than a parallel status system.

Constitution alignment (RBAC-UX): The feature spans workspace baseline surfaces under /admin, tenant compare surfaces under /admin/t/{tenant}/..., and canonical compare-run detail under /admin/operations/{run}. Membership boundaries remain unchanged: non-members receive 404, in-scope members missing capability receive 403. Server-side authorization remains required for compare starts and any related follow-up mutations. Unsupported or mixed-strategy rejection is compare eligibility truth, not an authorization bypass.

Constitution alignment (OPS-EX-AUTH-001): Not applicable beyond reaffirming that compare surfaces do not use the auth-handshake exception.

Constitution alignment (BADGE-001): This feature does not introduce a new badge framework. Existing centralized compare, trust, freshness, and outcome semantics remain authoritative. Any new unsupported or strategy-failure label must be centralized rather than page-local.

Constitution alignment (UI-FIL-001): The touched compare surfaces continue to use existing Filament pages, actions, sections, alerts, and shared status primitives. Unsupported or mixed-scope explanations must reuse those shared affordances rather than creating a local diagnostic UI framework.

Constitution alignment (UI-NAMING-001): Primary operator-facing labels remain Baseline Compare, Compare now, Compare assigned tenants, Compare matrix, Baseline compare, Open operation, and similar existing nouns. Internal architecture terms such as strategy, registry, or resolver stay out of primary operator copy unless they appear in secondary diagnostic detail where no simpler truthful wording exists.

Constitution alignment (DECIDE-001): The feature does not introduce a new primary operator surface. It reinforces the existing decision flow by making compare readiness, unsupported scope, incomplete evidence, and failure truth visible in the correct existing surfaces rather than hidden inside one domain-specific backend path.

Constitution alignment (UI-CONST-001 / UI-SURF-001 / ACTSURF-001 / UI-HARD-001 / UI-EX-001 / UI-REVIEW-001 / HDR-001): Existing inspect and drilldown models remain unchanged. Baseline detail, compare matrix, compare landing, and canonical run detail keep their current navigation patterns. The only material surface change is clearer compare eligibility and degraded-state truth. No new destructive action is introduced, and no existing destructive placement changes.

Constitution alignment (ACTSURF-001 - action hierarchy): Compare now and Compare assigned tenants remain the primary launch actions on their existing surfaces. Compare compatibility explanations belong in disabled helper text, confirmation copy, or immediate result messaging, not in mixed catch-all action groups. Navigation to detailed diagnostics remains secondary to the launch and review actions.

Constitution alignment (OPSURF-001): Default-visible compare content must stay operator-first. Launch surfaces should show whether compare can run truthfully. Review surfaces should show whether the latest result is trustworthy, unsupported, incomplete, or failed. Raw diagnostics and strategy-specific detail remain explicitly secondary.

Constitution alignment (UI-SEM-001 / LAYER-001 / TEST-TRUTH-001): The new compare-result contract is a business-truth boundary, not a UI semantics framework. The feature must remove hidden assumptions rather than add a second interpretive layer. Tests must prove behavior, outcome, and lifecycle correctness across the new boundary rather than merely proving indirection exists.

Constitution alignment (Filament Action Surfaces): The Action Surface Contract remains satisfied. Each affected surface keeps one primary inspect or open model, no redundant View action is introduced, empty action groups are not introduced, and destructive actions remain unchanged. The UI Action Matrix below records the affected surfaces.

Constitution alignment (UX-001 - Layout & Information Architecture): No new compare page is introduced. Existing compare pages, alerts, summaries, and run-detail sections must surface the new eligibility and failure truth without adding parallel layouts or naked diagnostic blocks.

Functional Requirements

• FR-203-001 Compare strategy contract: The platform MUST define one explicit compare capability contract that allows domain-specific logic to participate in compare without taking ownership of the platform run lifecycle.
• FR-203-002 Strategy capability declaration: Each compare strategy MUST declare the canonical domain, subject-class, and subject-type families it supports for compare.
• FR-203-003 Deterministic strategy resolution: The compare entrypoint MUST resolve exactly one compatible strategy family for a run from canonical Baseline Scope V2 and MUST do so deterministically.
• FR-203-004 Single-strategy-per-run rule: A compare run MUST reject scope that spans more than one compatible strategy family instead of partially processing or silently choosing one family.
• FR-203-005 No implicit Intune fallback: If no compatible strategy exists for the requested scope, the compare path MUST fail or degrade explicitly and MUST NOT silently fall back to the current Intune logic.
• FR-203-006 Platform orchestration ownership: The platform compare layer MUST own compare start, normalized scope intake, strategy resolution, run status and outcome transitions, summary aggregation, unified finding write flow, audit hooks, persistence coordination, and failure handling.
• FR-203-007 Strategy ownership boundary: A compare strategy MUST own subject discovery, baseline subject materialization, current-state materialization, domain normalization, fingerprinting, equivalence or drift determination, domain-specific evidence-gap classification, and domain-specific finding enrichment.
• FR-203-008 Explicit strategy inputs: A strategy MUST receive the current workspace, tenant, baseline reference, normalized scope, and compare-run context plus any required dependencies through explicit platform context rather than hidden global lookups.
• FR-203-009 Stable compare-result contract: The platform MUST consume a structured per-subject compare result that represents, at minimum, subject identity, domain key, subject class, subject type key, baseline availability, current-state availability, compare state, trust or confidence, evidence quality or gaps, recommended severity when relevant, finding candidate data, and diagnostics or reason codes.
• FR-203-010 Strategy-provided subject projection: Strategies MUST provide the subject metadata required for findings and summaries, including stable subject identity, domain key, subject-type meaning, stable subject key, and operator-facing label data, so that the platform does not invent policy-shaped defaults.
• FR-203-011 Unified platform outputs: Regardless of strategy, compare MUST continue to produce one canonical run model, one canonical compare summary model, one unified finding lifecycle, and one unified trust or outcome story.
• FR-203-012 Explicit Intune strategy: The current Intune compare behavior MUST run through one explicit Intune compare strategy rather than through implicit platform-default logic.
• FR-203-013 Intune behavior preservation: The Intune extraction MUST preserve existing drift, no-drift, incomplete, ambiguous, evidence-gap, summary, and finding projection behavior unless a separate spec explicitly changes those semantics.
• FR-203-014 Remove policy-only platform assumptions: Platform compare code touched by this feature MUST no longer assume that every subject is a policy, that policy-version evidence is universal, or that Intune normalization rules are universal compare behavior.
• FR-203-015 Distinct result states: The compare layer MUST keep no-drift, drift found, subject unsupported, evidence incomplete, ambiguous or indeterminate, and compare failed as distinct operator-visible outcomes.
• FR-203-016 Truthful strategy failure handling: If a strategy fails after compare has started, the platform MUST preserve truthful run outcome, useful diagnostics, and clear follow-up meaning rather than implying successful or complete compare.
• FR-203-017 Stable persistence footprint: The feature SHOULD reuse current compare and finding persistence wherever possible and MUST NOT introduce a new top-level compare artifact unless removing hardcoded platform assumptions cannot be done otherwise.
• FR-203-018 Strategy-neutral stored context: Any compare summary or run-context data added or changed by this feature MUST avoid implying that every compared subject is a policy unless that meaning is explicitly strategy-owned metadata.
• FR-203-019 Pre-flight scope validation: The compare entrypoint MUST validate that scope is canonical V2, that all included subject families are supported by the selected strategy, and that inactive or unsupported subject types are rejected before subject processing begins.
• FR-203-020 Workspace fan-out parity: Workspace compare launch surfaces that fan out tenant compares MUST apply the same compatibility validation and single-strategy rule as tenant-local compare starts.
• FR-203-021 Operator-safe unsupported messaging: If a compare cannot run because scope is unsupported or mixed, the operator MUST receive a clear explanation and the system MUST not imply that compare completed or that no drift was found.
• FR-203-022 Diagnostics without reverse engineering: The strategy result contract MUST be strong enough that the platform can write summaries, findings, and diagnostics without reverse-engineering raw strategy internals or reintroducing hidden domain assumptions.
• FR-203-023 Future-domain plausibility: The resulting compare boundary MUST make it possible to add a future non-Intune compare strategy by registering one strategy family and supplying the structured compare-result contract, without cloning the platform orchestration path.
• FR-203-024 Automated regression coverage: Automated coverage MUST prove strategy resolution, unsupported scope rejection, mixed-strategy rejection, Intune strategy capability matching, unchanged Intune compare classification and finding semantics, and preservation of canonical run outcome and trust behavior through the new boundary.
• FR-203-025 Enqueue-only compare starts: Tenant and workspace compare start surfaces MUST remain enqueue-only, MUST NOT perform inline remote work, and MUST keep strategy selection and compatibility validation in-process before the run is queued.

UI Action Matrix (mandatory when Filament is changed)

Surface	Location	Header Actions	Inspect Affordance (List/Table)	Row Actions (max 2 visible)	Bulk Actions (grouped)	Empty-State CTA(s)	View Header Actions	Create/Edit Save+Cancel	Audit log?	Notes / Exemptions
Baseline profile view page	Existing workspace baseline detail surface	Existing Compare now, Compare assigned tenants, and Open compare matrix actions remain; unsupported or mixed-scope compare must surface through existing confirmation or helper text patterns	Explicit baseline detail page	none added	none	Existing baseline detail empty states remain	Existing view-page actions remain	n/a	Existing compare-start audit semantics remain	No new action type; compare launch truth becomes more explicit
Baseline compare matrix page	Existing workspace compare matrix surface	Existing Compare assigned tenants remains the primary launch action; compatibility explanation must be visible before misleading fan-out starts	Explicit matrix controls and drilldowns	none added	none	Existing matrix empty states remain	n/a	n/a	Existing compare-start audit semantics remain	Matrix layout and drilldowns remain unchanged; only launch truth is clarified
Tenant baseline compare landing	Existing tenant compare landing surface	Existing Compare now remains capability-gated and confirmed; unsupported or mixed-scope compare must not present as a successful start	Explicit tenant compare page	none added	none	Existing compare prerequisites and empty states remain	Existing page actions remain	n/a	Existing compare-start and compare-run audit semantics remain	No new destructive action; existing launch action keeps confirmation
Canonical compare run detail	Existing compare run detail surface	Existing navigation actions remain	Explicit operation run detail	none added	none	Existing no-run or no-data states remain	Existing run-detail actions remain	n/a	Existing run-backed audit semantics remain	New strategy diagnostics remain secondary evidence, not a new action plane

Key Entities (include if feature involves data)

• Compare Strategy: The domain-owned compare capability that knows how to discover subjects, materialize baseline and current state, compare them, and enrich results for one compatible subject family.
• Compare Strategy Registry: The deterministic mapping that selects one compare strategy family from canonical Baseline Scope V2 for a run.
• Compare Subject Result: The structured internal result for one processed subject, including identity, classification, compare state, trust, evidence quality, finding candidate data, and diagnostics.
• Compare Orchestration Context: The platform-owned run context that coordinates scope intake, strategy resolution, execution, summary aggregation, finding persistence, and truthful run outcome.
• Intune Compare Strategy: The first explicit compare strategy that owns the current Intune-specific compare behavior without forcing those assumptions into the platform core.

Success Criteria (mandatory)

Measurable Outcomes

• SC-001: In automated regression coverage, 100% of the current Intune compare scenarios selected for the feature produce the same operator-visible classification, finding, and summary outcome after the Intune compare logic is isolated behind the new compare boundary.
• SC-002: In automated launch coverage, unsupported or mixed-strategy scope is rejected before subject processing in 100% of covered cases and is never reported as successful compare or no-drift.
• SC-003: In automated validation, one non-Intune compare-capable subject family can pass through the same compare lifecycle without being modeled as an Intune policy flow.
• SC-004: On the existing compare landing and run-detail surfaces, operators can distinguish no drift, drift, unsupported, incomplete, ambiguous, and failed outcomes without opening raw diagnostics.
• SC-005: Post-implementation review can identify one platform-owned compare lifecycle and one isolated Intune compare boundary, with no remaining universal policy default required at compare entrypoints.
• SC-006: Focused regression coverage proves that compare start surfaces stay enqueue-only, introduce no inline remote work, and preserve current compare throughput expectations for the targeted start paths.

Rollout Strategy

Phase 1 - Introduce strategy contract and resolution

• Define the compare strategy contract and the deterministic strategy registry.
• Route the compare entrypoint through strategy resolution while keeping the current Intune path functionally intact.

Phase 2 - Extract the Intune strategy

• Move the current Intune compare logic behind the explicit Intune strategy boundary.
• Preserve existing compare launches, summaries, findings, and operator-visible semantics.

Phase 3 - Remove platform hardcoding

• Eliminate platform-level policy-only assumptions from orchestration, finding projection defaults, and compare-result handling.
• Ensure compare summaries and finding writes consume strategy-provided metadata instead of Intune defaults.

Phase 4 - Harden diagnostics and rejection paths

• Make unsupported and mixed-strategy scope rejection explicit on the existing compare launch surfaces.
• Ensure strategy failure and degraded cases stay truthful on compare landing and run-detail surfaces.

Non-Goals

• Implementing a second real governance domain
• Supporting multi-strategy compare in one run
• Redesigning the compare UI as a multi-domain surface
• Renaming every Intune-specific class, field, or model
• Replacing the current finding lifecycle or evidence domain with a new universal model
• Generalizing backup, restore, or inventory workflows as part of this feature
• Building a broad compare plugin framework for unrelated workflows

Assumptions

• Spec 202 provides the canonical Baseline Scope V2 input contract and subject-family vocabulary needed for deterministic strategy resolution.
• Existing Intune compare behavior is the first production-real strategy and should be preserved rather than diluted into a lowest-common-denominator compare model.
• Single-strategy-per-run is sufficient for the current release and keeps compare truth easier to explain than mixed-domain orchestration would.
• Existing compare runs and findings can absorb the necessary strategy-neutral context without requiring a new top-level compare persistence model.
• Workspace compare fan-out continues to start tenant-owned compare work and does not need a new workspace umbrella run in this feature.

Dependencies

• Spec 202 - Governance Subject Taxonomy and Baseline Scope V2
• Existing workspace baseline detail and compare-matrix surfaces
• Existing tenant baseline compare landing and canonical operation run detail surfaces
• Existing compare summary, trust, finding, and audit semantics
• Current Intune compare logic as the baseline behavior to preserve

Risks

• The extraction could become a thin wrapper around the current monolith without really removing platform-level Intune assumptions.
• Intune compare behavior could regress during the move behind the explicit boundary if regression coverage is too weak.
• The compare-result contract could stay too weak, forcing the platform layer to rebuild hidden domain assumptions from raw strategy outputs.
• Unsupported or mixed-scope rejection could be surfaced too late, after partial compare work has already started.
• Future-domain preparation could expand into a broader framework unless the single-strategy-per-run boundary is enforced.

Definition of Done

• The compare engine has one platform-owned orchestration path and one explicit Intune compare strategy.
• Current Intune compare behavior still works and is regression-protected through the new boundary.
• Compare entrypoints resolve strategy from canonical Baseline Scope V2 rather than implicit Intune assumptions.
• Unsupported or mixed-strategy scope is rejected clearly and truthfully.
• Platform compare code touched by this feature no longer treats policy semantics as the universal compare default.
• Existing operator surfaces keep one consistent run, finding, trust, and outcome story while strategy-specific detail remains secondary.