astral/docs/m365-baseline-roadmap.md

M365 Baseline Expansion Roadmap

This document tracks the repository from its current implemented state rather than from the original proposal.

Current State

The repository already operates as a two-workload baseline system:

• Intune drift backup via IntuneCD
• Entra drift backup for Named Locations, Authentication Strengths, Conditional Access, App Registrations, and Enterprise Applications

The surrounding control loop is also implemented:

• hourly backup pipeline plus midnight Prague full run
• rolling PR per workload
• deterministic reviewer summary with optional Azure OpenAI narrative
• optional per-file change-ticket threads
• reviewer /reject and /accept decision sync every 20 minutes
• auto-remediation for rejected drift snapshots
• post-merge restore queue for partial-accept / partial-reject review flows
• selective historical restore from branch, tag, or commit
• output validation and drift-noise filtering before commit

What Is Stable Today

Stable and part of the normal operating model:

• Intune export and reporting
• Entra Named Locations export
• Entra Authentication Strengths export
• Entra Conditional Access export with reference-name enrichment
• object inventory and assignment reporting for both workloads
• Entra app inventory reporting
• drift-branch commit and rolling PR update workflow

Implemented, but intentionally constrained:

• App Registrations export is full-run only
• Enterprise Applications export is full-run only
• light runs preserve the previous committed snapshot for those two Entra categories

Not yet implemented:

• Directory role templates and active directory roles
• Exchange Online, Teams, SharePoint, Purview, and Azure governance modules

Current Gaps And Stabilization Backlog

1. Fix App Registrations light-run stability. The current pipeline still disables hourly App Registrations export because some runs produce resolver-only churn. Re-enabling hourly export requires a deterministic light-run result.

2. Keep Enterprise Applications scoped as a heavy module unless runtime proves otherwise. Enterprise Applications are already exported, but only on full runs. The current design assumes this category should remain bounded to the daily/full path unless runtime and diff quality support widening scope.

3. Add the next identity-baseline module only after Phase 1 is fully stable. Directory roles are the next logical addition, but they should follow the same pattern: deterministic export, report generation, validation, reviewer-noise filtering, and tests.

Design Rules For New Modules

Every expansion module should follow the conventions already used by Intune and Entra:

1. Store raw JSON under tenant-state/<workload-or-module>/.
2. Store human-review reports under tenant-state/reports/<workload-or-module>/.
3. Keep one object per file with deterministic naming and stable key ordering where possible.
4. Validate expected outputs before drift commit.
5. Filter known non-config churn before PR creation.
6. Update permissions, README, and tests in the same change.
7. Start as daily/full-run scope unless there is evidence it is safe and cheap to run hourly.

Roadmap By Phase

Phase 1: Identity Baseline

Completed:

• Entra Named Locations
• Entra Authentication Strengths
• Entra Conditional Access
• App Registrations exporter
• Enterprise Applications exporter

Remaining:

• stabilize App Registrations for light runs
• decide whether Enterprise Applications should remain full-run only
• add Directory Roles / Directory Role Templates

Phase 2: Service Policy Baseline

Candidate modules:

• Exchange Online transport and mail flow rules
• Defender for Office policy configuration
• Teams policy families
• SharePoint and OneDrive tenant-level sharing controls

Phase 3: Governance Baseline

Candidate modules:

• Purview DLP policies
• Purview retention labels and policies
• Azure policy assignments and initiatives
• Azure RBAC role assignments

Proposed Future Repository Shape

Keep the existing lowercase workload structure and extend it consistently:

tenant-state/
  intune/
  entra/
  exchange/
  teams/
  sharepoint/
  purview/
  azure-governance/
  reports/
    intune/
    entra/
    exchange/
    teams/
    sharepoint/
    purview/
    azure-governance/

Recommended Execution Order

1. Finish Phase 1 stabilization.
2. Add Directory Roles as the next identity module.
3. Add one Phase 2 or Phase 3 module at a time.
4. Require several stable daily cycles before widening scope or adding the next module.
5. Promote a module from full-run only to hourly only after unchanged tenants produce clean, low-noise diffs.

Acceptance Criteria

• No regression in current Intune or Entra backup success rate.
• Unchanged environments produce deterministic outputs across repeated runs.
• Reviewer PRs stay focused on configuration-effective drift, not enrichment noise.
• New modules document exact permissions and expected outputs.
• Restore and review workflows remain coherent as scope expands.