TenantAtlas/specs/423-security-compliance-readiness-pack/spec.md

Feature Specification: Spec 423 - Security and Compliance Readiness Pack

Feature Branch: 423-security-compliance-readiness-pack Created: 2026-06-30 Status: Draft Input: User-provided "Spec 423 - Security and Compliance Readiness Pack" draft plus repo checks against Specs 414-422, roadmap/candidate queue, constitution, Product Surface Contract, TenantPilot agent skill gates, and current TenantConfiguration Coverage v2 runtime.

Preparation Metadata

• Selected candidate: Spec 423 - Security and Compliance Readiness Pack.
• Source location: User attachment /Users/ahmeddarrazi/.codex/attachments/ac35bc16-b85d-4b3e-8202-efb18a8c733b/pasted-text.txt; related deferral anchors in specs/421-entra-core-comparable-renderable-pack/spec.md and specs/422-exchange-teams-comparable-renderable-pack/spec.md.
• Why selected: The active auto-prep queue in docs/product/spec-candidates.md remains empty, but the user explicitly promoted this bounded Coverage v2 follow-up. Specs 419-422 establish M365 registry, generic evidence, Entra comparable/renderable support, and Exchange/Teams comparable/renderable support. The next logical product-safety slice is a stricter Security and Compliance pack that supports compare/render/readiness without restore, certification, legal attestation, or customer claims.
• Roadmap relationship: Aligns with the roadmap themes for security posture, compliance evidence, evidence/coverage hardening, provider-boundary discipline, and safe M365 governance expansion. This package is not auto-selected from the queue; it is a user-promoted P0 Coverage v2 safety slice.
• Close alternatives deferred: Management-report runtime validation, governance artifact lifecycle retention, provider readiness productization, cross-domain indicator follow-through, system-panel browser fixture work, and first governed AI consumer remain manual-promotion backlog items. Security and Compliance restore/apply, certification, customer reports, legal/regulatory attestation, Review Pack output, and broad M365 claims are deferred to later explicit specs.
• Related completed-spec guardrail: specs/414-tcm-first-coverage-core-cutover/, specs/415-generic-content-backed-capture/, and specs/417-canonical-identity-engine/ through specs/422-exchange-teams-comparable-renderable-pack/ contain completed/validated signals and are read-only dependency context. Do not rewrite them, normalize their close-out history, or strip task/browser/review evidence.
• Prerequisite gate result: PASS for preparation. Repo truth includes TenantConfigurationResourceType, TenantConfigurationResource, TenantConfigurationResourceEvidence, TenantConfigurationSupportedScope, ResourceTypeRegistry, SupportedScopeResolver, ClaimGuard, GenericPayloadNormalizer, CoveragePayloadRedactor, CanonicalIdentityResolver, CoverageV2ReadinessReadModel, Entra and Exchange/Teams comparable/renderable patterns, and Security and Compliance registry rows.
• Smallest viable implementation slice: Add bounded Security and Compliance typed normalizers, comparators, render summaries, readiness/manual-review derivation, Claim Guard hardening, redaction, and tests for selected existing content-backed evidence rows. Mandatory first support is evidence-gated for retentionCompliancePolicy, labelPolicy, and dlpCompliancePolicy; autoSensitivityLabelPolicy, protectionAlert, and complianceTag may be promoted only when evidence exists and tests stay bounded.

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

• Problem: Security and Compliance Coverage v2 registry/evidence can exist without operator-safe interpretation. Operators would otherwise need raw payloads to decide whether retention, labeling, or DLP changes require review.
• Today's failure: TenantPilot can show registry/evidence truth for selected Security and Compliance resource types, but cannot safely answer what changed, whether the change is compliance-impacting, or whether manual review is required without risking restore-ready, certified, legal, or customer-ready overclaim.
• User-visible improvement: Authorized internal operators can inspect selected Security and Compliance evidence as structured compare/render/readiness summaries, with raw payloads hidden and high-risk changes clearly marked for manual review.
• Smallest enterprise-capable version: DB-only typed compare/render/readiness over existing content-backed evidence for retentionCompliancePolicy, labelPolicy, and dlpCompliancePolicy, with optional promotion of autoSensitivityLabelPolicy, protectionAlert, and complianceTag only when evidence and tests exist.
• Explicit non-goals: No restore/apply, no certification, no legal/regulatory attestation, no customer-facing reports, no Review Pack output, no new capture contracts, no new route/navigation/dashboard, no Purview or Security mini-platform, no new tables, no live Graph/TCM/docs calls.
• Permanent complexity imported: Focused typed normalizer/comparator/render-summary/readiness helpers, bounded derived readiness labels, Claim Guard phrase coverage, and focused unit/feature/browser-if-rendered tests. No new persistence, global taxonomy table, or cross-domain UI framework is planned.
• Why now: Specs 421 and 422 proved the comparable/renderable pattern for Entra, Exchange, and Teams and explicitly deferred Security and Compliance. The domain is high blast radius, so it needs a safety-first pack before any future customer or certification claims.
• Why not local: A local Purview/Security helper would bypass the existing Coverage v2 evidence, identity, redaction, read-model, and Claim Guard paths. The shared Coverage v2 path already exists and is the narrowest correct implementation.
• Approval class: Core Enterprise.
• Red flags triggered: New derived readiness labels for a high-risk domain. Defense: labels are derived, feature-local, non-persisted, and change operator manual-review behavior; they do not create a platform-wide taxonomy.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 1 | Produktnaehe: 2 | Wiederverwendung: 2 | Gesamt: 11/12
• Decision: approve.

Spec Scope Fields (mandatory)

• Scope: workspace.
• Primary Routes: Existing internal/operator Coverage v2 readiness/inspect surface only if rendered data changes. No new route, navigation entry, customer route, report, download, or dashboard is in scope.
• Data Ownership: Existing Coverage v2 TenantConfigurationResourceType, TenantConfigurationResource, and TenantConfigurationResourceEvidence rows remain owned by workspace_id, managed_environment_id, and same-scope provider_connection_id. Provider-native tenant IDs remain metadata only.
• RBAC: Existing Coverage v2 read authorization applies. Non-member or wrong workspace/environment access is deny-as-not-found (404). A member missing the required view capability receives 403. Any inspect/read flow must validate provider connection scope.

No Legacy / No Backward Compatibility Constraint (mandatory)

TenantPilot is pre-production for this feature.

• Compatibility posture: canonical Coverage v2 extension.
• 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 typed support pack over Coverage v2. No customer contract requires old labels, Coverage v1 adapters, dual writes, fallback readers, or compatibility fixtures.

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

The expected impact is data-driven presentation on the existing Coverage v2 internal/operator readiness and inspect surface when comparable/renderable/readiness summaries become visible. No new UI files are required by this spec; if implementation needs runtime UI edits, the plan/tasks must be amended before editing runtime UI.

UI/Productization Coverage (mandatory when UI Surface Impact is not "No UI surface impact")

• Route/page/surface: Existing Coverage v2 readiness/resource/evidence inspection surface and inspect detail disclosure.
• Current or new page archetype: Technical Annex / read-only evidence inspection.
• Design depth: Internal/Hidden with Product Surface proof if rendered output changes.
• Repo-truth level: repo-verified existing surface from Spec 418.
• Existing pattern reused: Existing Coverage v2 read model, existing internal/operator inspect flow, existing badge/status patterns.
• New pattern required: none.
• Screenshot required: no standalone screenshot artifact required by prep; focused browser proof required if rendered output changes.
• Page audit required: no full page audit; focused existing-surface browser smoke is sufficient unless implementation changes runtime UI files.
• Customer-safe review required: yes for wording boundaries; no customer route or output may be activated.
• Dangerous-action review required: no mutating/destructive action is 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 - existing internal surface only; update coverage artifacts only if runtime UI files/routes/navigation change
• No-impact rationale when applicable: N/A.

Product Surface Impact (mandatory for UI-affecting specs)

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

• Product Surface Contract applies?: yes, for data-driven rendered status/evidence/readiness changes on the existing Coverage v2 surface.
• Page archetype: Technical Annex.
• Primary user question: Which selected Security and Compliance evidence can be compared, rendered, and safely reviewed by an internal operator?
• Primary action: Inspect.
• Surface budget result: pass if limited to the existing read-only surface and inspect disclosure; exception required if implementation adds a new page, dashboard, action, customer output, or more than one primary decision flow.
• Technical Annex / deep-link demotion: Raw payloads, source IDs, provider IDs, evidence hashes, OperationRun links, unsupported fields, source contract keys, and diagnostics remain hidden/demoted to internal inspect/diagnostics and must not become default-visible product proof.
• Canonical status vocabulary: Product-facing labels must use existing canonical states such as Ready, Needs attention, Blocked, Unknown, and scoped internal labels. Do not expose certified, restore-ready, customer-ready, legal compliance verified, or broad "Security and Compliance covered" language.
• Visible complexity impact: neutral if the existing inspect surface gains concise summaries and manual-review blockers; increased complexity requires a documented exception.
• Product Surface exceptions: none planned.

Browser Verification Plan (mandatory)

• Browser proof required?: yes if implementation-created summaries/readiness states render on the existing Coverage v2 surface; otherwise no.
• No-browser rationale: N/A - no rendered UI surface changed only if implementation proves no rendered output changes.
• Focused path when required: Existing Coverage v2 readiness/operator route.
• Primary interaction to execute: Load the existing route as an authorized operator, inspect a Security and Compliance resource row, and verify typed summary/readiness/manual-review presentation.
• Console, Livewire, Filament, network, and 500-error checks: planned when browser proof is required.
• Full-suite failure triage: unrelated browser/full-suite failures may be documented only after focused proof is green.

Human Product Sanity Check (mandatory)

• Required?: yes if rendered output changes; no if no rendered output changes.
• No-human-sanity rationale: N/A only with exact no-rendered-change proof.
• Reviewer questions: purpose clear, one dominant inspect action, technical details demoted, manual-review warnings clear, no restore/certified/customer/legal claims, complexity not worse, trust acceptable.
• Planned result location: implementation report / PR close-out.

Product Surface Merge Gate Checklist (mandatory)

• No-legacy posture or approved exception recorded.
• Product Surface Impact is completed.
• Browser proof is required if rendered output changes, or N/A - no rendered UI surface changed must be justified.
• Human Product Sanity is required if rendered output changes, or N/A must be justified.
• 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): status messaging, evidence inspection, typed summaries, claim safety, readiness/manual-review presentation.
• Systems touched: CoveragePayloadRedactor, ClaimGuard, CoverageV2ReadinessReadModel, existing Coverage v2 read authorization, existing comparable/renderable service patterns, existing badge/readiness display if rendered.
• Existing pattern(s) to extend: Entra and Exchange/Teams comparable/renderable patterns from Specs 421/422.
• Shared contract / presenter / builder / renderer to reuse: Coverage v2 resource/evidence/read-model path, redactor, Claim Guard, existing render-summary pattern, existing comparator pattern.
• Why the existing shared path is sufficient or insufficient: Sufficient for DB-only typed interpretation over existing evidence. No separate Security/Purview engine is justified.
• Allowed deviation and why: none planned.
• Consistency impact: Readiness, compare, render, redaction, and claim wording must align with existing Coverage v2 semantics while adding stricter manual-review behavior for high-risk Security and Compliance changes.
• Review focus: Verify no parallel Security/Purview mini-platform, no raw payload/default proof, no customer/legal/certification claim, and no historical-spec rewrite.

OperationRun UX Impact (mandatory when touched)

• Touches OperationRun start/completion/link UX?: no.
• Shared OperationRun UX contract/layer reused: N/A.
• Delegated start/completion UX behaviors: N/A.
• Local surface-owned behavior that remains: Existing diagnostic OperationRun references, if present, remain secondary/internal and authorized.
• Queued DB-notification policy: N/A.
• Terminal notification path: N/A.
• Exception required?: none.

Provider Boundary / Platform Core Check (mandatory)

• Shared provider/platform boundary touched?: yes.
• Boundary classification: mixed. Coverage v2 evidence, identity, claim, readiness, redaction, and read-model semantics are platform-core; Microsoft TCM/Security/Compliance/Purview names and source aliases are provider-owned metadata.
• Seams affected: resource type canonical names, source aliases, typed payload field mapping, compare/render/readiness interpretation, claim wording.
• Neutral platform terms preserved or introduced: provider connection, managed environment, resource, evidence, coverage level, readiness, manual review, claim state.
• Provider-specific semantics retained and why: Microsoft Security and Compliance resource names remain because this spec is explicitly for M365 Coverage v2 representative resource types. They must stay source metadata and typed support keys, not ownership truth.
• Why this does not deepen provider coupling accidentally: No new provider framework, provider-owned table, provider ownership key, customer claim, restore path, or live Microsoft call is introduced.
• Follow-up path: document-in-feature for bounded provider-specific hotspots; follow-up-spec for restore/certification/customer output if ever promoted.

UI / Surface Guardrail Impact (mandatory when operator-facing surfaces are changed)

Surface / Change	Operator-facing surface change?	Native vs Custom	Shared-Family Relevance	State Layers Touched	Exception Needed?	Low-Impact / N/A Note
Existing Coverage v2 readiness / inspect surface data	yes, data-driven if summaries render	Native Filament existing surface	Coverage v2 evidence/readiness family	page/detail	no	No new route/action/navigation planned

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
Existing Coverage v2 readiness / inspect surface	Tertiary Evidence / Diagnostics	Release/operator review of selected Security and Compliance evidence	Resource name, coverage/evidence/identity/claim state, readiness/manual-review state, typed summary if rendered	raw/normalized payload, source metadata, unsupported fields, evidence hash, OperationRun link	Not primary; it supports internal evidence inspection and release review	Follows existing Coverage v2 internal review flow	Reduces raw-payload reading for selected Security and Compliance evidence

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

Surface	Audience Modes In Scope	Decision-First Default-Visible Content	Operator Diagnostics	Support / Raw Evidence	One Dominant Next Action	Hidden / Gated By Default	Duplicate-Truth Prevention
Coverage v2 readiness / inspect	operator-MSP, support-platform	selected resource summary, manual-review state, material changes, blockers, claim state	unsupported fields, source metadata, identity diagnostics	raw payload stays hidden or secondary/internal; secrets and content never shown	Inspect	raw payload, provider IDs, OperationRun details, source keys	Coverage/readiness appears once; do not duplicate as broad Security and Compliance readiness

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
Coverage v2 readiness	List / Table / Report	Read-only registry/evidence inspection	Inspect selected evidence	Existing inspect affordance	existing behavior	not required	none	existing route	inspect disclosure	workspace + managed environment	Coverage v2 resources	coverage level, evidence state, identity state, claim state, readiness/manual-review state	none

UI Action Matrix (mandatory when operator-facing surfaces are changed)

Surface	Header Actions	Row Actions	Bulk Actions	Empty-State CTA(s)	Primary Inspect / Open Affordance	Destructive / High-Impact Actions	Authorization / Visibility	Notes
Coverage v2 readiness / inspect	no new header action	existing Inspect only; no new row action	none	no new empty-state CTA	existing inspect affordance / disclosure	none	existing Coverage v2 read authorization; non-member/wrong scope 404, member missing view capability 403	Data-driven summary/readiness presentation only; no route, navigation, action, restore, certify, export, or customer output added

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
Coverage v2 readiness / inspect	Tenant operator / release reviewer	Verify selected Security and Compliance evidence interpretation without unsafe claims	Technical Annex / read-only evidence inspection	What selected Security and Compliance evidence is comparable/renderable/readiness-assessed, and what requires manual review?	typed summary, coverage/evidence/identity/claim/readiness state, last captured	raw payload, unsupported fields, source metadata, evidence hash, OperationRun	coverage level, evidence state, identity state, claim state, readiness/manual-review, compare importance	read-only	Inspect	none

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: no. Existing Coverage v2 resource/evidence rows remain truth.
• New persisted entity/table/artifact?: no.
• New abstraction?: yes, bounded typed helpers for Security and Compliance normalization/compare/render/readiness may be added.
• New enum/state/reason family?: no persisted enum/state family. Derived readiness/manual-review labels may be local result values only.
• New cross-domain UI framework/taxonomy?: no.
• Current operator problem: Operators cannot safely understand selected Security and Compliance evidence without raw payloads or overclaiming compliance readiness.
• Existing structure is insufficient because: Generic payload summaries and existing Entra/Exchange/Teams helpers do not know retention, label, DLP, auto-label, alert, or compliance tag material fields and manual-review requirements.
• Narrowest correct implementation: Add Security and Compliance typed helpers that plug into existing Coverage v2 read-model/redaction/Claim Guard paths and only promote types with content-backed evidence and tests.
• Ownership cost: Maintain typed mappings, compare importance rules, readiness/manual-review rules, redaction tests, Claim Guard phrase tests, and focused browser-if-rendered proof.
• Alternative intentionally rejected: A Purview/Security dashboard, restore engine, certification pack, persisted readiness table, or workload-specific service platform.
• Release truth: Current-release truth over existing Coverage v2 evidence, not future capture, restore, certification, or customer reporting preparation.

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 unless explicitly required by this spec.

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

• Test purpose / classification: Unit for typed normalization/compare/render/redaction/readiness/Claim Guard; Feature for evidence-gated promotion, RBAC/scope, no overclaim/no restore/no certification/no legal attestation/no tenant_id; Browser if rendered Coverage v2 output changes.
• Validation lane(s): fast-feedback, confidence, browser-if-rendered. PostgreSQL lane only if implementation unexpectedly changes migrations/indexes/constraints.
• Why this classification and these lanes are sufficient: The core behavior is deterministic service/read-model interpretation over existing DB evidence. Feature tests prove authorization/scope and no unsafe claims. Browser proof is only needed when the existing rendered surface changes.
• New or expanded test families: focused Spec423* unit/feature tests, and a focused existing-surface browser smoke only if rendered output changes.
• Fixture / helper cost impact: Use minimal workspace/managed-environment/provider/evidence factories and fake content-backed evidence payloads. No live Graph/TCM/Microsoft documentation calls.
• Heavy-family visibility / justification: none unless focused browser proof is required for rendered output.
• Special surface test profile: existing technical/evidence surface profile if browser proof is needed.
• Standard-native relief or required special coverage: standard-native-filament relief for layout; focused browser proof if rendered output changes.
• Reviewer handoff: Verify no hidden browser/heavy cost, no broad fixture defaults, no raw payload/default proof, no legal/certified/restore/customer claims, no mini-platform, and exact commands in the implementation report.
• Budget / baseline / trend impact: none expected; document if browser or feature fixture cost materially expands.
• Escalation needed: document-in-feature if contained; follow-up-spec for certification, restore, customer output, or broader Security/Purview coverage.
• Active feature PR close-out entry: Guardrail / Smoke Coverage.
• Planned validation commands:
  • cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent
  • cd apps/platform && ./vendor/bin/sail artisan test --filter=Spec423
  • cd apps/platform && ./vendor/bin/sail artisan test --filter=ClaimGuard
  • focused browser smoke for the existing Coverage v2 readiness/inspect route if rendered output changes.
  • git diff --check

User Scenarios & Testing (mandatory)

User Story 1 - Interpret Mandatory Security and Compliance Evidence (Priority: P1)

As an internal operator, I need selected content-backed Security and Compliance evidence to be normalized, compared, and rendered safely so I can understand retention, label, and DLP configuration changes without raw payloads.

Why this priority: Retention, labeling, and DLP are high-blast-radius controls and the mandatory minimum value of the pack.

Independent Test: Given content-backed evidence payloads for retentionCompliancePolicy, labelPolicy, and dlpCompliancePolicy, compare output identifies material changes, render output shows operator-readable summaries, and raw payload/secrets/content remain hidden.

Acceptance Scenarios:

1. Given content-backed retentionCompliancePolicy evidence, When retention duration, disposition action, enabled state, or scope changes, Then compare output marks the change critical and render output shows a concise retention summary with manual-review warning.
2. Given content-backed labelPolicy evidence, When published labels, default/mandatory behavior, or scope changes, Then compare output marks the material change and render output summarizes label publication and labeling behavior without raw payload.
3. Given content-backed dlpCompliancePolicy evidence, When mode, rules/actions, or workload/location scope changes, Then compare output marks the change critical and render output summarizes policy mode/scope/action behavior safely.

---

User Story 2 - Require Manual Review and Block Unsafe Readiness (Priority: P1)

As a release reviewer, I need Security and Compliance readiness to mean "ready for operator review" only, with manual-review and blocked states when evidence, identity, permissions, or high-risk changes make automated confidence unsafe.

Why this priority: The term readiness is dangerous in this domain unless it explicitly avoids legal, restore, certification, and customer-ready meanings.

Independent Test: Readiness derivation produces manual-review for high-risk material changes, blocks missing/identity/permission cases, and never maps to restore/certification/legal/customer-ready claims.

Acceptance Scenarios:

1. Given a high-risk material retention or DLP change, When readiness is derived, Then the result requires manual review and does not say ready for customer proof.
2. Given evidence is missing or not content-backed, When readiness is derived, Then the result remains blocked/unassessed and the type is not promoted to readiness-assessed.
3. Given identity conflict, missing external identity, unsupported identity, or provider-scope mismatch exists, When readiness is derived, Then readiness is blocked and no claim is allowed.

---

User Story 3 - Prevent Overclaim and Sensitive Content Leakage (Priority: P1)

As a platform reviewer, I need Claim Guard and redaction proof so TenantPilot cannot claim Security/Compliance certification, restore readiness, legal approval, customer-ready proof, or broad Purview coverage from this internal operator pack.

Why this priority: Incorrect claims or content leaks would create product, legal, and customer trust risk.

Independent Test: Claim Guard allows only scoped internal compare/render/readiness-for-operator-review language and blocks certified, restore-ready, customer-ready, legal/regulatory, 100 percent, full Purview, and broad Security and Compliance claims.

Acceptance Scenarios:

1. Given an internal statement "Selected Security and Compliance resources are ready for operator review", When Claim Guard evaluates it, Then it remains internal-only and scoped.
2. Given a statement "Security and Compliance is certified" or "Retention is restore-ready", When Claim Guard evaluates it, Then it is blocked.
3. Given render summaries are generated, When they are inspected, Then raw payloads, provider responses, tokens, secrets, case content, mail/message/file content, DLP incident content, security incident content, and unredacted PII are absent from default-visible output.

---

User Story 4 - Promote Only Evidence-Backed Resource Types (Priority: P2)

As a release reviewer, I need optional Security and Compliance resource types to remain unpromoted unless content-backed evidence and focused tests exist so TenantPilot never fakes typed support.

Why this priority: The draft lists six resource types, but the repo must promote only what evidence and tests can prove.

Independent Test: Mandatory and optional types are promoted only when content-backed evidence exists; missing-evidence types remain detected/content-backed-only with explicit blocker/deferred reasons.

Acceptance Scenarios:

1. Given a selected resource type has no content-backed evidence, When promotion is evaluated, Then it remains unpromoted and the implementation report records the blocker.
2. Given autoSensitivityLabelPolicy, protectionAlert, or complianceTag has content-backed evidence and tests, When implementation promotes it, Then it receives comparable/renderable/readiness-assessed support without restore/certification/customer claims.
3. Given implementation pressure to include all Security and Compliance resource types, When evidence or tests are missing, Then the type is deferred rather than simulated.

Edge Cases

• Missing source contracts or absent content-backed evidence must not be papered over by registry-only promotion.
• Unknown fields in material retention, labeling, DLP, auto-label, alert, or compliance tag sections must become unsupported-field diagnostics or manual-review triggers, not false calm.
• Redacted values must not produce false material changes.
• Array ordering must be stable when order is not semantically meaningful; priority/order fields remain order-sensitive where business behavior depends on order.
• Render/compare/readiness must not perform Graph, TCM, provider, HTTP, or Microsoft documentation calls.
• Customer-facing paths must not show Security and Compliance readiness as customer proof.

Requirements (mandatory)

Functional Requirements

• FR-423-001: The implementation MUST use existing Coverage v2 resource type, resource, evidence, identity, redaction, read-model, and Claim Guard boundaries.
• FR-423-002: A Security and Compliance resource type MUST be promoted to comparable only when content-backed evidence exists, typed normalization exists, deterministic compare rules exist, volatile fields are excluded or labeled, redaction rules exist, and focused tests cover material changes.
• FR-423-003: A Security and Compliance resource type MUST be promoted to renderable only when comparable support exists, an operator-safe summary exists, raw payload is unnecessary for understanding, sensitive fields are redacted, and focused tests cover default-visible output.
• FR-423-004: A Security and Compliance resource type MUST be promoted to readiness-assessed only when renderable support exists, readiness/manual-review rules are derived from existing Coverage v2 states and resource-specific safety tiers, and focused tests prove no restore/certification/legal/customer-ready meaning.
• FR-423-005: retentionCompliancePolicy, labelPolicy, and dlpCompliancePolicy MUST have typed compare/render/readiness support when content-backed evidence exists.
• FR-423-006: autoSensitivityLabelPolicy, protectionAlert, and complianceTag MAY be promoted only when content-backed evidence exists and scope remains bounded with focused tests.
• FR-423-007: Missing source contracts, missing evidence, blocked capture outcomes, identity conflicts, provider-scope mismatches, permission blockers, or unsupported resource types MUST remain explicit blockers/deferred reasons.
• FR-423-008: Compare output MUST classify changes using bounded result labels: added, removed, changed, unchanged, ignored_volatile, redacted, unsupported_field, and manual_review_required.
• FR-423-009: Compare output MAY use derived importance labels critical, important, informational, and manual_review_required; these labels MUST NOT become a persisted global risk taxonomy.
• FR-423-010: Retention duration, disposition/action, included/excluded scope, enabled/state, DLP mode/actions/rules/scope, label publication/default/mandatory behavior, auto-label enforcement, alert threshold/recipient changes, and compliance tag retention/disposition changes MUST NOT be downgraded to informational.
• FR-423-011: Render output MUST answer what the resource is, whether it is enabled/active, what scope/workload/location it affects, what enforcement/retention/label/DLP behavior applies, what changed, what requires manual review, and what is unsupported or redacted.
• FR-423-012: Render output MUST hide raw payloads, raw provider responses, tokens, authorization headers, cookies, client secrets, passwords, private keys, certificate material, mail/message/file content, DLP incident content, security incident content, eDiscovery case content, audit search content, and unredacted PII beyond necessary admin-visible identifiers.
• FR-423-013: Readiness MUST mean "enough structured evidence for internal operator review" only.
• FR-423-014: Readiness MUST require manual review for high-risk compliance/legal-impacting resources, critical material changes, unknown fields in material sections, and retention/disposition/legal-impacting changes.
• FR-423-015: Readiness MUST block or remain unassessed when evidence is missing, identity is unsafe, permissions/source availability are blocked, the type is unsupported, or redaction fails.
• FR-423-016: Claim Guard MUST allow only scoped internal/operator statements for selected comparable/renderable/readiness-for-operator-review support.
• FR-423-017: Claim Guard MUST block certification, restore-ready, customer-ready proof, legal/regulatory attestation, 100 percent Security and Compliance/Purview coverage, full compliance coverage, and broad M365 claims.
• FR-423-018: Render/compare/readiness MUST be DB-only from existing evidence at render time and MUST NOT call Graph, TCM, provider clients, HTTP, remote APIs, or Microsoft documentation.
• FR-423-019: Existing Coverage v2 read authorization MUST apply: non-member/wrong workspace/environment is 404, member missing required view capability is 403, and provider connection scope must match workspace and managed environment.
• FR-423-020: The implementation MUST NOT add restore/apply/certify/legal-attestation/customer-output actions, new routes, new navigation, new dashboard, new capture action, new source contracts, new workload-specific table family, new Security/Purview engine, or new customer-facing surface.
• FR-423-021: No tenant_id may be introduced as Coverage v2 ownership truth, compatibility alias, dual-write target, fallback reader, or parallel scope key.
• FR-423-022: Existing Coverage v2 operator surface MAY show comparable/renderable/readiness Security and Compliance summaries; any rendered change requires focused browser proof and Human Product Sanity.
• FR-423-023: Implementation close-out MUST record evidence availability, promoted/deferred resource types, normalizer/compare/render/readiness matrices, Claim Guard proof, redaction proof, no-restore/no-certification/no-legal-attestation proof, no tenant_id, no mini-platform, Product Surface result, tests/browser/no-browser, deployment impact, and deferred work.

Non-Functional Requirements

• NFR-423-001: The pack MUST be deterministic: identical input payloads produce identical normalized summaries, compare results, readiness results, and redaction outcomes.
• NFR-423-002: Existing Coverage v2 surface performance MUST remain DB-only with no render-time provider/API calls and no new per-row remote work.
• NFR-423-003: Test fixtures MUST use fake content-backed payloads and must not require live Graph, TCM, Purview, Security and Compliance, or Microsoft documentation access.
• NFR-423-004: Output language MUST remain scoped and safe for internal operators; customer-readable claims are out of scope.
• NFR-423-005: The implementation MUST stay within existing Laravel 12, Filament v5, Livewire v4, Pest v4, PostgreSQL, and Sail conventions.

Key Entities (include if feature involves data)

• TenantConfigurationResourceType: Existing Coverage v2 registry definition for selected Security and Compliance canonical resource types.
• TenantConfigurationResource: Existing environment-owned concrete resource observed in one workspace, managed environment, provider connection, and resource type.
• TenantConfigurationResourceEvidence: Existing append-only evidence row with content-backed payload metadata, normalized payload, evidence state, coverage level, capture outcome, and capture time.
• Typed Security and Compliance summary: Derived, non-persisted render/compare/readiness result generated from existing evidence.

Success Criteria (mandatory)

Measurable Outcomes

• SC-423-001: For each mandatory type with content-backed evidence, focused tests prove deterministic normalization, material compare detection, operator-safe rendering, and readiness/manual-review behavior.
• SC-423-002: Focused tests prove no selected Security and Compliance type can be promoted to comparable/renderable/readiness-assessed without content-backed evidence and corresponding tests.
• SC-423-003: Focused tests prove Claim Guard blocks restore-ready, certified, customer-ready, legal/regulatory, broad Security and Compliance, broad Purview, and 100 percent coverage claims.
• SC-423-004: Focused tests prove raw payloads, secrets, provider responses, case/mail/message/file/DLP incident/security incident content, and unredacted sensitive values are absent from default-visible summaries.
• SC-423-005: Focused tests prove render/compare/readiness performs no Graph, TCM, provider, HTTP, or remote documentation calls.
• SC-423-006: Product Surface proof records focused browser/Human Product Sanity results when rendered output changes, or exact N/A - no rendered UI surface changed proof.
• SC-423-007: Implementation report records promoted and deferred types with reasons, no tenant_id, no mini-platform, no restore/apply/certification/legal/customer output, and validation commands/results.

Assumptions

• Specs 414, 415, and 417-422 remain completed dependency context and will not be modified.
• Existing Coverage v2 models and coverage-level enum can represent comparable/renderable/readiness-assessed behavior without schema changes.
• Security and Compliance registry rows from Spec 419 remain active but conservative by default.
• Spec 420 proved missing-contract behavior for dlpCompliancePolicy; this spec does not add capture contracts and promotes only evidence-backed rows already present or test-seeded.
• Existing Coverage v2 surface is internal/operator only and read-only.

Risks

Risk	Severity	Mitigation
Readiness is mistaken for legal approval	High	Claim Guard, copy restrictions, manual-review labels, tests
Readiness is mistaken for restore/certification	High	no restore/certification requirements and tests
Retention/DLP changes are underexplained	High	critical/manual-review compare importance rules
Sensitive compliance content leaks	High	redaction tests and browser-if-rendered proof
Purview/Security mini-platform appears	High	reuse Coverage v2 shared services; no tables/dashboard
Raw payload becomes default UI proof	High	Product Surface proof and redaction/feature tests
Too many resource types included	Medium	mandatory first pack plus evidence-gated optional types
tenant_id returns	High	no-tenant-id static/feature tests
Remote calls during render	High	no-remote-render tests

Open Questions

None blocking preparation. Implementation preflight must record which of the six listed resource types have content-backed evidence and defer any missing-evidence type.

Follow-up Spec Candidates

• Security and Compliance certified compare pack, if customer proof is ever explicitly approved.
• Security and Compliance restore/apply evaluation, only after separate safety and legal/product review.
• Customer-facing M365 compliance report or Review Pack output, only through a separate customer-output spec.
• M365 customer reporting Claim Guard pack.
• M365 pilot readiness gate.