TenantAtlas/specs/426-exchange-teams-core-evidence-identity-readiness/spec.md

Feature Specification: Spec 426 - Exchange / Teams Core Evidence & Stable Identity Readiness

Feature Branch: 426-exchange-teams-core-evidence-identity-readiness Created: 2026-07-02 Status: Draft Input: User-provided candidate: "Spec 426 - Exchange / Teams Core Evidence & Stable Identity Readiness"

Selection And Preflight

• Selected candidate: Spec 426 - Exchange / Teams Core Evidence & Stable Identity Readiness.
• Source: Direct user-provided draft in the 2026-07-02 session.
• Why selected: Spec 425 completed the Entra certified compare pack at current HEAD (33e496c1 feat: complete spec 425 enta certified compare pack (#492)). Exchange/Teams certification was intentionally blocked because source-backed evidence and stable identity are not ready for the four mandatory denominator types.
• Roadmap relationship: Explicit manual promotion outside the empty auto-prep queue in docs/product/spec-candidates.md. It continues the Coverage v2 / M365 maturity path after Specs 414, 415, 417, 418, 419, 420, 422, and 425.
• Close alternatives deferred: Spec 427 Exchange / Teams Verified Source Contract Enablement, Spec 428 content-backed evidence promotion, Spec 429 compare/render promotion, later Exchange / Teams Certified Compare Pack, Exchange restore/apply, Teams restore/apply, customer reports, Review Pack output, management PDF output, broad Exchange/Teams/M365 coverage claims, optional Exchange/Teams resource expansion, and Security/Compliance certification.
• Completed-spec guardrail result: Specs 414, 415, 417, 418, 419, 420, 422, and 425 are completed dependency context only. Their close-out history, validation results, browser proof, and task completion markers must not be rewritten by this spec.
• Pre-implementation preflight evidence:
  • CoverageSourceContractResolver maps conditionalAccessPolicy, securityDefaults, deviceAndAppManagementAssignmentFilter, notificationMessageTemplate, and roleScopeTag.
  • CoverageSourceContractResolver explicitly lists acceptedDomain and appPermissionPolicy as Spec 420 missing-contract blockers.
  • transportRule and meetingPolicy do not currently have explicit source contract mappings.
  • CoverageIdentityStrategyRegistry has stable strategies for conditionalAccessPolicy and securityDefaults, but not for transportRule, acceptedDomain, appPermissionPolicy, or meetingPolicy.
  • ExchangeTeamsComparablePayloadNormalizer, ExchangeTeamsCoverageComparator, and ExchangeTeamsRenderableSummaryBuilder support the four target types for content-backed or synthetic/existing rows from Spec 422.
  • GenericContentEvidenceCaptureService, CoverageResourceUpserter, and CoverageEvidenceWriter already provide the shared capture/resource/evidence path with workspace, managed-environment, provider-connection, OperationRun, raw payload, normalized payload, and payload hash storage.
  • Current capture outcome enum values include capture_blocked_missing_contract, capture_blocked_permission, capture_blocked_beta, capture_blocked_unsupported, and capture_failed. Spec wording must use repo-canonical values or deliberately amend enums/tests; it must not create a parallel status family.
• Hard implementation preflight: Before runtime code changes, implementation must re-check current source/tests and stop if Coverage v2 generic capture, canonical identity, Graph contract path, OperationRun-backed capture, or workspace/environment/provider ownership infrastructure is missing.

Post-Review Source Contract Correction (2026-07-02)

Strict review found that the initially proposed Graph v1.0 resource paths for the four mandatory Exchange/Teams types were not production-safe source contracts. mailFlowRule, acceptedDomains, teamsAppPermissionPolicy, and teamsMeetingPolicy must not be registered as Microsoft Graph v1.0 capture endpoints unless a future implementation proves a real repo-canonical provider contract for them.

This correction supersedes earlier implementation wording that claimed the four mandatory types were source-backed in this branch:

• transportRule, acceptedDomain, appPermissionPolicy, and meetingPolicy remain in scope as the required denominator, but source capture for them MUST fail closed as capture_blocked_missing_contract until a verified source contract exists.
• Missing-contract capture MUST NOT call ProviderGateway/GraphClientInterface, MUST NOT create TenantConfigurationResource rows, and MUST NOT create fake per-resource evidence.
• Stable identity strategies may be prepared for future valid source payloads, but Identity/name-like values are not stable identity for these types. Preferred stable IDs are provider/source IDs such as id, sourceId, Guid, RuleId, or policyId; acceptedDomain may use DomainName/domainName as the documented natural key when source-backed.
• The final Spec 426 source-backed evidence readiness gate is therefore FAIL-safe / blocked, not source-ready. Spec 426 closure may be PASS WITH CONDITIONS only when the condition states that this branch proves fail-safe behavior and does not prove readiness, capture support, compare support, render support, or certification. A later spec or amended implementation must introduce verified source contracts before any certification work can proceed.

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

• Problem: Exchange/Teams compare/render support exists only for content-backed synthetic or existing rows. The mandatory certification denominator cannot be trusted because live/source-contract-backed evidence and stable identity are missing for all four required resource types.
• Today's failure: TenantPilot could over-read Exchange/Teams typed compare/render support as certification readiness even though transportRule, acceptedDomain, appPermissionPolicy, and meetingPolicy do not all have source contracts, content-backed capture proof, or stable identity strategies.
• User-visible improvement: Internal operators and release reviewers can see that the four Exchange/Teams core types do not yet have verified source contracts, fail closed without fake evidence, and have hardened identity strategies ready for future valid source payloads, while certification, restore, customer claims, and broad workload claims remain blocked.
• Smallest enterprise-capable version: Remove unverified source mappings, prove missing-contract capture fails closed for exactly exchange.transportRule, exchange.acceptedDomain, teams.appPermissionPolicy, and teams.meetingPolicy, harden stable identity strategies, preserve typed normalization/hash/redaction proof, and keep Claim Guard blockers.
• Explicit non-goals: No certification, no certified coverage level assignment, no Exchange/Teams Certified Compare Pack, no restore/apply/assisted restore, no customer-facing report, no Review Pack output, no management PDF output, no Exchange dashboard, no Teams dashboard, no new route/navigation, no Exchange/Teams table family, no mini-platform, no optional resource expansion, no tenant_id, no v1 compatibility, no migration of old snapshots.
• Permanent complexity imported: Four identity strategy entries, typed source-payload normalization alignment, focused capture/identity/claim/redaction tests, and implementation-report matrices. No new persisted entity/table/framework is allowed.
• Why now: Spec 425 proves the certification bar for Entra. The next Exchange/Teams certification attempt is unsafe until the denominator has real source contracts, content-backed evidence, and stable identity.
• Why not local: Certification readiness is a shared Coverage v2 truth problem. A page-local parser or one-off capture path would bypass source contracts, provider scope, canonical identity, OperationRun, redaction, and Claim Guard.
• Approval class: Core Enterprise.
• Red flags triggered: New source mappings and identity strategies, plus typed normalization alignment. Defense: these are narrow extensions of existing Coverage v2 registries/services for four concrete resource types and directly prevent unsafe certification/customer/restore claims.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 1 | Produktnaehe: 2 | Wiederverwendung: 2 | Gesamt: 11/12
• Decision: approve as a prerequisite unblocker only.

Spec Scope Fields (mandatory)

• Scope: Workspace + managed-environment scoped Coverage v2 capture/evidence/identity/readiness behavior for exactly four Microsoft 365 resource types.
• Primary Routes: None by default. Existing Coverage v2 internal/operator surface only if implementation proves a small rendered readiness update is strictly needed and amends this spec/plan/tasks before UI edits.
• Data Ownership: Existing Coverage v2 records only: TenantConfigurationResourceType, TenantConfigurationResource, TenantConfigurationResourceEvidence, TenantConfigurationSupportedScope, and existing OperationRun linkage. Environment-owned records stay scoped by workspace_id, managed_environment_id, and same-scope provider_connection_id.
• RBAC: Existing capture/readiness authorization applies. Non-member workspace or missing managed-environment entitlement returns 404. Established member without capability returns 403. Readonly cannot start capture. Provider connections must belong to the same workspace and managed environment.

For canonical-view specs:

• Default filter behavior when tenant-context is active: N/A - no new canonical route or route filter.
• Explicit entitlement checks preventing cross-tenant leakage: All capture/evidence/readiness lookup paths must resolve through workspace + managed environment + provider connection scope and must not use provider-native tenant identifiers as ownership truth.

No Legacy / No Backward Compatibility Constraint (mandatory)

TenantPilot is pre-production unless this spec explicitly records a compatibility exception.

• Compatibility posture: canonical Coverage v2 extension; no compatibility exception.
• Legacy aliases, fallback readers, hidden routes, duplicate UI, old labels, or historical fixtures kept?: no.
• Why clean replacement is safe now: This is a new internal readiness slice over active Coverage v2 services. No production data or external contract requires Coverage v1 adapters, fallback readers, dual writes, or old customer-facing coverage vocabulary.

Mandatory Resource Scope

Only these resource types are in scope:

Workload	Resource type	In scope?
Exchange	transportRule	yes
Exchange	acceptedDomain	yes
Teams	appPermissionPolicy	yes
Teams	meetingPolicy	yes

Explicitly out of scope: remoteDomain, organizationConfig, sharedMailbox, mailboxPlan, mailbox, mailboxPermission, mail-flow connector resources, appSetupPolicy, messagingPolicy, teamsUpdateManagementPolicy, voiceRoute, callingPolicy, emergencyCallingPolicy, meetingConfiguration, Teams channels/messages/files/recordings/transcripts, and all other Exchange/Teams/M365 types.

No silent expansion is allowed. Helper context may be used internally only when needed by an approved source contract and must not become a registered in-scope or certified resource type.

Primary Operators And User Stories

Primary operators: internal TenantPilot platform operators, release reviewers, and implementation reviewers preparing a later Exchange/Teams certification pass. No customer-facing operator workflow is introduced by this spec.

User Story 1 - Release Reviewer Sees A Safe Certification Prerequisite

As a release reviewer, I need objective evidence that the four Exchange/Teams denominator types are not falsely source-backed and that identity is hardened before approving a later certification spec.

Acceptance: For each mandatory type, the implementation report and tests show missing-contract capture blocks, no provider call, no fake evidence, hardened stable identity rules for future valid source payloads, compare/render helper compatibility, and certified = false.

User Story 2 - Platform Operator Captures Evidence Without Scope Leakage

As a platform operator, I need provider capture for these resource types to stay workspace, managed-environment, and provider-connection scoped.

Acceptance: Non-member access returns 404, missing managed-environment entitlement returns 404, missing capability returns 403, readonly users cannot start capture, and cross-workspace/cross-environment provider connections are rejected.

User Story 3 - Implementation Reviewer Verifies Identity Stability

As an implementation reviewer, I need to prove that resource identity is stable and not based on display labels, ordering, payload hashes, operation runs, or random values.

Acceptance: All four identity strategies use stable source-backed identity inputs or a proven immutable natural key/composite, and invalid identity inputs block readiness.

User Story 4 - Security Reviewer Confirms No Overclaim Or Sensitive Exposure

As a security/release reviewer, I need readiness proof that cannot be mistaken for certification, restore readiness, full workload coverage, or customer-ready output.

Acceptance: Claim Guard blocks certification, restore, full Exchange/Teams/M365, and customer claims; redaction tests prove raw payloads, secrets, mail content, Teams content, and raw permission context are not logged or default-rendered.

Functional Requirements

Source Contracts

• FR-426-001: CoverageSourceContractResolver or the repo-canonical equivalent MUST NOT resolve any mandatory type to a source contract unless the contract is production-safe and verified. In this branch, all four mandatory types MUST fail closed as missing source contracts.
• FR-426-002: Source contracts MUST come from the existing contract registry/patterns and route through GraphClientInterface or the repo-canonical provider client abstraction.
• FR-426-003: Implementation MUST NOT build endpoints by string-concatenating resource type names, guess runtime endpoints, bypass GraphClientInterface, fetch documentation at runtime, or treat synthetic/test evidence as source proof.
• FR-426-004: Allowed source classes are tcm, graph_v1_fallback, and repo-canonical provider contracts. graph_beta_experimental is allowed only behind an explicit blocker and cannot pass certification-readiness.
• FR-426-005: Missing contract, missing permission, unsupported source, experimental-only source, source unavailable, and provider failure MUST produce safe blocked/failed outcomes using repo-canonical outcome values.
• FR-426-006: Empty collections count as successful source-contract capture proof only when the source contract succeeded, permission was sufficient, provider response succeeded, and operation/capture proof exists. They MUST NOT create fake resource instances or fake per-resource evidence. In the current per-resource Coverage v2 evidence model, an empty collection does not satisfy per-resource content-backed readiness unless an existing repo-approved type-level evidence artifact can safely carry the explicit empty normalized payload and deterministic hash.

Evidence

• FR-426-007: All four mandatory types MUST remain on the existing generic/shared Coverage v2 capture path. Until verified contracts exist, capture MUST stop before provider calls and record only blocked outcomes, not resources or evidence.
• FR-426-008: Persisted evidence MUST include or preserve repo-equivalent fields: workspace_id, managed_environment_id, provider_connection_id, resource_id, resource_type_id, operation_run_id, source_contract_key, source_endpoint, source_version, source_schema_hash, source_metadata, raw_payload, normalized_payload, payload_hash, capture_outcome, evidence_state, and captured_at.
• FR-426-009: No tenant_id platform-core ownership field, fallback ownership alias, or dual ownership truth may be introduced.
• FR-426-010: Payload hashes MUST be deterministic: same normalized payload produces the same hash, volatile metadata is excluded where configured, material field changes change the hash, and unordered provider collections are normalized where semantics are unordered.
• FR-426-011: Fake, synthetic, missing-contract, missing-permission, failed, or skipped evidence MUST NOT count as source-backed evidence.
• FR-426-012: OperationRun context and summaries MUST remain sanitized: flat numeric summary_counts, no raw payloads, no secrets, no raw permission context, no mail/chat/file/recording/transcript content.

Stable Identity

• FR-426-013: CoverageIdentityStrategyRegistry or the repo-canonical equivalent MUST define stable identity strategies for transportRule, acceptedDomain, appPermissionPolicy, and meetingPolicy.
• FR-426-014: Preferred identity is a stable provider/source ID. A documented immutable natural key is allowed only when proven stable within provider/environment scope. A deterministic composite key is allowed only if every component is stable and source-backed.
• FR-426-015: Display name, localized label, array index, priority/order, payload hash, operation run ID, random generated UUID, enabled state, conditions/actions/settings hash, domain type, default flag, description, and app/settings hash MUST NOT be sole stable identity.
• FR-426-016: Source-backed payloads for all four types MUST reach stable identity. derived, identity_conflict, missing_external_id, or unsupported_identity blocks certification readiness.
• FR-426-017: CanonicalIdentityResolver MUST be used; implementation must not create a separate Exchange/Teams identity path.

Normalization And Compare/Render Readiness

• FR-426-018: Future verified source-backed payloads MUST normalize into the same comparable/renderable shape used by Spec 422, or through a strictly equivalent typed alignment step using existing ExchangeTeamsComparablePayloadNormalizer, ExchangeTeamsCoverageComparator, and ExchangeTeamsRenderableSummaryBuilder paths.
• FR-426-019: Persisted normalized_payload for the four target types MUST be typed enough for deterministic hashing and compare/render proof. If implementation retains a generic payload envelope, it must include the typed comparable shape or prove the typed shape is deterministically derived before hash/readiness evaluation.
• FR-426-020: Normalized payloads MUST include or derive resource_type/canonical_type, workload, source identity, safe display label, source contract, source class, material fields, unsupported-field diagnostics, and volatile-field exclusions. Capture timestamps MUST remain evidence metadata such as captured_at and MUST NOT be part of the normalized material payload or payload hash.
• FR-426-021: transportRule material fields include enabled/state, priority/order, conditions, actions, exceptions, mode/enforcement state, and scope where present.
• FR-426-022: acceptedDomain material fields include domain name, domain type, default-domain flag, and state where present.
• FR-426-023: appPermissionPolicy material fields include policy ID, display name, allowed apps, blocked apps, policy mode, and assignment/target summary when available from the same approved source.
• FR-426-024: meetingPolicy material fields include policy ID, display name, external/anonymous access, recording/transcription, lobby/admission, content sharing, and meeting chat/settings where present.
• FR-426-025: Unknown source-backed fields MUST be recorded as unsupported-field diagnostics and cannot be silently ignored when material to readiness.
• FR-426-026: The final readiness matrix may report compare_render_ready for the four types as a derived assertion from existing Coverage v2 evidence, identity, and compare/render proof. It MUST NOT introduce a new persisted readiness boolean/status family and MUST NOT report or assign certified.

Claim Guard And Safety

• FR-426-027: Claim Guard MUST allow only internal/operator readiness wording when evidence, identity, and compare/render proof pass.
• FR-426-028: Claim Guard MUST block Certified Exchange / Teams Core Compare Pack, Certified Exchange, Certified Teams, full Exchange coverage, full Teams coverage, certified Microsoft 365 coverage, Exchange restore-ready, Teams restore-ready, and customer-ready Exchange/Teams proof.
• FR-426-029: For all four mandatory types after this post-review correction, the implementation report/readiness matrix MUST derive: content_backed = false, identity_strategy_hardened = true, compare_render_ready = false, certified = false, restore_ready = false, and customer_claimable = false. Future source-backed readiness requires verified contracts and a separate PASS gate.
• FR-426-030: Raw provider responses, raw payloads, access tokens, refresh tokens, ID tokens, client secrets, private keys, certificates, authorization headers, cookies, bearer tokens, mail body/subject content, Teams chat/message/file/recording/transcript content, and raw permission context MUST NOT be logged or default-rendered.

Non-Functional Requirements

• NFR-426-001 Security and privacy: Logs, OperationRun context, rendered output, diagnostics, and implementation reports must not expose secrets, authorization material, raw provider responses, raw permission context, mail content, Teams chat/message/file/recording/transcript content, recordings, or transcripts.
• NFR-426-002 Determinism: Source-backed normalization, identity resolution, and payload hashing must be deterministic for the same provider payload after volatile-field exclusion and semantic ordering normalization.
• NFR-426-003 Performance and provider cost: Remote provider work must remain limited to the four mandatory resource types, run through the existing OperationRun-backed capture path, and avoid compare/render-time provider calls.
• NFR-426-004 Observability: Capture outcomes, evidence states, identity states, unsupported-field diagnostics, OperationRun linkage, and final blocker reasons must be explicit enough for release review without raw payload exposure.
• NFR-426-005 Maintainability: The implementation must extend existing Coverage v2 registries/services and avoid new table families, mini-platforms, broad provider frameworks, or parallel enum/status taxonomies.
• NFR-426-006 Test isolation: Tests must use fake provider responses and local fixtures only; no real provider calls, runtime documentation fetches, or network-dependent certification proof are allowed.

UI Surface Impact (mandatory - UI-COV-001)

Does this spec add, remove, rename, or materially change any reachable UI surface?

• No UI surface impact
• Existing page changed
• New page/route added
• Navigation changed
• Filament panel/provider surface changed
• New modal/drawer/wizard/action added
• New table/form/state added
• Customer-facing surface changed
• Dangerous action changed
• Status/evidence/review presentation changed
• Workspace/environment context presentation changed

Default decision: no new runtime UI surface and no rendered UI change. A tiny update to the existing Coverage v2 internal/operator surface is allowed only if implementation proves it is strictly needed, and only after this spec, plan, and tasks are amended before editing UI files. New Exchange/Teams dashboard, route, navigation, customer surface, certify action, restore/apply action, report, Review Pack output, export, or PDF output is forbidden.

UI/Productization Coverage (mandatory when UI Surface Impact is not "No UI surface impact"; otherwise write N/A - no reachable UI surface impact plus rationale)

• Route/page/surface: N/A - no reachable UI surface impact by default.
• Current or new page archetype: N/A.
• Design depth: N/A.
• Repo-truth level: N/A.
• Existing pattern reused: Existing Coverage v2 services and tests; no rendered surface change.
• New pattern required: none.
• Screenshot required: no unless runtime UI is amended into scope.
• Page audit required: no.
• Customer-safe review required: negative proof only; no customer-facing output or claim may appear.
• Dangerous-action review required: no dangerous/high-impact action in scope.
• Coverage files updated or explicitly not needed:
  • docs/ui-ux-enterprise-audit/route-inventory.md
  • docs/ui-ux-enterprise-audit/design-coverage-matrix.md
  • docs/ui-ux-enterprise-audit/page-reports/...
  • docs/ui-ux-enterprise-audit/strategic-surfaces.md
  • docs/ui-ux-enterprise-audit/grouped-follow-up-candidates.md
  • docs/ui-ux-enterprise-audit/unresolved-pages.md
  • N/A - no reachable UI surface impact
• No-impact rationale when applicable: Evidence and identity readiness can be proven through shared services, persisted evidence, and tests without adding or changing a rendered surface.

Product Surface Impact (mandatory for UI-affecting specs; otherwise write N/A - no rendered product surface changed plus rationale)

Reference: docs/product/standards/product-surface-contract.md.

• Product Surface Contract applies?: no for default implementation; yes only if runtime UI is amended into scope.
• Page archetype: N/A.
• Primary user question: N/A.
• Primary action: N/A.
• Surface budget result: N/A.
• Technical Annex / deep-link demotion: Raw payloads, OperationRun links, source keys, provider IDs, permission context, and diagnostics remain service/test/internal proof only unless a future amended UI path demotes them behind existing internal details.
• Canonical status vocabulary: N/A for no rendered UI. If amended into UI, map to Product Surface vocabulary and never show certification, restore-ready, customer-ready, full Exchange, full Teams, or M365 certified claims.
• Visible complexity impact: neutral by default.
• Product Surface exceptions: none.

Browser Verification Plan (mandatory)

• Browser proof required?: no by default; yes if runtime UI files or rendered readiness output change.
• No-browser rationale: N/A - no rendered UI surface changed.
• Focused path when required: Existing Coverage v2 readiness/operator route with seeded workspace, managed environment, provider connection, and the four blocked missing-contract Exchange/Teams outcomes with no resource/evidence rows.
• Primary interaction to execute: If UI changes are amended in, load the existing route, inspect blocked source-contract readiness, verify certification/restore/customer-ready/raw/secrets/mail/chat/content absent, and verify no console/Livewire/Filament errors.
• Console, Livewire, Filament, network, and 500-error checks: required only if browser proof is required.
• Full-suite failure triage: unrelated failures must be documented only after focused proof is green.

Human Product Sanity Check (mandatory)

• Required?: no by default; yes if rendered UI changes.
• No-human-sanity rationale: N/A - no product surface changed.
• Reviewer questions: If amended into UI, reviewers must verify readiness is not confused with certification, restore readiness, full workload coverage, or customer proof; raw/technical details are demoted; and visible complexity is neutral or lower.
• Planned result location: implementation report if UI changes; otherwise N/A.

Product Surface Merge Gate Checklist (mandatory)

• No-legacy posture or approved exception recorded.
• Product Surface Impact is completed or N/A is justified.
• Browser proof is completed or N/A - no rendered UI surface changed is justified.
• Human Product Sanity is completed or not applicable with rationale.
• Product Surface exceptions are documented or none.
• Implementation report will state Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, tests/browser result, deployment impact, visible complexity outcome, and no completed-spec rewrite assertion.

Cross-Cutting / Shared Pattern Reuse (mandatory)

• Cross-cutting feature?: yes.
• Interaction class(es): evidence capture, identity, claim wording, compare/render readiness, redaction, provider contract handling.
• Systems touched: CoverageSourceContractResolver, config/graph_contracts.php, GenericContentEvidenceCaptureService or equivalent capture path, CoverageIdentityStrategyRegistry, CanonicalIdentityResolver, CoverageResourceUpserter, CoverageEvidenceWriter, ExchangeTeamsComparablePayloadNormalizer, ExchangeTeamsCoverageComparator, ExchangeTeamsRenderableSummaryBuilder, ClaimGuard, ProviderGateway, and focused tests.
• Existing pattern(s) to extend: Coverage v2 source contract, capture/evidence, identity, redaction, read-model, and Claim Guard paths.
• Shared contract / presenter / builder / renderer to reuse: Existing Tenant Configuration/Coverage v2 services. Do not create a separate Exchange/Teams engine.
• Why the existing shared path is sufficient or insufficient: Existing paths already own scope, provider connection, OperationRun, evidence rows, identity evaluation, redaction, and compare/render adapters. This branch keeps the four concrete source contracts blocked until verified provider contracts exist, adds stable identity strategies, and preserves typed normalization helper proof for future source-backed payloads.
• Allowed deviation and why: A small typed normalization adapter or capture-normalization handoff is allowed if the current generic normalizer cannot persist the Spec 422 comparable shape.
• Consistency impact: Outcome, evidence, identity, claim, source, and compare/render states must stay aligned with Coverage v2 enums and Claim Guard.
• Review focus: No endpoint guessing, no direct HTTP, no display-name identity, no fake evidence, no certification, no restore, no customer output, no raw payload/default proof, no tenant_id, no mini-platform.

OperationRun UX Impact (mandatory when touched)

• Touches OperationRun start/completion/link UX?: no new UI start/completion/link UX.
• Shared OperationRun UX contract/layer reused: Existing capture OperationRun behavior only; no local UI composition.
• Delegated start/completion UX behaviors: N/A - no new start action. If an existing capture workflow is reused, it must continue to use the shared OperationRun path.
• Local surface-owned behavior that remains: none.
• Queued DB-notification policy: no new queued DB notification policy.
• Terminal notification path: existing central lifecycle mechanism only.
• Exception required?: none.

Remote/provider capture is OperationRun-backed. Allowed operation type is existing tenant_configuration.capture or a repo-canonical equivalent. No raw payload, permission context, secrets, or mail/chat/content may enter OperationRun context/messages/notifications.

Provider Boundary / Platform Core Check (mandatory when touched)

• Shared provider/platform boundary touched?: yes.
• Boundary classification: mixed. Source contracts and Exchange/Teams payload semantics are provider-owned. Coverage v2 evidence, identity state, claim state, read/model readiness, scope, and redaction are platform-core.
• Seams affected: graph contracts, source contract resolver, provider client path, identity strategies, typed normalization, compare/render readiness, Claim Guard wording, and evidence metadata.
• Neutral platform terms preserved or introduced: workspace, managed environment, provider connection, resource type, source contract, evidence, identity, claim, capture outcome, coverage level, compare/render readiness.
• Provider-specific semantics retained and why: Exchange and Teams resource names and payload fields are necessary to interpret the four mandatory source-backed types.
• Why this does not deepen provider coupling accidentally: No provider-native tenant ID ownership, no Exchange/Teams table family, no provider framework, no new dashboard/surface, no customer output, no restore/apply, and no certification in this spec.
• Follow-up path: Spec 427 must verify or keep blocked the exact four Exchange/Teams source contracts. Spec 428 may promote content-backed evidence only after verified contracts exist. Spec 429 may promote compare/render only after source-backed evidence exists. Exchange/Teams certification remains a later separate spec after those gates pass. Optional resource expansion, restore, customer reports, Review Pack/PDF output, and broader M365 certification require separate specs.

UI / Surface Guardrail Impact (mandatory when operator-facing surfaces are changed; otherwise write N/A)

N/A - no operator-facing surface change by default. If implementation amends UI into scope, reuse the existing Coverage v2 internal/operator Technical Annex surface only and complete the Product Surface/browser/human sanity requirements before editing runtime UI files.

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

N/A - no operator-facing surface change by default.

Audience-Aware Disclosure (mandatory when operator-facing surfaces are changed)

N/A - no operator-facing surface change by default. If amended, raw payloads, provider IDs, permission context, unsupported internals, source keys, OperationRun details, and provider diagnostics must remain hidden, collapsed, or support-gated.

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

N/A - no operator-facing surface change by default.

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

N/A - no operator-facing surface change by default.

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: no. Evidence remains existing Coverage v2 resource/evidence truth.
• New persisted entity/table/artifact?: no.
• New abstraction?: no new broad abstraction. Existing registries/resolvers/normalizers may be extended narrowly for four concrete types. A small typed capture-normalization adapter is allowed only if existing normalizers cannot safely align source payloads to Spec 422 shape.
• New enum/state/reason family?: no by default. Use existing CaptureOutcome, EvidenceState, IdentityState, CoverageLevel, and ClaimState values. Enum/status additions require amendment and tests.
• New cross-domain UI framework/taxonomy?: no.
• Current operator problem: Exchange/Teams certification remains blocked because source-backed evidence and stable identity are unproven for the exact required denominator.
• Existing structure is insufficient because: Spec 422 typed compare/render helpers do not prove live/source-backed capture or stable canonical identity. Current source resolver and identity registry lack the four required entries.
• Narrowest correct implementation: Keep the four missing source contracts fail-closed until verified provider contracts exist, add four identity strategies for future valid source payloads, preserve typed normalization alignment, and add claim/redaction/no-overclaim tests; no new tables, UI, restore, certification, or customer output.
• Ownership cost: Four identity strategies, typed normalization/hash/redaction guards, and focused source-blocker tests must be maintained with future provider contract changes.
• Alternative intentionally rejected: Certify based on Spec 422 synthetic/existing rows or display-name identity. That would create unsafe overclaims and unstable resource matching.
• Release truth: Current-release prerequisite unblocker for a later certification spec.

Compatibility posture

This feature assumes a pre-production environment. Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope.

Testing / Lane / Runtime Impact (mandatory for runtime behavior changes)

• Test purpose / classification: Unit for source contract resolver, capture eligibility, identity strategy, canonical identity, payload normalization, evidence hash, Claim Guard, and redaction. Feature for blocked capture with no fake evidence/readiness rows, OperationRun linkage, provider scope, no certification, no restore, no customer claim, no tenant_id, and no mini-platform. Browser only if UI changes.
• Validation lane(s): fast-feedback for Unit/Feature; browser conditional; Pint dirty; diff check.
• Why this classification and these lanes are sufficient: The behavior is service, DB, contract, identity, and claim safety. Browser proof is needed only when rendered UI changes.
• New or expanded test families: Spec426 TenantConfiguration Unit/Feature tests and focused fixtures only.
• Fixture / helper cost impact: Add minimal fake provider payloads for four resource types. Avoid broad default workspace/provider helper expansion.
• Heavy-family visibility / justification: none unless UI is amended into scope.

Acceptance Criteria

Source Contracts

• transportRule, acceptedDomain, appPermissionPolicy, and meetingPolicy fail closed as missing contracts in this branch because no production-safe source contract has been verified.
• No hardcoded endpoint guessing, direct HTTP bypass, Graph SDK bypass outside repo abstraction, or runtime documentation fetch.
• Missing contract, missing permission, unsupported source, experimental source, source unavailable, and provider failure are safe blocked/failed outcomes.

Evidence

• All four types create no resource/evidence rows while their source contracts are missing.
• raw_payload, typed/usable normalized_payload, deterministic payload_hash, source metadata, capture outcome, evidence state, and operation_run_id remain required only when a verified future contract captures items.
• Empty collections are represented safely as source-contract capture proof when provider calls succeed, without fake resource instances or fake per-resource evidence.
• Fake/synthetic evidence never counts as source-backed.

Identity

• All four types have stable identity strategies and use CanonicalIdentityResolver.
• Display-name-only, array-index, priority/order-only, payload-hash-only, random UUID, and operation-run identity are impossible as stable identity.
• Identity conflict, missing external ID, unsupported identity, or derived-only identity blocks certification readiness.

Compare / Render Readiness

• Typed payload fixtures normalize into the Spec 422 compare/render-ready shape, but no source-backed compare/render readiness is claimed while contracts are missing.
• Unsupported fields are diagnostic and material unsupported fields block readiness.
• Existing Spec 422 compare/render pipeline remains valid.
• No certification is assigned.

Claim Guard

• Internal evidence-ready, stable-identity-ready, and compare/render-ready wording is allowed only when proven; this branch does not prove source-backed evidence readiness for the four mandatory types.
• Certified, restore-ready, full Exchange, full Teams, full M365, and customer-ready claims are blocked.

Architecture And Safety

• No tenant_id, no v1 adapter, no fallback reader, no dual write, no Exchange/Teams table family, no mini-platform, no new route/navigation/dashboard/customer output, and no restore/apply path.
• Raw payloads, secrets, permission context, mail content, and Teams content are not displayed/logged.
• Provider scope is enforced by workspace + managed environment + provider connection.

Validation

• Focused unit tests pass.
• Focused feature tests pass.
• Browser proof passes if UI changes.
• Pint dirty passes.
• git diff --check passes.

Success Criteria

• All four mandatory resource types remain blocked as missing source contracts until a verified source exists.
• All four mandatory resource types create no fake resources or fake evidence when capture is attempted without a verified contract.
• All four mandatory resource types have hardened identity strategies that reject display/name-like identity and prefer stable provider/source IDs or the approved accepted-domain natural key.
• Typed payload fixtures for all four types remain compatible with the existing Spec 422 compare/render pipeline, but no source-backed compare_render_ready result is claimed.
• Certification, restore readiness, customer claims, full Exchange/Teams claims, and full M365 claims remain blocked.
• No raw payload, secret, mail content, Teams content, raw permission context, tenant_id ownership path, Exchange/Teams table family, route/navigation/dashboard, customer output, or restore/apply path is introduced.

Risks

Risk	Severity	Mitigation
Certification wording or state sneaks in early	High	Claim Guard requirements, no-certification feature tests, and implementation-report proof require certified = false.
Fake/synthetic evidence is counted as source-backed	High	Source provenance tests and evidence requirements reject missing-contract, skipped, synthetic, or failed evidence as readiness proof.
Identity relies on display name, order, hash, or run ID	High	Identity strategy and canonical identity tests reject unstable identity inputs and block readiness.
Missing contract or missing permission is interpreted as empty configuration	High	Capture eligibility tests require blocked outcomes and explicit successful-empty-collection proof.
Raw payload, secrets, mail content, or Teams content leak into logs/UI/output	High	Redaction tests and OperationRun sanitization requirements block raw/default exposure.
Unsupported source-backed fields are silently ignored	High	Normalization tests require unsupported-field diagnostics and readiness blockers for material unsupported fields.
Workspace/environment/provider scope is crossed	High	Provider scope feature tests enforce same workspace, managed environment, provider connection, and RBAC semantics.
A separate Exchange/Teams platform grows inside Coverage v2	Medium	Architecture guard tests forbid new table families, routes, dashboards, reports, exports, PDFs, restore paths, and mini-platform surfaces.

Implementation Report Requirements

The implementation report MUST include:

• Candidate gate result.
• Dirty state before/after.
• Files changed.
• Source contract matrix.
• Evidence matrix.
• Identity matrix.
• Compare/render readiness matrix.
• Claim Guard proof.
• Redaction proof.
• No certification proof.
• No restore proof.
• No customer claim proof.
• No tenant_id confirmation.
• No mini-platform confirmation.
• Product Surface impact/no-impact.
• Tests run.
• Deferred work.

Required source/evidence/identity matrix:

Workload	Resource Type	Source Contract	Evidence	Identity	Compare/Render Ready	Certified?	Blocker
Exchange	transportRule					No
Exchange	acceptedDomain					No
Teams	appPermissionPolicy					No
Teams	meetingPolicy					No

Required claim matrix:

Claim	Allowed?	Reason
Exchange/Teams core evidence-ready	Yes, if proven	Internal/operator readiness only
Exchange/Teams core stable-identity-ready	Yes, if proven	Internal/operator readiness only
Certified Exchange / Teams Core Compare Pack	No	Deferred until verified source contracts, content-backed evidence, and compare/render promotion pass in later specs
100% Exchange coverage	No	Broad overclaim
100% Teams coverage	No	Broad overclaim
Certified Microsoft 365 coverage	No	Broad overclaim
Exchange restore-ready	No	Restore out of scope
Teams restore-ready	No	Restore out of scope
Customer-ready Exchange/Teams proof	No	Customer output deferred

Assumptions

• Specs 414, 415, 417, 418, 419, 420, 422, and 425 remain accepted/completed dependency context.
• Existing Coverage v2 generic capture and canonical identity services are the only allowed foundation path.
• Source contracts can be represented through repo contract registry patterns without direct HTTP or endpoint guessing.
• No runtime UI change is required for this prep package unless later implementation proves otherwise and amends artifacts first.

Open Questions

• Source contract support for all four mandatory types remains blocked until a future implementation proves production-safe provider contracts. This branch records the blocker instead of weakening evidence criteria or guessing endpoints.

Final Candidate Gate

Choose one in the implementation report: PASS, PASS WITH CONDITIONS, or FAIL.

PASS is not achieved by this branch. A future amended implementation can report PASS only when:

• all four mandatory source contracts resolve through approved source paths,
• all four mandatory types persist source-backed evidence,
• all four mandatory types have stable identity strategies,
• source-backed payloads are compare/render-ready,
• certification remains blocked,
• restore remains blocked,
• customer claims remain blocked,
• no raw/secrets/mail/chat/content exposure,
• no tenant_id ownership path,
• no Exchange/Teams mini-platform,
• focused tests pass.

PASS WITH CONDITIONS is allowed for this branch only as a closure gate when the implementation report states the condition explicitly: Spec 426 proves fail-safe behavior for Exchange/Teams source-backed evidence; it does not prove readiness, capture support, compare support, render support, or certification; typed normalizer/hash tests are future-contract helper proof only.

FAIL is required if missing source contracts are treated as source-backed, fake/synthetic evidence is counted as source-backed, display name is used as stable identity, certification/restore/customer output is introduced, broad coverage is claimed, raw/secrets/content leak, tenant_id is introduced, a mini-platform appears, or tests do not prove the fail-safe evidence + identity posture. This branch intentionally records PASS WITH CONDITIONS for Spec 426 closure while source-backed evidence readiness remains safely blocked because verified contracts are not available.

Follow-Up Spec Candidates

• Spec 427 - Exchange / Teams Verified Source Contract Enablement.
• Spec 428 - Exchange / Teams Content-Backed Evidence Promotion.
• Spec 429 - Exchange / Teams Compare/Render Promotion.
• Later spec - Exchange / Teams Certified Compare Pack.
• Security & Compliance certified/readiness hardening.
• M365 customer reporting Claim Guard pack.
• M365 pilot readiness gate.
• Exchange restore/apply.
• Teams restore/apply.
• Optional Exchange/Teams resource expansion.