[008] Greenfield GPO baseline refresh and AD version metadata for 3.0.0

Start with the design reference at specs\008-Update-TierModel and inspect the existing JSON/schema and TierModel module helpers; the issue does not name specific source or test files. First validate the refreshed Deploy path in an approved isolated lab, then follow the stated delivery order for owner review, Audit, and Pester coverage. Done means the acceptance criteria pass without an automatic live-policy cutover or production rollout.

Problem

The current deployment catalog contains older SCT baselines and has no persistent Tier Model deployment-version or managed-GPO content-version metadata. The greenfield foundation must work before a historical upgrade manifest or replacement workflow is implemented.

Agreed implementation scope

• Refresh the supplied Edge 151, Windows Server 2025 v2602, Windows 11 26H2, and Microsoft 365 Apps v2512 backup sources.
• Update all 49 consuming GPO declarations across 19 distinct source variants, including the unversioned PAW Staging BitLocker declaration and two Server Credential Guard templates.
• Preserve previous backup GUID directories in a temporary archive until the refreshed deployment is accepted and their removal is approved.
• Preserve existing OU targets, link order, enabled/enforced defaults, filtering intent, and the existing Windows-versus-Server Domain Security source split. Additional Internet Explorer backups are outside this refresh.
• Target Tier Model release 3.0.0. Refreshed policy content is version 1.1; unchanged policy content is version 1.0.
• Lab-prove the selected application-owned AD registry before permanent integration: serviceConnectionPoint records using namespaced keywords under CN=TierModel,CN=System in the managed domain. Keep the deployment record separate from per-GPO records bound to actual live GPO GUIDs. Native GPO version counters are not application content versions.
• Extend the JSON/schema and existing TierModel module helpers, and integrate deployment metadata without introducing a second deployment engine.

Missing version metadata identifies legacy/unversioned handling, not proof of ownership or permission to adopt/reimport an existing GPO. Missing records in a known v3 deployment must also be handled as possible metadata faults. No implicit existing-domain upgrade or blanket legacy stamping is authorized.

Delivery order

1. Implement and validate the refreshed Deploy path in an approved isolated lab.
2. Owner reviews the JSON and exercises the lab deployment.
3. Improve Audit for the new metadata behavior.
4. Add new Pester coverage after intended working-code lab behavior is established, following the requested 008-scoped sequencing exception.

Historical upgrade JSON, the selected-family updater, bridge deployment, and production publication remain later work. This issue does not authorize automatic live-policy cutover or retirement.

Acceptance

• Every refreshed import path resolves to the intended backup ID and source metadata; archived predecessors remain recoverable.
• All declared GPOs have explicit stable identity and content-version data without changing unrelated policy/link configuration.
• Metadata is written only after verified successful creation/import/configuration and is bound to the actual target GUID.
• Preview and WhatIf remain domain-read-only; failed or partial deployment cannot advance a complete-release record.
• Repeated deployment preserves existing identity/settings/links and fails explicitly on unknown legacy ownership, collisions, unreadable state, or conflicting metadata.
• Shared prerequisites, structured logging, diagnostics, and result contracts are preserved.
• No automatic cancellation/unlock, release publication, or production rollout is included.

Design reference: specs\008-Update-TierModel.