TenantAtlas/specs/128-rbac-baseline-compare/research.md

Research — Intune RBAC Baseline Compare & Findings v1

Decision: Add explicit baseline-compare support metadata on foundation types

Rationale: BaselineProfileResource::foundationTypeOptions() currently lists all foundation types from InventoryPolicyTypeMeta::foundations(), which would make every configured foundation implicitly selectable for baseline compare. The spec requires intentional, type-level baseline eligibility metadata so only intuneRoleDefinition becomes eligible and intuneRoleAssignment stays excluded.

Alternatives considered:

• Filter foundation options with hard-coded type checks in Filament resource code: rejected because it hides eligibility rules in UI code and does not create a reusable source of truth.
• Treat every foundation as baseline-eligible by default: rejected because the spec explicitly disallows broad foundation rollout.

Decision: Reuse the existing RBAC Graph contracts and inventory/version evidence from Spec 127

Rationale: config/graph_contracts.php already contains inventory-grade contracts for intuneRoleDefinition and intuneRoleAssignment, and Spec 127 already established tenant-scoped inventory plus immutable PolicyVersion evidence for Role Definitions. The compare feature can therefore stay DB-first and does not need new live Graph calls for baseline rendering or run detail.

Alternatives considered:

• Add new RBAC-specific Graph contracts for compare: rejected because current contracts already include the fields needed for normalized Role Definition diffs.
• Re-hydrate live Graph payloads during compare: rejected because it would violate the existing DB-first compare and monitoring model and introduce misleading drift when live state is unavailable.

Decision: Use Role Definition ID as the compare identity for this foundation type

Rationale: Current baseline capture and compare use display-name-derived BaselineSubjectKey matching. That is adequate for some policy surfaces but does not meet the spec requirement for Role Definition identity, where a delete-and-recreate with a new ID is meaningful drift. The capture and compare pipeline needs a targeted identity-model extension for intuneRoleDefinition so baseline items and current inventory match by stable external ID.

Alternatives considered:

• Keep display-name matching and treat renamed duplicates as ambiguous: rejected because it would hide recreated roles and violate the spec’s identity model.
• Match by a composite of display name plus built-in/custom state: rejected because the object identity still changes when a role is recreated.

Decision: Reuse IntuneRoleDefinitionNormalizer::flattenForDiff() as the normalized compare surface

Rationale: The existing normalizer already produces deterministic, order-insensitive permission-block output and readable summary blocks for Role Definitions. Reusing that normalization path keeps diff semantics aligned with the inventory and version-display model from Spec 127 and avoids a second RBAC diff representation.

Alternatives considered:

• Hash raw snapshot payloads directly: rejected because transport noise and ordering differences would create unstable findings.
• Build a separate RBAC-only diff normalizer: rejected because the existing normalizer already captures the governance-relevant fields required by the spec.

Decision: Keep unified baseline.compare finding lifecycle and recurrence behavior

Rationale: CompareBaselineToTenantJob::upsertFindings() already provides profile-scoped recurrence keys, idempotent times_seen updates, reopen behavior, and baseline auto-close support. The RBAC feature should plug into that same lifecycle so findings behave consistently with the rest of the drift engine.

Alternatives considered:

• Introduce an RBAC-specific finding table or source lifecycle: rejected because it would duplicate the compare engine and break existing findings surfaces.
• Make recurrence snapshot-scoped for RBAC only: rejected because the current implementation and tests are profile-scoped, and the new spec only requires baseline profile participation in the fingerprint inputs.

Decision: Extend the existing evidence contract instead of inventing an RBAC-only UI model

Rationale: Existing baseline compare evidence already carries summary kind, provenance, baseline and current version references, and diff-compatible structures consumed by findings and run-detail surfaces. RBAC compare should extend those contracts with an RBAC-specific summary kind and before/after normalized evidence so existing UI surfaces can render the new findings without a dedicated page.

Alternatives considered:

• Render RBAC changes from ad-hoc JSON blobs in the UI: rejected because it would bypass the unified finding evidence contract and create fragile presentation logic.
• Create a new RBAC findings screen: rejected because the spec explicitly requires compatibility with existing baseline, drift, and findings surfaces.

Decision: Reuse existing coverage-guard and partial-success semantics for RBAC safe degradation

Rationale: CompareBaselineToTenantJob already suppresses findings for uncovered types and records partial-success outcomes with coverage reason codes. RBAC compare should use the same mechanism so missing provider or permission coverage produces a clear run/report warning without emitting false drift.

Alternatives considered:

• Emit missing findings when current RBAC data is unavailable: rejected because it would create false drift.
• Fail the entire compare run hard on any RBAC coverage gap: rejected because the current engine already supports safer partial-success semantics with explicit suppression reasons.