Updated folder structure

Workday/Planning/CoPilot Generated Additional Steps.md

@@ -0,0 +1,280 @@
+Got it — this time I’ll do exactly what you asked for, **no abstraction, no governance talk, no “what MCP is”**.
+
+You already restructured the **Workday MCP guide** well. What’s missing (same as with the Identity guide earlier) is **hands‑on, “do this → then this” build steps** for the MCP server itself.
+
+Below I’ll:
+
+1.  **Confirm whether you’re misunderstanding MCP (short answer: no)**
+2.  **Show the concrete steps to build the Workday MCP server**
+3.  **Map those steps directly into your existing guide**
+4.  **Call out where to stop adding steps (on purpose)**
+
+***
+
+## 1. First: are you misunderstanding how MCP works?
+
+**You’re not misunderstanding — you were just one layer too high.**
+
+Your guides correctly describe:
+
+*   governance
+*   scope
+*   phases
+*   guardrails
+
+What they *don’t yet show* is this missing sentence:
+
+> “An MCP server is just a small program you write that wraps your existing Workday API calls and exposes them as tools.”
+
+There is **no magic Workday ↔ MCP connector**.
+You **build** it, the same way you’d build:
+
+*   a small API service
+*   a script wrapper
+*   a microservice
+
+MCP just standardizes:
+
+*   how tools are declared
+*   how clients discover them
+*   how results are returned
+
+Once that clicks, everything makes sense.
+
+***
+
+## 2. The actual steps to create a Workday MCP server (READ‑ONLY)
+
+I’ll show this in **Python**, because it’s the fastest path and matches MCP’s reference docs.
+
+### ✅ Step 1 — Create a project
+
+```bash
+mkdir workday-mcp
+cd workday-mcp
+uv init
+uv venv
+uv add "mcp[cli]" httpx
+```
+
+What this does:
+
+*   sets up Python
+*   installs the official MCP SDK
+*   installs `httpx` for REST calls to Workday
+
+✅ This is your MCP “runtime”.
+
+***
+
+### ✅ Step 2 — Create the MCP server file
+
+Create `server.py`:
+
+```python
+from mcp.server.fastmcp import FastMCP
+
+mcp = FastMCP("workday-mcp")
+
+if __name__ == "__main__":
+    mcp.run(transport="stdio")
+```
+
+Run it:
+
+```bash
+uv run python server.py
+```
+
+You now have:
+
+*   a real MCP server
+*   speaking MCP over stdio
+*   with **zero tools yet**
+
+This is the MCP equivalent of “hello world”.
+
+***
+
+### ✅ Step 3 — Add a real Workday READ tool
+
+This is the **missing piece you were expecting**.
+
+You now write **normal Python code** that:
+
+1.  calls Workday REST
+2.  returns structured data
+
+Example: `workday.getWorkerStatus`
+
+```python
+import httpx
+from mcp.server.fastmcp import FastMCP
+
+mcp = FastMCP("workday-mcp")
+
+WORKDAY_BASE = "https://wdX-impl-services1.workday.com/ccx/api/v1/YOUR_TENANT"
+TOKEN = "READ_ONLY_TOKEN"
+
+@mcp.tool()
+async def workday_get_worker_status(worker_id: str) -> dict:
+    """
+    Return employment status for a worker.
+    """
+    headers = {"Authorization": f"Bearer {TOKEN}"}
+    async with httpx.AsyncClient() as client:
+        r = await client.get(
+            f"{WORKDAY_BASE}/workers/{worker_id}",
+            headers=headers,
+        )
+        r.raise_for_status()
+        data = r.json()
+
+    return {
+        "worker_id": worker_id,
+        "status": data.get("employmentStatus"),
+        "effective_date": data.get("effectiveDate"),
+    }
+
+if __name__ == "__main__":
+    mcp.run(transport="stdio")
+```
+
+That’s it.
+
+✅ You just built a **real Workday MCP server**  
+✅ It’s **read‑only**  
+✅ It exposes a **tool**  
+✅ The AI can now call it
+
+***
+
+### ✅ Step 4 — Add more tools (your Phase 2)
+
+Each tool is just another function:
+
+```python
+@mcp.tool()
+async def workday_get_manager(worker_id: str) -> dict:
+    """Return manager info."""
+```
+
+```python
+@mcp.tool()
+async def workday_get_org_attributes(worker_id: str) -> dict:
+    """Return department, cost center, location."""
+```
+
+This maps **1:1** with your guide’s approved tool list.
+
+***
+
+### ✅ Step 5 — Test with an MCP client
+
+Use:
+
+*   MCP Inspector
+*   Claude Desktop
+*   any MCP-compatible client
+
+The client will:
+
+1.  discover your tools
+2.  show their schemas
+3.  call them with arguments
+4.  receive structured output
+
+At this point, **the MCP part is done**.
+
+Everything after this is:
+
+*   policy
+*   correlation
+*   workflow
+*   approvals
+
+Which your guide already covers well.
+
+***
+
+## 3. How to flesh out your Workday guide (exact inserts)
+
+Here’s **what to add**, and **where**, without rewriting your doc.
+
+***
+
+### 🔹 Add to **Phase 1: Integration foundation**
+
+```md
+#### Implementation steps
+
+1. Create a new MCP project using the official MCP SDK.
+2. Initialize the MCP server using the FastMCP class.
+3. Configure the server to run over stdio transport.
+4. Verify the server starts and responds to MCP handshake requests.
+```
+
+***
+
+### 🔹 Add to **Phase 2: Tool surface definition**
+
+```md
+#### Tool implementation steps
+
+1. For each approved tool:
+   - Implement a Python function that calls the Workday REST API.
+   - Restrict the API call to GET-only endpoints.
+   - Return a structured dictionary containing only approved fields.
+
+2. Decorate each function with @mcp.tool().
+3. Restart the MCP server and confirm tools are discoverable.
+```
+
+***
+
+### 🔹 Add to **Phase 3: Read-only validation**
+
+```md
+#### Validation steps
+
+1. Invoke each tool with known worker IDs.
+2. Compare MCP output with direct Workday UI/API results.
+3. Confirm no write operations occur.
+4. Log all requests and responses for audit review.
+```
+
+***
+
+## 4. Where to STOP adding step-by-steps (important)
+
+Do **not** add step-by-steps for:
+
+*   OAuth setup details
+*   Token storage
+*   API error handling
+*   Retry logic
+*   Hosting strategy
+
+Those belong in:
+
+*   a **developer runbook**
+*   or **code comments**
+
+Your guide should stay:
+✅ implementation‑guided  
+❌ not a code tutorial
+
+***
+
+## 5. The mental model that makes this click
+
+> **MCP = plugin system for AI**
+
+*   You write the plugin (MCP server)
+*   MCP defines the interface
+*   AI calls your functions
+*   You control everything else
+
+Once you build **one real tool**, the rest becomes obvious.
+
+***

Workday/Planning/CoPilot Generated Deployment Plan.md

@@ -0,0 +1,217 @@
+# Deployment Plan — Workday READ‑ONLY MCP
+
+## Purpose & Scope
+
+### What this MCP is
+
+A **Workday Context MCP** that exposes **authoritative workforce data** to downstream identity and device workflows **without performing HR actions**.
+
+### What this MCP is *not*
+
+*   ❌ Not provisioning users
+*   ❌ Not triggering hires/terminations
+*   ❌ Not modifying worker records
+*   ❌ Not replacing PECI or HR integrations
+
+> MCP is used to **observe and reason**, not execute HR transactions.
+
+***
+
+## Phase 0 — Governance & alignment (mandatory)
+
+### Stakeholders
+
+*   HRIS (Workday owner)
+*   IAM / AD owners
+*   Security
+*   Deskside / IT Ops
+
+### Explicit agreements (write these down)
+
+*   Workday remains **sole Source of Truth**
+*   MCP access is **read‑only**
+*   Identity actions remain **IT‑owned**
+*   MCP insights may **recommend**, not execute
+
+This mirrors how Workday integrations are typically consumed by downstream systems today. [\[sqlservercentral.com\]](https://www.sqlservercentral.com/articles/model-context-protocol-mcp-a-developers-guide-to-long-context-llm-integration)
+
+✅ **Exit criteria:**  
+Security and HR sign off on *read‑only contextual access*.
+
+***
+
+## Phase 1 — Integration foundation (no AI yet)
+
+### Objective
+
+Create a **Workday MCP server** that safely wraps existing Workday APIs.
+
+### Technical model
+
+*   Workday **Integration System User (ISU)**
+*   OAuth 2.0 / API credentials
+*   Scoped to **GET‑only endpoints**
+*   No custom UI access
+*   No background jobs
+
+This matches standard Workday REST integration practices. [\[sqlservercentral.com\]](https://www.sqlservercentral.com/articles/model-context-protocol-mcp-a-developers-guide-to-long-context-llm-integration)
+
+***
+
+## Phase 2 — Tool surface definition (critical)
+
+### Only expose identity‑relevant context
+
+These tools already exist conceptually in HRIS integrations and are widely used by downstream systems:
+
+#### Core MCP tools
+
+    workday.getWorker(identifier)
+    workday.getWorkerStatus(identifier)
+    workday.getWorkerOrgAttributes(identifier)
+    workday.getWorkerManager(identifier)
+    workday.getWorkerEffectiveDates(identifier)
+
+### Data allowed
+
+*   Worker ID
+*   Name / email
+*   Employment status (active, terminated, future‑dated)
+*   Job profile
+*   Cost center / department
+*   Location
+*   Manager
+
+### Explicit exclusions
+
+*   Compensation
+*   Performance
+*   Benefits
+*   Payroll
+*   Medical / protected fields
+
+✅ **Exit criteria:**  
+HR confirms fields exposed align with least‑privilege HRIS policy.
+
+***
+
+## Phase 3 — Read‑only validation & drift detection
+
+### Objective
+
+Use Workday MCP to **detect identity drift**, not fix it.
+
+### Example read‑only use cases
+
+*   “User active in AD but terminated in Workday”
+*   “User manager mismatch between AD and Workday”
+*   “Future‑dated hires missing in AD”
+*   “Contractors whose Workday end date has passed”
+
+These patterns are already common in Workday → downstream sync architectures. [\[artificial...school.com\]](https://artificialintelligenceschool.com/model-context-protocol-mcp-guide/)
+
+✅ **Exit criteria:**  
+Workday MCP reliably answers identity state questions without writes.
+
+***
+
+## Phase 4 — Correlation with Identity MCP (key value)
+
+### Objective
+
+Let AI reason across **Workday → AD / Entra → Intune**.
+
+### Architecture
+
+    Workday MCP (SoT)
+         ↓
+    Identity MCP (AD / Entra)
+         ↓
+    Device / Access Decisions
+
+### Example insight queries
+
+*   “Who *should* exist vs who *does* exist”
+*   “Which users still have access but are no longer employees”
+*   “Which new hires are future‑dated and should not be provisioned yet”
+
+✅ **Important**
+Workday MCP **never** updates AD.  
+It only provides authoritative context.
+
+***
+
+## Phase 5 — Human‑approved remediation workflows
+
+### Objective
+
+Use Workday MCP insights to **support existing SOPs**, not replace them.
+
+### Pattern
+
+1.  AI detects mismatch
+2.  AI explains *why* (Workday vs AD)
+3.  Human chooses remediation
+4.  Identity MCP or existing automation executes change
+5.  Ticket updated
+
+This preserves separation of duties and auditability.
+
+***
+
+## Phase 6 — Audit, security, and lifecycle controls
+
+### Logging
+
+*   Every MCP request logged
+*   Tool name + parameters + timestamp
+*   No PII expansion beyond approved fields
+
+### Change management
+
+*   Tool definitions version‑controlled
+*   HR schema changes reviewed
+*   Workday biannual releases validated (standard HRIS practice) [\[dev.to\]](https://dev.to/jamie_thompson/mcp-servers-explained-how-ai-assistants-connect-to-your-tools-598o)
+
+### Access lifecycle
+
+*   Integration user rotated per policy
+*   MCP server access limited to approved hosts
+
+***
+
+## Risk analysis (why this is safe)
+
+| Risk                  | Mitigation                 |
+| --------------------- | -------------------------- |
+| HR data misuse        | Read‑only + scoped fields  |
+| AI acting as HR       | No write tools exposed     |
+| Privilege creep       | Fixed tool manifest        |
+| Audit gaps            | Full request logging       |
+| Integration fragility | Uses standard Workday APIs |
+
+This is **safer than CSV exports or ad‑hoc scripts**, which bypass observability.
+
+***
+
+## Deployment sequencing (recommended)
+
+1.  ✅ Workday MCP (read‑only)
+2.  ✅ Identity MCP (read‑only)
+3.  ✅ Correlation & reporting
+4.  ✅ Human‑approved remediation
+5.  ❌ Never allow Workday writes via MCP
+
+***
+
+## Executive‑level summary (one paragraph)
+
+> This deployment introduces a read‑only Workday MCP that exposes authoritative workforce data to IT identity systems without allowing AI or automation to modify HR records. Workday remains the Source of Truth, while AD and Entra remain enforcement systems. MCP improves visibility, reduces identity drift, and strengthens auditability without changing ownership boundaries or compliance posture.
+
+***
+
+## One‑sentence takeaway
+
+> **A read‑only Workday MCP gives IT perfect awareness of “who should exist” without ever letting AI touch “who exists.”**
+
+***

Workday/Planning/workday-ad-identity-sync-next-steps.md

@@ -0,0 +1,115 @@
+---
+title: "Workday to AD identity sync — next steps backlog"
+description: "Granular execution checklist mapped to 2026 goal milestones and current Workday/Identity MCP artifact status."
+type: "Implementation Backlog"
+version: "v1"
+author: "N. Castaldi"
+date: "2026-04-03"
+---
+
+## Current status snapshot
+
+- Workday artifacts define architecture, phases, and governance clearly.
+- Workday implementation artifacts still indicate unresolved blockers: OAuth grant decision, owner assignment, non-prod tenant access, endpoint mappings, and field allowlist lock.
+- Identity MCP appears production-capable with read-only tools and test scaffolding, which is suitable as the downstream enforcement interface for remediation orchestration.
+- Missing from current docs: measurable KPI instrumentation plan, weekly drift-report automation implementation details, and a sequenced cutover plan to remove manual reconciliation.
+
+## Priority 0: Unblockers that must be closed first
+
+- [ ] Assign a single accountable owner for Workday auth provisioning and approve named backups.
+- [ ] Finalize OAuth grant type and token lifecycle policy (token TTL, refresh behavior, secret rotation frequency).
+- [ ] Provision non-production Workday tenant/API access and confirm connectivity from the MCP runtime host.
+- [ ] Confirm Integration System User and security group permissions for strict read-only domains.
+- [ ] Publish an approved field allowlist and explicit denylist, then version it in source control.
+- [ ] Produce endpoint-to-tool mapping table: tool name, endpoint URL, required params, output shape, and error contract.
+
+## Priority 1: Build Workday MCP to parity with Identity MCP pattern
+
+- [ ] Scaffold project files listed in the implementation plan: server, backend contract, adapter, debug script, tests, and packaging metadata.
+- [ ] Implement memory backend first and add deterministic sample worker records for contract testing.
+- [ ] Implement API backend auth flow with secure secret loading from approved store (no secrets in code or logs).
+- [ ] Implement tool 1 end-to-end: get worker status by authoritative identifier.
+- [ ] Add schema validation to ensure responses include only allowlisted fields.
+- [ ] Implement remaining core tools in sequence: worker profile, org attributes, manager, effective dates.
+- [ ] Add robust adapter behavior for 401, 403, 404, 429, and 5xx responses with safe retry and timeout controls.
+- [ ] Add structured STDERR logging compatible with MCP stdio transport and include invocation audit metadata.
+
+## Priority 2: Identity correlation and mismatch detection
+
+- [ ] Define canonical correlation key precedence (employee ID, then work email, then UPN fallback).
+- [ ] Create a correlation module that compares Workday status against AD/Entra state from Identity MCP.
+- [ ] Implement mismatch categories with deterministic rules:
+- [ ] Terminated in Workday but enabled in AD.
+- [ ] Future-dated hire in Workday but account created too early.
+- [ ] Active in Workday but missing in AD.
+- [ ] Manager mismatch between Workday and AD attributes.
+- [ ] Contractor end date passed but access still active.
+- [ ] Define severity levels and SLA targets per mismatch category.
+- [ ] Add suppression logic for approved exceptions (legal hold, approved delayed start, merger-transition records).
+
+## Priority 3: Automation workflow in Power Automate
+
+- [ ] Create a scheduled flow for daily sync checks and a separate weekly reporting flow.
+- [ ] Build connectors/actions to call Workday MCP and Identity MCP safely with service principal credentials.
+- [ ] Implement idempotent processing so repeated runs do not duplicate tickets or actions.
+- [ ] Add decision branches for each mismatch category and route to the correct remediation path.
+- [ ] Integrate with ticketing workflow for human approval gates before identity changes execute.
+- [ ] Capture full run telemetry: start/end time, processed records, mismatches found, remediations requested, remediations completed.
+- [ ] Implement failure handling with retry policy, dead-letter queue pattern, and escalation notifications.
+
+## Priority 4: Automated remediation via Identity MCP
+
+- [ ] Confirm Phase-gate controls so any write actions stay disabled until approvals are complete.
+- [ ] Define remediation action catalog mapped to mismatch categories (disable account, update manager, queue provisioning task).
+- [ ] Add mandatory approval checks (ticket ID, approver identity, timestamp, change reason) before any write path.
+- [ ] Build rollback procedures per remediation type and test rollback on non-production data.
+- [ ] Add post-action validation checks to confirm AD/Entra state now matches Workday source-of-truth.
+
+## Priority 5: Measurement and reporting (SMART metrics)
+
+- [ ] Establish Q1 2026 baseline for mean-time-to-provision (MTTP) using existing onboarding tickets.
+- [ ] Define MTTP formula and data source contract so measurements are reproducible.
+- [ ] Implement weekly identity drift report generation with trend lines by mismatch type.
+- [ ] Add dashboard metrics required for Q3 target tracking:
+- [ ] MTTP reduction percentage versus Q1 baseline.
+- [ ] Total mismatches detected per week.
+- [ ] Percent auto-resolved versus human-resolved mismatches.
+- [ ] Manual reconciliation hours eliminated.
+- [ ] Publish weekly report distribution list and archival location for audit retention.
+
+## Priority 6: Security, compliance, and operational hardening
+
+- [ ] Run a log redaction test to verify no secrets or restricted fields are emitted.
+- [ ] Perform least-privilege review across Workday ISU, MCP host identity, and Power Automate connectors.
+- [ ] Add change-control requirements for schema updates and new tool introduction.
+- [ ] Create a quarterly access recertification checklist for service accounts and app registrations.
+- [ ] Add synthetic monitoring checks for token acquisition, endpoint latency, and tool health.
+- [ ] Create incident response runbook for sync failures, auth failures, and drift-report pipeline outages.
+
+## Priority 7: Delivery plan by quarter
+
+- [ ] Q2 milestone 1: close all unblocking dependencies and complete non-prod end-to-end read-only validation.
+- [ ] Q2 milestone 2: complete Workday MCP core tools plus correlation logic and automated mismatch classification.
+- [ ] Q2 milestone 3: deploy Power Automate daily sync and ticketed approval workflow to pilot scope.
+- [ ] Q3 milestone 1: enable weekly drift reporting to IT Operations with stable SLA performance.
+- [ ] Q3 milestone 2: complete production rollout and retire manual reconciliation process.
+- [ ] Q3 milestone 3: verify at least 30 percent MTTP reduction against Q1 baseline and document evidence.
+
+## Immediate next 10 execution steps
+
+- [ ] Confirm OAuth grant type in writing and record decision in implementation plan.
+- [ ] Request and obtain non-prod Workday API credentials.
+- [ ] Implement and test one Workday MCP tool in API mode.
+- [ ] Lock response schema allowlist in tests.
+- [ ] Define correlation key precedence and test with sample identity data.
+- [ ] Implement first mismatch detector: terminated-in-Workday but active-in-AD.
+- [ ] Stand up daily Power Automate check flow in non-production.
+- [ ] Generate first weekly drift report draft and validate with IT Operations.
+- [ ] Pilot one human-approved remediation path end-to-end.
+- [ ] Capture baseline MTTP and publish first KPI scorecard.
+
+## Suggested status tracking tags
+
+- [ ] Add one tag to each backlog item: BLOCKED, READY, IN_PROGRESS, VALIDATING, DONE.
+- [ ] Add owner and target date to each item before sprint planning.
+- [ ] Review and update this backlog weekly until Q3 completion.

Workday/Planning/workday-ad-identity-sync-sprint-board.md

@@ -0,0 +1,55 @@
+---
+title: "Workday to AD identity sync — sprint board"
+description: "Sprint-ready execution board converted from the next-steps backlog."
+type: "Sprint Board"
+version: "v1"
+author: "N. Castaldi"
+date: "2026-04-03"
+source: "workday-ad-identity-sync-next-steps.md"
+---
+
+## Usage
+
+- Update Status using: BLOCKED, READY, IN_PROGRESS, VALIDATING, DONE.
+- Replace placeholder owners and dates during sprint planning.
+- Keep one row per deliverable-sized work item.
+
+## Sprint board
+
+| ID | Work item | Priority | Owner | Target date | Dependency | Definition of done | Verification | Status |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| WIS-001 | Finalize OAuth grant type and token lifecycle policy | P0 | Unassigned | 2026-04-10 | Security + HRIS decision meeting | Decision record approved and stored in repo | Review signed decision doc and confirm policy values | READY |
+| WIS-002 | Provision non-prod Workday API credentials and tenant access | P0 | Unassigned | 2026-04-12 | WIS-001 | Service account/API client active in non-prod with read-only scope | Run connectivity script and receive valid token + successful API call | READY |
+| WIS-003 | Confirm ISU, security group, and domain read-only permissions | P0 | Unassigned | 2026-04-12 | WIS-002 | Approved least-privilege matrix published | Validate permissions against allowlist and denylist checklist | READY |
+| WIS-004 | Publish field allowlist and explicit denylist in version control | P0 | Unassigned | 2026-04-13 | WIS-003 | Field-scope policy document merged and referenced by tests | Peer review confirms all sensitive domains excluded | READY |
+| WIS-005 | Create endpoint mapping table for all five Workday tools | P0 | Unassigned | 2026-04-14 | WIS-004 | Tool-to-endpoint mapping complete with request/response/error contracts | Trace each tool to endpoint and run contract review | READY |
+| WIS-006 | Scaffold Workday MCP project files to Identity parity | P1 | Unassigned | 2026-04-16 | WIS-005 | Server, backend, adapter, debug script, tests, and pyproject created | Local startup succeeds in memory mode | READY |
+| WIS-007 | Implement memory backend with deterministic worker fixtures | P1 | Unassigned | 2026-04-17 | WIS-006 | Fixtures cover active, terminated, future-dated, contractor cases | Unit tests pass for fixture-driven tool outputs | READY |
+| WIS-008 | Implement API backend token flow with secure secret loading | P1 | Unassigned | 2026-04-18 | WIS-006, WIS-002 | OAuth token acquisition and refresh work with no secrets in code/logs | Integration smoke test obtains token and executes read call | READY |
+| WIS-009 | Implement and validate first tool: getWorkerStatus | P1 | Unassigned | 2026-04-19 | WIS-008, WIS-005 | Tool returns allowlisted fields only with stable schema | Run tool in non-prod and compare to expected schema | READY |
+| WIS-010 | Add allowlist schema validation tests for all tool outputs | P1 | Unassigned | 2026-04-20 | WIS-009, WIS-004 | Automated tests fail on disallowed fields and pass on compliant output | Execute test suite and confirm gate behavior | READY |
+| WIS-011 | Implement remaining tools: worker, org attributes, manager, effective dates | P1 | Unassigned | 2026-04-22 | WIS-009, WIS-010 | All five read-only tools operational in memory and API modes | Run tool-by-tool smoke checks and integration tests | READY |
+| WIS-012 | Add adapter resilience for 401/403/404/429/5xx with retry/timeouts | P1 | Unassigned | 2026-04-23 | WIS-011 | Error handling and backoff logic validated by tests | Mock HTTP scenarios and verify controlled responses | READY |
+| WIS-013 | Define canonical correlation key precedence across Workday and AD | P2 | Unassigned | 2026-04-24 | WIS-011 | Correlation strategy documented and approved | Validate mapping against sample records with edge cases | READY |
+| WIS-014 | Implement mismatch detector: terminated in Workday but active in AD | P2 | Unassigned | 2026-04-25 | WIS-013 | Rule triggers correctly and emits actionable mismatch record | Run detector on test dataset with known outcomes | READY |
+| WIS-015 | Implement mismatch detector: future-dated hire prematurely provisioned | P2 | Unassigned | 2026-04-26 | WIS-013 | Rule identifies early-provisioning violations | Validate against future-dated hire scenarios | READY |
+| WIS-016 | Implement mismatch detector: active worker missing in AD | P2 | Unassigned | 2026-04-27 | WIS-013 | Missing-account cases are detected without false positives | Reconcile detector output with manually curated sample set | READY |
+| WIS-017 | Implement mismatch detector: manager mismatch | P2 | Unassigned | 2026-04-28 | WIS-013 | Manager differences flagged with both source values | Compare output to Workday and AD manager fields | READY |
+| WIS-018 | Implement mismatch detector: contractor past end date still active | P2 | Unassigned | 2026-04-29 | WIS-013 | Expired contractor access identified and categorized | Validate with contractor end-date test records | READY |
+| WIS-019 | Build Power Automate daily sync flow (non-prod) | P3 | Unassigned | 2026-05-02 | WIS-011, WIS-014-WIS-018 | Daily flow executes MCP calls and writes run telemetry | Trigger flow manually and by schedule; verify run logs | READY |
+| WIS-020 | Build Power Automate weekly drift reporting flow | P3 | Unassigned | 2026-05-03 | WIS-019 | Weekly report generated, distributed, and archived | Confirm report delivery list receives expected summary | READY |
+| WIS-021 | Add idempotency controls to avoid duplicate tickets/actions | P3 | Unassigned | 2026-05-04 | WIS-019 | Duplicate processing prevented across reruns | Execute repeated test runs and confirm no duplicate artifacts | READY |
+| WIS-022 | Integrate ticket approval gate before remediation execution | P4 | Unassigned | 2026-05-06 | WIS-019, WIS-021 | No remediation executes without valid approval metadata | Attempt unapproved run and confirm hard block | READY |
+| WIS-023 | Define remediation action catalog mapped to mismatch types | P4 | Unassigned | 2026-05-07 | WIS-014-WIS-018 | Action matrix approved by IAM/Security and IT Ops | Review matrix and sign off in change record | READY |
+| WIS-024 | Implement rollback procedures and tests for each remediation action | P4 | Unassigned | 2026-05-09 | WIS-023 | Rollback path documented and successfully tested for each action | Execute rollback drills in non-prod with evidence captured | READY |
+| WIS-025 | Instrument KPI baseline for Q1 2026 MTTP | P5 | Unassigned | 2026-05-10 | Access to historical onboarding tickets | Baseline dataset and formula documented | Recompute baseline independently and match results | READY |
+| WIS-026 | Implement KPI dashboard metrics and weekly trend outputs | P5 | Unassigned | 2026-05-12 | WIS-020, WIS-025 | Dashboard shows MTTP delta, drift volume, resolution mode split, hours saved | Validate dashboard calculations against raw report data | READY |
+| WIS-027 | Enable production logging/redaction and operational monitoring | P6 | Unassigned | 2026-05-14 | WIS-012, WIS-026 | Request-level logs, redaction checks, and health monitors active | Run synthetic checks for auth, latency, and failure paths | READY |
+| WIS-028 | Execute pilot rollout and validate SLA/severity routing | P6 | Unassigned | 2026-05-16 | WIS-022, WIS-027 | Pilot operates without policy violations and with acceptable false-positive rate | 2-week pilot report accepted by IT Operations | READY |
+| WIS-029 | Production cutover and manual reconciliation retirement | P7 | Unassigned | 2026-06-15 | WIS-028 | Automated process is primary; manual reconciliation decommissioned | Confirm no manual reconciliation tasks required for 2 cycles | READY |
+| WIS-030 | Q3 outcome verification and executive evidence pack | P7 | Unassigned | 2026-09-30 | WIS-029 | Evidence shows >=30% MTTP reduction and weekly drift reports running | Validate KPI package against baseline and audit records | READY |
+
+## Notes
+
+- Date placeholders are proposed sequencing dates and should be adjusted to active sprint cadence.
+- If needed, split large items into child stories but preserve the same ID as parent epic prefix.

Workday/Planning/workday-mcp-implementation-plan.md

@@ -0,0 +1,139 @@
+---
+title: "Workday MCP — implementation and auth plan"
+description: "Execution plan to build a read-only Workday MCP server using the proven Identity MCP pattern."
+type: "Implementation Plan"
+version: "v1"
+author: "N. Castaldi"
+date: "2026-03-11"
+---
+
+## Objective
+
+Build a read-only Workday MCP server by reusing the implementation pattern that succeeded in the Identity MCP server, while replacing the AD/PowerShell adapter with a Workday REST/OAuth adapter.
+
+## Scope for first release
+
+Included:
+- Read-only tools only:
+    - workday.getWorker(identifier)
+    - workday.getWorkerStatus(identifier)
+    - workday.getWorkerOrgAttributes(identifier)
+    - workday.getWorkerManager(identifier)
+    - workday.getWorkerEffectiveDates(identifier)
+- Workday MCP project scaffolding equivalent to the Identity MCP structure
+- In-memory backend for local contract testing
+- API backend for Workday REST integration
+- Unit tests and integration smoke tests
+- Logging and audit controls
+
+Excluded:
+- Any write actions to Workday
+- Any HR transaction support
+- Ticketing automation from Workday MCP
+- Correlation/remediation execution logic beyond read-only outputs
+
+## Current decisions captured
+
+- API family for v1: REST only
+- Security model: least privilege, read-only field scope
+- Deployment model: phased rollout aligned to existing Workday install guide
+- Architecture pattern: dual backend (`memory` default, `api` production)
+
+## Build plan (execution sequence)
+
+1. Clone the Identity MCP skeleton into Workday equivalents.
+2. Create Workday backend contract with five async tool methods.
+3. Implement in-memory backend with safe sample worker payloads.
+4. Implement FastMCP server entrypoint and tool wrappers.
+5. Implement Workday REST adapter with OAuth token handling.
+6. Add config and secret-loading contract.
+7. Add adapter unit tests with mocked HTTP/token responses.
+8. Add non-prod integration smoke tests for end-to-end validation.
+9. Validate output schema allowlist and excluded fields.
+10. Publish runbook updates and final verification checklist.
+
+## Files to create for parity with Identity MCP
+
+- workday_mcp_server.py
+- workday_backend.py
+- workday_adapter.py
+- debug_workday_connectivity.py
+- pyproject.toml
+- .gitignore
+- tests/test_workday_adapter.py
+- tests/test_integration.py
+
+## Authentication implementation requirements
+
+1. Use Workday REST API with OAuth 2.0 for API calls.
+2. Use a dedicated Integration System User (ISU) for MCP access.
+3. Register and manage a dedicated Workday API client for this service.
+4. Restrict security group and domain permissions to approved read-only fields.
+5. Keep separate credentials and client configuration for non-production and production.
+6. Store client secret/token material in approved secret storage, never in code.
+7. Enforce token refresh, timeout, retry, and rate-limit handling in adapter logic.
+
+## Data to gather (required before build proceeds)
+
+### A. Workday auth and tenant details
+- Tenant name(s) for non-production and production
+- Base API host URL(s)
+- Approved OAuth grant type for this integration
+- Token endpoint details and expected token lifetime
+- Refresh token policy and rotation requirements
+
+### B. Identity and access control details
+- ISU account name and owner
+- Integration security group name
+- Exact domain permissions approved for read-only use
+- Explicit list of denied domains/fields
+
+### C. Endpoint and schema contract
+- Exact Workday REST endpoints for each of the 5 tools
+- Required request parameters and lookup identifiers
+- Expected success payload shape per endpoint
+- Error payload examples for 401/403/404/429/5xx
+
+### D. Operations and observability
+- Required logging sink and retention policy
+- Required audit fields per MCP invocation
+- Retry/backoff thresholds and timeout limits
+- Rate-limit constraints provided by tenant admins
+
+## Current blockers
+
+1. OAuth grant type is not finalized.
+2. Ownership for credential and security-group provisioning is not assigned.
+3. Non-production Workday tenant/sandbox access is not yet available.
+4. Exact endpoint-to-tool mapping is not finalized.
+5. Approved field allowlist and denylist are not yet locked to testable schema contracts.
+
+## Dedicated next steps
+
+1. Assign owner for Workday auth provisioning (HRIS or IAM/Security) and confirm accountable approver.
+2. Finalize OAuth grant type and token lifecycle policy in a short design decision record.
+3. Provision non-production tenant access and generate non-prod API client credentials.
+4. Confirm ISU + security group + domain permissions for read-only scope.
+5. Produce endpoint mapping table (tool -> endpoint -> fields -> error contract).
+6. Create initial Workday project scaffold and run server in memory mode.
+7. Implement adapter token flow and one tool end-to-end in non-prod.
+8. Expand to all five tools and complete unit plus integration test gates.
+9. Validate logs and outputs for secret safety and field-scope compliance.
+10. Update install guide with exact run/test commands once implementation is proven.
+
+## Verification checklist
+
+- [ ] All blocker items are resolved and documented.
+- [ ] Server starts in memory mode and API mode.
+- [ ] All five tools return only approved fields.
+- [ ] Unit tests pass with mocked auth and API error scenarios.
+- [ ] Integration tests pass against non-production tenant.
+- [ ] No secrets appear in logs.
+- [ ] Audit logs capture tool name, parameters, timestamp, and result status.
+
+## Related documents
+
+- [workday-mcp-install-guide.md](./workday-mcp-install-guide.md)
+- [CoPilot Generated Deployment Plan.md](./CoPilot%20Generated%20Deployment%20Plan.md)
+- [CoPilot Generated Additional Steps.md](./CoPilot%20Generated%20Additional%20Steps.md)
+- [../Identity/implementation-guide.md](../Identity/implementation-guide.md)

Workday/Planning/workday-mcp-install-guide.md

@@ -0,0 +1,287 @@
+---
+title: "Workday MCP — Deployment and install guide"
+description: "Step-by-step guide for deploying a read-only Workday MCP server for identity context, drift detection, and controlled remediation workflows."
+type: "Install Guide"
+version: "v1"
+author: "N. Castaldi"
+date: "2026-03-11"
+---
+
+<!-- Guide Title and Logo Row -->
+<div style="display: flex; align-items: center; justify-content: space-between; margin-bottom: 1.5em;">
+  <h1 style="margin: 0; font-size: 2em;">Workday MCP — Deployment and install guide</h1>
+  <img src="https://rwdn-uploads.s3.amazonaws.com/mcgl15001/production/54b7a8d305541296303508cec6e5dfb6.png" alt="Company Logo" style="height:60px; max-width:180px; object-fit:contain;">
+</div>
+
+## Table of contents
+
+- [Introduction](#introduction)
+- [Definitions](#definitions)
+- [Prerequisites / Required tools & access](#prerequisites--required-tools--access)
+- [Installation procedure](#installation-procedure)
+- [Post-installation actions](#post-installation-actions)
+- [Troubleshooting / Escalation procedures](#troubleshooting--escalation-procedures)
+- [References / Related documents](#references--related-documents)
+- [Revision history](#revision-history)
+
+---
+
+## Introduction
+
+### Purpose
+
+This guide explains how to deploy a **read-only Workday MCP** that provides authoritative workforce context to downstream identity and device workflows. The deployment is designed to improve visibility and drift detection without enabling any HR record modification.
+
+### Audience
+
+HRIS owners, IAM and AD owners, Security, and Deskside or IT Operations teams responsible for identity governance and integration controls.
+
+### Scope
+
+This guide covers phased implementation of a Workday Context MCP from governance alignment through operational controls. It intentionally excludes any capability to perform HR write actions.
+
+The MCP in this guide:
+
+- Observes workforce data through scoped read-only endpoints
+- Correlates workforce state with AD, Entra, and device context
+- Supports human-approved remediation through downstream IT-owned systems
+
+The MCP in this guide does not:
+
+- Provision users
+- Trigger hires or terminations
+- Modify worker records
+- Replace PECI or existing HR integrations
+
+---
+
+## Definitions
+
+| Term | Definition |
+| --- | --- |
+| **MCP** | Model Context Protocol interface exposing approved tools and context to AI clients |
+| **Workday MCP** | Read-only MCP server that surfaces workforce attributes from Workday for downstream identity reasoning |
+| **HRIS** | Human Resources Information System; Workday is the source-of-truth HRIS in this design |
+| **ISU** | Integration System User in Workday used for API-based integration access |
+| **Identity drift** | Mismatch between authoritative workforce state and downstream identity or access state |
+| **Source of Truth (SoT)** | Authoritative system of record; Workday remains SoT for workforce status |
+
+---
+
+## Prerequisites / Required tools & access
+
+Complete all prerequisites before implementation work begins.
+
+- [ ] Security and HR sign-off on read-only contextual access
+- [ ] Stakeholder alignment across HRIS, IAM or AD owners, Security, and IT Ops
+- [ ] Workday Integration System User (ISU) created for the MCP service
+- [ ] OAuth 2.0 or approved API credential method configured
+- [ ] API access scoped to GET-only endpoints
+- [ ] Repository established for version-controlled tool manifests
+- [ ] Logging destination approved for request-level audit events
+
+> **No AI-facing deployment begins until governance agreements are documented and approved.**
+
+---
+
+## Installation procedure
+
+Deploy the Workday MCP in seven controlled phases.
+
+```mermaid
+flowchart LR
+    phase-governance[Phase 0: Governance and alignment] --> phase-foundation[Phase 1: Integration foundation]
+    phase-foundation --> phase-tools[Phase 2: Tool surface definition]
+    phase-tools --> phase-validation[Phase 3: Read-only validation]
+    phase-validation --> phase-correlation[Phase 4: Correlation with identity]
+    phase-correlation --> phase-remediation[Phase 5: Human-approved remediation]
+    phase-remediation --> phase-controls[Phase 6: Audit and lifecycle controls]
+```
+
+| Phase | Capability | Risk level |
+| --- | --- | --- |
+| 0 | Governance and read-only agreement | None |
+| 1 | Integration foundation | Low |
+| 2 | Approved tool surface and field scope | Low |
+| 3 | Drift detection and read-only validation | Low |
+| 4 | Cross-system correlation | Low |
+| 5 | Human-approved remediation orchestration | Medium (controlled) |
+| 6 | Audit and lifecycle controls | Low |
+
+---
+
+### Step 1: Governance and alignment (Phase 0)
+
+**Objective:** Establish ownership boundaries and non-negotiable control agreements before technical build.
+
+1. Confirm required stakeholders are assigned and accountable:
+    - HRIS (Workday owner)
+    - IAM or AD owners
+    - Security
+    - Deskside or IT Ops
+2. Record and approve the following agreements:
+    - Workday remains the sole Source of Truth for workforce status
+    - MCP access is read-only
+    - Identity actions remain IT-owned
+    - MCP insights may recommend but do not execute
+3. Obtain Security and HR sign-off on read-only contextual access.
+
+✅ **Exit criteria:** Signed governance agreement with read-only scope and ownership boundaries.
+
+---
+
+### Step 2: Integration foundation (Phase 1)
+
+**Objective:** Build a secure Workday MCP integration layer without exposing AI tooling yet.
+
+1. Configure a dedicated Workday ISU for the MCP server.
+2. Configure OAuth 2.0 (or approved equivalent) for API authentication.
+3. Restrict access to GET-only endpoints required for approved context fields.
+4. Confirm there is no custom UI access and no background mutation jobs.
+
+✅ **Exit criteria:** Workday MCP server can authenticate and retrieve data through read-only API paths only.
+
+---
+
+### Step 3: Tool surface definition (Phase 2)
+
+**Objective:** Expose only identity-relevant workforce context under least privilege.
+
+1. Implement the approved core tools:
+
+    ```powershell
+    workday.getWorker(identifier)
+    workday.getWorkerStatus(identifier)
+    workday.getWorkerOrgAttributes(identifier)
+    workday.getWorkerManager(identifier)
+    workday.getWorkerEffectiveDates(identifier)
+    ```
+
+2. Limit output fields to:
+    - Worker ID
+    - Name and email
+    - Employment status (active, terminated, future-dated)
+    - Job profile
+    - Cost center or department
+    - Location
+    - Manager
+3. Explicitly exclude:
+    - Compensation
+    - Performance
+    - Benefits
+    - Payroll
+    - Medical and protected fields
+4. Validate field exposure with HRIS policy owners.
+
+✅ **Exit criteria:** HR confirms exposed fields align to least-privilege policy.
+
+---
+
+### Step 4: Read-only validation and drift detection (Phase 3)
+
+**Objective:** Prove the MCP can detect drift accurately without triggering changes.
+
+1. Validate representative read-only scenarios:
+    - User active in AD but terminated in Workday
+    - User manager mismatch between AD and Workday
+    - Future-dated hires missing in AD
+    - Contractor end date passed in Workday
+2. Document expected versus actual results for each validation case.
+3. Confirm all outputs are informational only and do not trigger remediation actions.
+
+✅ **Exit criteria:** Workday MCP reliably answers identity-state questions with no write behavior.
+
+---
+
+### Step 5: Correlation with Identity MCP (Phase 4)
+
+**Objective:** Enable AI reasoning across workforce, identity, and device context.
+
+1. Integrate data flow in this order:
+    - Workday MCP (Source of Truth)
+    - Identity MCP (AD and Entra state)
+    - Device or access decision context (for reporting and recommendations)
+2. Validate cross-system insights, including:
+    - Who should exist versus who does exist
+    - Users with access who are no longer employees
+    - Future-dated hires that should not be provisioned yet
+3. Confirm Workday MCP remains context-only and never issues AD updates.
+
+✅ **Exit criteria:** Cross-system insights are accurate and no direct identity writes originate from Workday MCP.
+
+---
+
+### Step 6: Human-approved remediation workflows (Phase 5)
+
+**Objective:** Use detected drift to support existing SOPs while preserving separation of duties.
+
+1. Implement the operational pattern:
+
+    ```text
+    1. AI detects mismatch
+    2. AI explains cause (Workday vs AD or Entra)
+    3. Human selects remediation path
+    4. Identity MCP or existing automation executes
+    5. Ticket is updated with result
+    ```
+
+2. Ensure remediation remains in IT-owned systems and not in Workday MCP.
+3. Validate tickets include decision, execution details, and closure evidence.
+
+✅ **Exit criteria:** Remediation is human-approved, auditable, and executed by approved downstream systems.
+
+---
+
+### Step 7: Audit, security, and lifecycle controls (Phase 6)
+
+**Objective:** Harden operational controls for steady-state use.
+
+1. Enable request-level logging for every MCP invocation.
+2. Record at minimum: tool name, parameters, timestamp, and result status.
+3. Ensure no expansion of PII beyond approved fields.
+4. Version-control all tool definitions and review changes through standard change control.
+5. Validate for Workday release cycles and schema changes before production rollout changes.
+6. Rotate integration credentials per policy and restrict server access to approved hosts.
+
+✅ **Exit criteria:** Logging, change management, and access lifecycle controls are operating and verified.
+
+---
+
+## Post-installation actions
+
+- Run a weekly control review for the first 60 days after go-live.
+- Review drift-detection false positives and tune query logic where needed.
+- Reconfirm field-level scope with HRIS and Security before adding any new tool.
+- Re-validate after each Workday release window and after identity schema changes.
+- Keep remediation SOP references current and linked to ticket templates.
+
+---
+
+## Troubleshooting / Escalation procedures
+
+| Issue | Resolution |
+| --- | --- |
+| Workday MCP authentication fails | Verify ISU status, OAuth credentials, token scope, and API endpoint allow-list. |
+| Tool returns incomplete worker attributes | Confirm requested fields are in approved scope and available in Workday API response mapping. |
+| Drift query results appear inconsistent with AD | Validate identity correlation key mapping (worker ID, email, or employee ID) and check for stale cache. |
+| Read-only contract is violated by a new tool proposal | Reject deployment, remove tool from manifest, and route through security and HR governance review. |
+| Audit log entries missing | Pause production use until logging is restored and event flow validation passes. |
+| Unexpected PII appears in output | Immediately disable affected tool, remove unapproved fields, and complete incident review. |
+
+**Support Contact:** Raise a ticket with IT Automation and include HRIS owner review if policy scope or data classification is involved.
+
+---
+
+## References / Related documents
+
+- [Model Context Protocol MCP — Developer guide (sqlservercentral.com)](https://www.sqlservercentral.com/articles/model-context-protocol-mcp-a-developers-guide-to-long-context-llm-integration)
+- [Model Context Protocol guide (artificialintelligenceschool.com)](https://artificialintelligenceschool.com/model-context-protocol-mcp-guide/)
+- [MCP servers explained (dev.to)](https://dev.to/jamie_thompson/mcp-servers-explained-how-ai-assistants-connect-to-your-tools-598o)
+
+---
+
+## Revision history
+
+| Version | Date | Author | Description |
+| --- | --- | --- | --- |
+| v1 | 2026-03-11 | N. Castaldi | Initial draft |