chore: archive legacy Identity, Workday, and Intune folders

- Move Identity/, Workday/, Intune/ to archive/ (superseded by nexus-mcp shards)
- Move 'Local Setup.md' to archive/ (superseded by nexus-mcp/Local-Setup.md)
- Add archive/README.md explaining migration and preserved content
- Clean repository structure: only nexus-mcp, documentation, and .github remain active

All legacy functionality migrated to nexus-mcp sharded architecture.
Archived folders preserved for reference and historical context.

Refs: SESSION_SNAPSHOT_2026-04-13.md

archive/Workday/Planning/Breadcrumbs/Gemini.md

@@ -0,0 +1,45 @@
+Here is a prioritized list of high-value tasks you can complete right now in your local workday-mcp environment:
+
+1. Expand the "Mismatch" Logic (WIS-014 – WIS-018)
+You’ve built the Manager scanner, but a true Identity Sync needs to detect several other types of drift.
+
+Job Title Mismatch: Build a tool to compare "Workday Title" vs "AD Title".
+
+Department Drift: Identify workers whose cost center in Workday doesn't match their AD Department string.
+
+Legal Name vs. Preferred Name: Build logic to handle cases where AD uses a "Display Name" that differs from the Workday "Legal Name".
+
+Status Reconciliation: Create a tool that specifically flags "Terminated" in Workday but "Enabled" in AD.
+
+2. Implement Schema Validation (WIS-010)
+Instead of just returning "any" dictionary, use a library like pydantic to enforce a strict contract.
+
+The Build: Create a WorkerModel that defines exactly what fields are required (e.g., employee_id must be a string of a certain length).
+
+The Test: Write a script that tries to "break" your tools by feeding them bad data to see if your error handling catches it gracefully.
+
+3. Build a "Dry Run" Comparison Tool (WIS-019)
+Before you ever automate a "Write" to Active Directory, you need a tool that simulates the change.
+
+The Logic: Create a tool that takes a Workday record and an AD record (both mocked for now) and returns a "Diff" object.
+
+Output Example: {"field": "department", "old": "Sales", "new": "Marketing", "action": "update"}.
+
+4. Hardening & Security (WIS-027 & Priority 6)
+Prepare for the "Production" environment requirements.
+
+Log Redaction: Update your server to ensure that if an error occurs, it doesn't print sensitive data (like emails or IDs) to the console/logs.
+
+Environment Configuration: Move your "Constants" (like port numbers or mock file paths) into a .env file and use the python-dotenv library to load them.
+
+Rate Limiting Simulation: Workday APIs have limits. Build a "decorator" for your tools that simulates a delay or a "429 Too Many Requests" error to test how your server handles it.
+
+5. Documentation & "Self-Service" (WIS-027)
+Build an MCP Resource: MCP supports "Resources" (read-only files). Create a resource that serves a "Data Dictionary" explaining what every Workday field means.
+
+Installation Script: Write a simple setup.sh or setup.bat that automates the creation of the .venv and installation of requirements for the next person who joins the project.
+
+6. Unit Testing (The "Quality" Pillar)
+Pytest Integration: Create a /tests folder and write tests that verify your get_worker_manager logic for all three scenarios (Found, Not Found, No Manager).
+
+CI/CD Simulation: Set up a local Git Hook that prevents you from committing code if it has Pylance errors or failing tests.

archive/Workday/Planning/Breadcrumbs/Microsoft Copilot.md

@@ -0,0 +1,279 @@
+Perfect — this gives us the **real-world shape** of the Workday record we should design around, *before* you ever get API access. Based on what you pasted, your **Employee ID is numeric (8 digits)** and you have a stable set of “Job Details” + “Public Contact” fields we can treat as your **Phase 1 canonical Worker contract**. [\[wheelsinc-...epoint.com\]](https://wheelsinc-my.sharepoint.com/personal/castn1_wheels_com/Documents/Microsoft%20Copilot%20Chat%20Files/server.py)
+
+Below I’m going to do two things:
+
+1.  Translate your Workday profile into a **clean canonical schema** (fields, types, constraints) that you can enforce with Pydantic (**WIS-010**) now.
+2.  Show how that schema feeds your **dry-run diff tool** (**WIS-019**) and your later Workday→AD sync logic—without needing Workday access yet.
+
+***
+
+## 1) What your profile tells us about “employee\_id” (and constraints)
+
+From your profile:
+
+*   `Employee ID` = `10016638` → **numeric string**, **8 digits** (at least in your tenant).
+*   This is a **better primary key** than email or name for matching to AD.
+
+### Recommended constraint (for now)
+
+*   Treat `employee_id` as a **string** (not int) to preserve leading zeros if they exist in other records.
+*   Enforce pattern: `^[0-9]{8}$` (8 digits)
+
+> If you later discover IDs vary (e.g., 6–10 digits), you can loosen the regex to `^[0-9]{6,10}$` without breaking downstream contracts.
+
+***
+
+## 2) Canonical Worker Schema (Phase 1 / no Workday API required)
+
+Here’s a **normalized Worker model** derived from your field list. I’m using names that are stable + automation-friendly, while keeping the original Workday labels clear.
+
+### Field mapping (Workday → canonical)
+
+**Identity**
+
+*   `employee_id` ← Employee ID (string, 8-digit numeric)
+*   `work_email` ← Email (string, email format)
+
+**Org / Reporting**
+
+*   `supervisory_organization` ← Supervisory Organization (string)
+*   `manager_name` ← Supervisory Organization trailing manager name (string, optional)
+*   `manager_employee_id` ← (not present in your paste; optional until Workday API provides it)
+
+**Job**
+
+*   `position` ← Position
+*   `business_title` ← Business Title
+*   `job_profile` ← Job Profile
+*   `employee_type` ← Employee Type (e.g., Regular)
+*   `management_level` ← Management Level (e.g., Individual Contributor)
+*   `time_type` ← Time Type (e.g., Full time)
+*   `fte_percent` ← FTE (decimal percent)
+
+**Employment dates**
+
+*   `hire_date` ← Hire Date (date)
+*   `original_hire_date` ← Original Hire Date (date)
+*   `continuous_service_date` ← Continuous Service Date (date)
+
+**Location**
+
+*   `location` ← Location
+*   `work_address` ← Work Address (string)
+
+### Why this specific cut matters
+
+This set gives you enough to drive:
+
+*   onboarding timing (hire date)
+*   basic directory attributes (title, department-like org fields, location)
+*   reporting chain resolution (supervisory org / manager)
+*   future group mapping (job profile, employee type, management level)
+
+…and it’s stable enough to validate *before* Workday access.
+
+***
+
+## 3) How I’d update your current MCP server **right now** (targeted improvements)
+
+Your current `server.py` is a solid scaffold, but it’s using:
+
+*   mock IDs like `EMP001`, and
+*   a flat dict with fields (`name`, `status`, `dept`, `email`, `manager_id`) [\[wheelsinc-...epoint.com\]](https://wheelsinc-my.sharepoint.com/personal/castn1_wheels_com/Documents/Microsoft%20Copilot%20Chat%20Files/server.py)
+
+To align with *real Workday data* **before you ever connect**:
+
+### A) Switch your mock dataset to real ID format
+
+Change mock keys from `EMP001` → `10016638` style.
+
+*   This forces you to solve input validation and casing issues now (numeric IDs have no casing).
+*   It prevents later refactors when Workday is live.
+
+### B) Standardize your tool outputs (strongly recommended)
+
+Right now, tools return either:
+
+*   a worker dict OR
+*   `{"error": ...}` [\[wheelsinc-...epoint.com\]](https://wheelsinc-my.sharepoint.com/personal/castn1_wheels_com/Documents/Microsoft%20Copilot%20Chat%20Files/server.py)
+
+Before Workday access, lock in a stable envelope like:
+
+```json
+{
+  "ok": true,
+  "data": { ... },
+  "error": null,
+  "meta": {
+    "correlation_id": "uuid",
+    "source": "mock",
+    "contract_version": "wis.v1"
+  }
+}
+```
+
+Why now? Because Power Automate + connectors love consistent shapes. If you wait, you’ll end up rewriting flows and schemas later.
+
+### C) Build Pydantic models for:
+
+*   Worker input (`WorkerModel`)
+*   Tool response (`WorkerStatusResponse`)
+*   Error (`ErrorModel`)
+*   Envelope (`ToolResponse[T]`)
+
+This is the core of **WIS-010**.
+
+***
+
+## 4) Concrete Pydantic Contract Proposal (WIS-010)
+
+Here’s the **contract design** I recommend based on your profile fields and your automation goals.
+
+### WorkerModel constraints (recommended)
+
+*   `employee_id`: `^[0-9]{8}$`
+*   `work_email`: must validate as email
+*   `fte_percent`: 0–100 (float)
+*   `time_type`: enum (`Full time`, `Part time`, etc.)
+*   Dates: parsed into real `date` objects
+
+### “Strict mode” recommendation
+
+Start with:
+
+*   `extra="forbid"` (reject unknown fields)
+*   later relax to `extra="ignore"` if Workday payloads contain extra fields you don’t care about
+
+This gives you confidence early.
+
+***
+
+## 5) Your Dry-Run Diff Tool (WIS-019) — now shaped by real Workday fields
+
+Once you validate Workday-shaped inputs, your dry-run diff becomes meaningful:
+
+### What it should compare (Phase 1 scope)
+
+From the fields you pasted, your first drift checks should include:
+
+*   Title / Business Title / Job Profile
+*   Location
+*   Manager / supervisory org reference
+*   Employee status → AD enabled/disabled state
+*   Email → UPN/mail alignment
+
+### Diff item example (your intended format + enhancements)
+
+You suggested:
+
+```json
+{"field":"department","old":"Sales","new":"Marketing","action":"update"}
+```
+
+I’d add two fields **now** that become critical in Phase 3:
+
+*   `severity` (low/medium/high)
+*   `reversible` (true/false)
+
+Example:
+
+```json
+{
+  "field": "business_title",
+  "old": "Team Lead, Deskside Support",
+  "new": "Team Lead, Deskside Support",
+  "action": "none",
+  "severity": "low",
+  "reversible": true
+}
+```
+
+Then your approval payload can be generated directly from the diff result (no extra logic later).
+
+***
+
+## 6) Break Tests you can run **today** (with your real constraints)
+
+Since we now know your ID shape, your “try to break it” script should include:
+
+### Employee ID failure cases
+
+*   empty string `""`
+*   non-numeric `"EMP001"`
+*   wrong length `"1001663"` (7 digits), `"100166380"` (9 digits)
+*   whitespace `" 10016638 "`
+
+### Data failures (WorkerModel)
+
+*   invalid email `"not-an-email"`
+*   FTE out of range `150.0`
+*   Hire date invalid `"2021-13-40"`
+*   Missing required fields (`employee_id`, `work_email`)
+
+### Expected behavior
+
+*   Tools return `ok:false`
+*   Error has stable code (e.g., `VALIDATION_ERROR`)
+*   No sensitive fields are echoed in logs (see below)
+
+This is how you prove WIS-010 is real, not theoretical.
+
+***
+
+## 7) Security/Hardening decisions informed by your profile fields
+
+Because Workday records contain PII-like data (email, address), your hardening step (WIS-027) should **explicitly redact**:
+
+*   `work_email`
+*   `work_address`
+*   `employee_id` (optional partial mask like `******38`)
+
+### Redaction policy (recommended)
+
+*   In logs: redact always
+*   In tool responses:
+    *   keep email if the tool is intended for automation and access is controlled
+    *   or provide a config switch: `RETURN_PII=false` (defaults safe)
+
+This is much easier to implement now than after Workday is live.
+
+***
+
+# 8) What I would change in your current `server.py` (actionable list)
+
+In order, **before Workday API access**:
+
+1.  **Replace EMP### mock IDs with numeric employee IDs** (like your `10016638`) [\[wheelsinc-...epoint.com\]](https://wheelsinc-my.sharepoint.com/personal/castn1_wheels_com/Documents/Microsoft%20Copilot%20Chat%20Files/server.py)
+2.  **Add Pydantic WorkerModel + Response envelope** (WIS-010) [\[wheelsinc-...epoint.com\]](https://wheelsinc-my.sharepoint.com/personal/castn1_wheels_com/Documents/Microsoft%20Copilot%20Chat%20Files/server.py)
+3.  **Normalize tool outputs** into `{ok,data,error,meta}` for every tool [\[wheelsinc-...epoint.com\]](https://wheelsinc-my.sharepoint.com/personal/castn1_wheels_com/Documents/Microsoft%20Copilot%20Chat%20Files/server.py)
+4.  **Implement dry\_run\_compare() tool** returning a typed DiffResult (WIS-019)
+5.  **Add rate-limit simulation decorator** and make errors explicitly retryable (WIS-027)
+6.  **Add log redaction helper** for email/address/employee\_id (WIS-027)
+7.  **Externalize mock data** into JSON + support multiple scenario datasets
+8.  **Pytest suite**: manager resolution scenarios (Found/Not Found/No Manager) using your mock structure [\[wheelsinc-...epoint.com\]](https://wheelsinc-my.sharepoint.com/personal/castn1_wheels_com/Documents/Microsoft%20Copilot%20Chat%20Files/server.py)
+9.  **Pre-commit hooks** to block commits on failing tests/lint
+
+***
+
+## 9) Two quick questions so I lock the schema correctly
+
+1.  In your tenant, is **Employee ID always 8 digits**, or have you seen contractors/vendors with a different format?
+2.  Do you want **Work Address** treated as:
+    *   a field you *store* in AD/Entra, or
+    *   *reference only* (used for location logic but not written anywhere)?
+
+***
+
+## If you want, I can take the next step automatically
+
+If you say “go,” I’ll draft:
+
+*   A **Pydantic schema pack** (`models.py`) for WorkerModel, DiffResult, Envelope
+*   A revised `server.py` that:
+    *   uses numeric employee IDs
+    *   returns consistent envelopes
+    *   includes `dry_run_compare`
+    *   includes redaction + rate-limit simulation toggles
+*   A `/tests` folder with the manager tests + “break tests” script
+
+Just tell me whether you prefer **Pydantic v1 or v2** (most orgs are v2 now, but I’ll match your repo dependency reality).

archive/Workday/Planning/Breadcrumbs/README

@@ -0,0 +1,3 @@
+# Breadcrumbs
+
+- Folder contains info and ideas to get back on the path after vacation.

archive/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.
+
+***

archive/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.”**
+
+***

archive/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.

archive/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.

archive/Workday/Planning/workday-cross-team-access-request-draft.md

@@ -0,0 +1,49 @@
+---
+title: "Workday to AD sync — cross-team access request draft"
+description: "Draft message to align Workday, Security, IT Ops, and Compliance stakeholders on non-prod access and governance prerequisites."
+type: "Draft Communication"
+version: "v1"
+author: "N. Castaldi"
+date: "2026-04-03"
+status: "DRAFT"
+---
+
+## Subject
+
+Request to align on Workday-to-AD automation access and data requirements
+
+## Draft message
+
+Hi team,
+
+I am leading an initiative to reduce manual onboarding and identity reconciliation work by connecting Workday worker status data to our identity operations workflow (AD/Entra), starting in non-production. The objective is to improve speed, reduce manual errors, and provide a repeatable view of identity mismatches before any remediation actions are considered.
+
+To move this forward safely, I need alignment and approvals across teams on the following:
+
+- Confirm the right Workday data fields we are approved to use.
+- Provision non-prod API access and integration credentials.
+- Approve auth/token and least-privilege scope.
+- Confirm secrets handling and runtime connectivity path.
+- Validate privacy/compliance guardrails on allowed vs restricted attributes.
+
+What I need from each group:
+
+- HRIS/Workday owner: confirm required business fields, source-of-truth definitions, and authoritative business rules.
+- Workday integration admin: provide non-prod API endpoint details and create integration account/client credentials.
+- Security/IAM: approve authentication approach, token lifecycle expectations, and least-privilege scopes.
+- Platform/IT operations: confirm approved secret storage mechanism and runtime connectivity path.
+- Compliance/privacy (if required): validate allowed versus restricted attributes and retention/logging constraints.
+
+Proposed next step:
+
+I am requesting a 30-minute working session next week to confirm owners, decisions, and timeline. Once these dependencies are closed, we can begin non-prod validation and provide a clear readiness update.
+
+Thank you for partnering on this. The outcome is a lower-risk, more reliable identity process with stronger operational visibility.
+
+## Notes for sender
+
+- Keep this message as-is for broad audience send.
+- Customize the timeline sentence after checking stakeholder availability.
+- Attach supporting docs:
+- [workday-ad-identity-sync-next-steps.md](workday-ad-identity-sync-next-steps.md)
+- [workday-ad-identity-sync-sprint-board.md](workday-ad-identity-sync-sprint-board.md)

archive/Workday/Planning/workday-cross-team-conversation-playbook.md

@@ -0,0 +1,206 @@
+---
+title: "Workday to AD sync — cross-team conversation playbook"
+description: "Detailed prep and conversation guide for closing Workday access, security, connectivity, and compliance prerequisites."
+type: "Execution Playbook"
+version: "v1"
+author: "N. Castaldi"
+date: "2026-04-03"
+status: "DRAFT"
+---
+
+## Purpose
+
+Use this playbook to run focused conversations with each stakeholder group so prerequisites are closed quickly and in the right sequence.
+
+## Core outcomes to close
+
+- Confirm the right Workday data fields we are approved to use.
+- Provision non-prod API access and integration credentials.
+- Approve auth/token and least-privilege scope.
+- Confirm secrets handling and runtime connectivity path.
+- Validate privacy/compliance guardrails on allowed vs restricted attributes.
+
+## Recommended sequence
+
+1. HRIS/Workday owner (field and business-rule alignment)
+2. Workday integration admin (API enablement and credentials)
+3. Security/IAM (auth and access approval)
+4. Platform/IT operations (secrets and runtime path)
+5. Compliance/privacy (data handling validation)
+
+## Global prep package (have ready before any meeting)
+
+- Project one-liner: what problem is being solved and expected operational value.
+- Scope boundaries: read-only non-prod pilot first; no write/remediation in initial phase.
+- High-level workflow: Workday source data -> MCP read tools -> mismatch reporting.
+- Target timeline: requested decision date and target pilot start date.
+- Draft field list: requested attributes and intended usage for each.
+- Architecture summary: where code runs, how credentials are stored, who can access logs.
+- Risk controls summary: least privilege, redaction, audit logging, approval gates.
+- Decision log template: owner, decision, date, follow-up tasks.
+
+## Team-by-team conversation guide
+
+## HRIS / Workday functional owner
+
+### Objective
+
+Confirm business semantics and approved fields so downstream technical setup is based on correct policy and definitions.
+
+### You need to have ready
+
+- Draft list of required worker attributes and why each is needed.
+- Proposed source-of-truth assumptions (status, manager, effective dates).
+- Examples of mismatch scenarios the process needs to detect.
+- Definition of out-of-scope fields for phase 1.
+
+### You need to ask them
+
+- Which exact fields are approved for this use case?
+- Which fields are restricted or require additional approvals?
+- What are the authoritative business rules for worker status transitions?
+- Are there known edge cases (contractors, leaves, future hires) we must handle?
+- Who is final approver for field-level usage decisions?
+
+### Expected outputs
+
+- Approved field allowlist.
+- Explicit denylist/restricted-field list.
+- Confirmed business-rule references and data definitions.
+- Named functional approver.
+
+## Workday integration administrator
+
+### Objective
+
+Enable non-prod API connectivity and provide integration credentials aligned to approved field scope.
+
+### You need to have ready
+
+- Approved field allowlist from HRIS discussion.
+- Required endpoint list mapped to planned tools.
+- Environment details for where integration will run.
+- Requested timeline for first non-prod connectivity test.
+
+### You need to ask them
+
+- Which non-prod endpoint base URLs should be used?
+- What auth mechanism is supported for this integration pattern?
+- What integration client/account needs to be created?
+- What scopes/permissions are required to support approved fields only?
+- What are token TTL, refresh behavior, rate limits, and expected error patterns?
+- Who owns credential rotation and break-glass procedures?
+
+### Expected outputs
+
+- Non-prod API endpoint details.
+- Integration account/client provisioned.
+- Initial credentials or secure retrieval path.
+- API constraints documented (timeouts, throttling, limits).
+
+## Security / IAM
+
+### Objective
+
+Approve authentication model, token lifecycle, and least-privilege access boundaries before runtime connection is enabled.
+
+### You need to have ready
+
+- Proposed auth flow and token lifecycle design.
+- Requested scopes and rationale tied to allowlisted fields.
+- Role and access matrix (who can access secrets/logs/runtime).
+- Incident handling approach for auth failures.
+
+### You need to ask them
+
+- Does the proposed auth/token approach meet policy?
+- Are requested scopes minimal and compliant?
+- What are mandatory controls for token rotation and revocation?
+- What logging or audit evidence is required for periodic review?
+- What security sign-off is required before pilot launch?
+
+### Expected outputs
+
+- Auth model approved or revised with clear action items.
+- Scope approvals documented.
+- Token governance requirements confirmed.
+- Security sign-off owner identified.
+
+## Platform / IT operations
+
+### Objective
+
+Confirm where and how secrets are managed and verify runtime network/connectivity path for non-prod calls.
+
+### You need to have ready
+
+- Proposed runtime host/environment details.
+- Secret storage options and preferred approach.
+- Connectivity requirements (egress destinations, DNS, firewall needs).
+- Operational support expectations (monitoring, alerting, on-call routing).
+
+### You need to ask them
+
+- Which secret manager/process is approved for this workload?
+- How should credentials be injected at runtime?
+- What network rules are required to reach non-prod Workday endpoints?
+- What observability minimums are required for production readiness?
+- What is the escalation path for connectivity or runtime failures?
+
+### Expected outputs
+
+- Approved secret handling pattern.
+- Confirmed runtime connectivity path and network changes.
+- Logging/monitoring baseline requirements.
+- Platform support owner and escalation model.
+
+## Compliance / privacy
+
+### Objective
+
+Validate that data usage, storage, logging, and retention patterns meet privacy and compliance requirements.
+
+### You need to have ready
+
+- Approved allowlist and denylist.
+- Data flow summary showing where attributes are read, transformed, and stored.
+- Logging and redaction plan.
+- Retention and deletion approach for reports/log artifacts.
+
+### You need to ask them
+
+- Are approved attributes compliant for this use case?
+- Are any attributes subject to heightened controls?
+- What retention period and deletion controls are required?
+- What masking/redaction standards are required in logs and reports?
+- Is a formal privacy review or exception request required?
+
+### Expected outputs
+
+- Compliance disposition for field usage.
+- Required privacy controls documented.
+- Retention requirements confirmed.
+- Named compliance approver and any follow-up tasks.
+
+## Meeting cadence and format
+
+- Format: 30-minute focused decision sessions.
+- Cadence: run in sequence within one week.
+- Artifacts: update decision log immediately after each session.
+- Escalation: unresolved decision over 3 business days escalates to project sponsor.
+
+## Suggested tracking table
+
+| Workstream | Owner | Decision due | Current status | Blocker | Next action |
+| --- | --- | --- | --- | --- | --- |
+| Field allowlist/denylist | Unassigned | TBD | READY | None | Schedule HRIS review |
+| Non-prod API credentials | Unassigned | TBD | READY | None | Confirm integration admin owner |
+| Auth/token and scope approval | Unassigned | TBD | READY | None | Schedule IAM review |
+| Secrets and connectivity path | Unassigned | TBD | READY | None | Confirm platform review participants |
+| Privacy/compliance validation | Unassigned | TBD | READY | None | Share data-flow summary |
+
+## References
+
+- [workday-ad-identity-sync-next-steps.md](workday-ad-identity-sync-next-steps.md)
+- [workday-ad-identity-sync-sprint-board.md](workday-ad-identity-sync-sprint-board.md)
+- [workday-mcp-implementation-plan.md](workday-mcp-implementation-plan.md)

archive/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)

archive/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 |