TenantAtlas/specs/429-exchange-teams-source-surface-catalog-adapter-strategy/catalog/cohort-plan.md

# Cohort Plan

Spec 429 catalog status: documentation only. Cohort membership is implementation sequencing guidance for later specs, not runtime support or customer claim vocabulary.

## Selection Principles

- Include both Exchange and Teams in Cohort 1.
- Prefer tenant-level or policy-level configuration over per-user, per-mailbox, content, transcript, file, phone-number, or message surfaces.
- Prefer source surfaces with official Microsoft documentation and a plausible read-only adapter path.
- Preserve current repo truth: no Cohort 1 item is evidence-ready until a later runtime spec implements and tests a source adapter/contract.
- Keep Purview/Defender/SharePoint/OneDrive boundary items out of Cohort 1 unless a later spec explicitly shifts ownership.
- Do not select unknown, unsupported/manual-only, portal-only, beta-only certification blockers, or source-unclear types.

## Cohort 1 Selected

15 candidates are selected. This fits the 12-20 target guidance and includes both Exchange and Teams.

| Order | Canonical type | Workload | Source surface class | Adapter pattern | Why selected | First blocker to clear |
| ---: | --- | --- | --- | --- | --- | --- |
| 1 | `transportRule` | Exchange | `exchange_online_powershell_rest` | `new_exchange_powershell_adapter` | High-value mail-flow configuration; already has repo identity/redaction helper proof but no source adapter. | Implement safe Exchange PowerShell read adapter and prove no mail-content exposure. |
| 2 | `acceptedDomain` | Exchange | `exchange_online_admin_api` | `new_exchange_admin_api_contract` | High-value domain posture; natural-key candidate and Admin API focused scenario. | Decide Admin API preview use vs PowerShell fallback; preserve blocked runtime state until proven. |
| 3 | `remoteDomain` | Exchange | `exchange_online_powershell_rest` | `new_exchange_powershell_adapter` | External automatic reply/format/forwarding controls have governance value without mailbox-content capture. | Implement allowed `Get-RemoteDomain` style read path. |
| 4 | `organizationConfig` | Exchange | `exchange_online_admin_api` | `new_exchange_admin_api_contract` | Tenant singleton baseline with high MSP value. | Limit to focused Admin API/PowerShell safe fields. |
| 5 | `mailboxPlan` | Exchange | `exchange_online_powershell_rest` | `new_exchange_powershell_adapter` | Configuration-oriented recipient boundary without per-mailbox explosion. | Prove least-privilege read path and source identity. |
| 6 | `inboundConnector` | Exchange | `exchange_online_powershell_rest` | `new_exchange_powershell_adapter` | Mail routing/security posture is customer-visible and operationally important. | Redact smart-host/domain/cert details appropriately. |
| 7 | `outboundConnector` | Exchange | `exchange_online_powershell_rest` | `new_exchange_powershell_adapter` | Complements inbound connector for mail-flow posture. | Redact routing and security metadata. |
| 8 | `sharingPolicy` | Exchange | `exchange_online_powershell_rest` | `new_exchange_powershell_adapter` | External collaboration setting with meaningful review value. | Validate external-domain redaction and stable identity. |
| 9 | `appPermissionPolicy` | Teams | `teams_powershell` | `new_teams_powershell_adapter` | High-value app governance; previously reviewed and blocked only by missing adapter. | Implement Teams PowerShell fake-runner proof and app-list redaction. |
| 10 | `appSetupPolicy` | Teams | `teams_powershell` | `new_teams_powershell_adapter` | Pinning/install policy is high-value and pairs naturally with app permission posture. | Account for app-centric management migration state. |
| 11 | `meetingPolicy` | Teams | `teams_powershell` | `new_teams_powershell_adapter` | High-risk meeting/recording/transcription governance; previously reviewed and blocked only by missing adapter. | Prove config-only capture and no recording/transcript/chat content. |
| 12 | `messagingPolicy` | Teams | `teams_powershell` | `new_teams_powershell_adapter` | Core collaboration policy with high MSP review value. | Prove no message/chat content capture. |
| 13 | `teamsUpdateManagementPolicy` | Teams | `teams_powershell` | `new_teams_powershell_adapter` | Moderate complexity and useful client governance posture. | Prove source shape and identity. |
| 14 | `teamsChannelsPolicy` | Teams | `teams_powershell` | `new_teams_powershell_adapter` | Policy-level channel governance without channel content. | Keep separate from Graph channel inventory/content. |
| 15 | `externalAccessPolicy` | Teams | `teams_powershell` | `new_teams_powershell_adapter` | External collaboration control is high value for customer/MSP review. | Redact external domains and cross-cloud metadata. |

## Cohort 2 Candidates

| Canonical type | Workload | Reason not Cohort 1 |
| --- | --- | --- |
| `transportConfig` | Exchange | Broad tenant singleton. Useful, but should follow adapter proof for rules/domains/connectors. |
| `sharedMailbox` | Exchange | Per-mailbox enumeration and PII risk; needs stricter scope/redaction review. |
| `managementRoleAssignment` | Exchange | Privileged RBAC data; requires dedicated security and audit review. |
| `tenantFederationConfiguration` | Teams | External/cross-tenant semantics overlap Entra and require additional boundary review. |
| `voiceRoute` | Teams | Voice licensing, PSTN, geography, and phone-number sensitivity make it too complex for first slice. |
| `teamsCallingPolicy` | Teams | Calling policy scope has license and emergency/voice complexity; should follow Teams policy adapter proof. |

## Deferred Backlog

| Canonical type | Boundary reason |
| --- | --- |
| `dlpCompliancePolicy` | Purview/Security & Compliance boundary; existing repo truth keeps it missing-contract blocked. |
| `labelPolicy` | Purview/Security & Compliance boundary. |
| `retentionCompliancePolicy` | Purview/Security & Compliance boundary and retention/customer-output sensitivity. |
| `teamsTeam` | Graph inventory/collaboration structure, not policy coverage; can explode into group/channel/file semantics. |
| `teamsChannel` | Graph channel inventory is content-adjacent and must not capture messages/files. |
| `teamsFileStorageIntegration` | SharePoint/OneDrive ownership boundary; needs separate source-surface catalog. |

## Unsupported / Unknown

| Category | Handling |
| --- | --- |
| Portal-only Teams or Exchange setting with no safe official automation source | `unsupported`; do not implement in Spec 430. |
| Unknown Teams/Exchange policy candidate | `unknown_requires_research`; keep blocked until official source docs and repo ownership are clear. |
| Microsoft cmdlet that performs operational action rather than durable configuration read | `unsupported_manual_only`; do not map as a target type. |

## Recommended Spec 430 Scope

The first runtime follow-up should not implement all 15 Cohort 1 candidates at once.

Recommended first slice:

1. Implement `new_exchange_powershell_adapter` as a read-only, command-allowlisted adapter with fake command-runner unit tests and no real shell execution in unit tests.
2. Use it for exactly `transportRule`, `remoteDomain`, and one connector type (`inboundConnector` or `outboundConnector`) to prove collection capture, identity, redaction, and blocked/permission-denied/source-unavailable distinctions.
3. Keep `acceptedDomain` and `organizationConfig` in the design as Admin API candidates, but do not depend on the preview Admin API for the first adapter proof unless the spec explicitly accepts preview/internal-only limits.
4. After Exchange adapter proof, implement a separate `new_teams_powershell_adapter` slice for `appPermissionPolicy`, `appSetupPolicy`, and `meetingPolicy`.

If Spec 430 must cover both workloads in one PR, reduce the first Exchange and Teams sets to two types each and keep all other Cohort 1 items as documented follow-up.

## No-Promotion Rule

Cohort placement never changes:

- coverage level
- evidence state
- support state
- claim state
- restore tier
- certification state
- customer output eligibility
- UI status
- OperationRun behavior

Only a later runtime spec with tests may change those values.