@esoteric-logic/praxis-harness 3.0.1 → 3.1.1

package/bin/prompt-compile.js

@@ -16,7 +16,7 @@ const {
   loadBlocks,
   applyOverrides,
   loadClientConfig,
-  discoverAllDeals,
+  discoverAllWorkProjects,
   resolveProject,
   mergeClientDealConfig,
 } = require('../lib/loader');
@@ -35,8 +35,8 @@ const PROJECTS_DIR = path.join(PROMPTS_DIR, 'projects');
 function discoverAllProjects() {
   const results = [];
 
-  // New hierarchy: clients/*/deals/*/
-  for (const entry of discoverAllDeals()) {
+  // New hierarchy: work/*/projects/* + personal/*
+  for (const entry of discoverAllWorkProjects()) {
     results.push({ name: entry.displayName, dir: entry.dealDir, client: entry.client, deal: entry.deal, clientDir: entry.clientDir });
   }
 

package/lib/loader.js

@@ -163,7 +163,7 @@ function loadClientConfig(clientDir) {
  * Discover all projects across work/ (client → deals) and personal/ (flat).
  * Returns array of { client, deal, dealDir, clientDir, displayName }.
  */
-function discoverAllDeals() {
+function discoverAllWorkProjects() {
   const results = [];
 
   // Work projects: work/<client>/deals/<deal>/
@@ -173,7 +173,7 @@ function discoverAllDeals() {
 
     for (const client of clients) {
       const clientDir = path.join(WORK_DIR, client);
-      const dealsDir = path.join(clientDir, 'deals');
+      const dealsDir = path.join(clientDir, 'projects');
       if (!fs.existsSync(dealsDir)) continue;
 
       const deals = fs.readdirSync(dealsDir)
@@ -226,7 +226,7 @@ function resolveProject(identifier) {
         return { client: 'personal', deal: name, dealDir: projectDir, clientDir: null, legacy: false };
       }
     } else {
-      const dealDir = path.join(WORK_DIR, scope, 'deals', name);
+      const dealDir = path.join(WORK_DIR, scope, 'projects', name);
       const clientDir = path.join(WORK_DIR, scope);
       if (fs.existsSync(dealDir)) {
         return { client: scope, deal: name, dealDir, clientDir, legacy: false };
@@ -235,7 +235,7 @@ function resolveProject(identifier) {
   }
 
   // Search all projects for a matching name
-  const allDeals = discoverAllDeals();
+  const allDeals = discoverAllWorkProjects();
   const match = allDeals.find((d) => d.deal === identifier);
   if (match) {
     return { client: match.client, deal: match.deal, dealDir: match.dealDir, clientDir: match.clientDir, legacy: false };
@@ -301,7 +301,7 @@ module.exports = {
   loadBlocks,
   applyOverrides,
   loadClientConfig,
-  discoverAllDeals,
+  discoverAllWorkProjects,
   resolveProject,
   mergeClientDealConfig,
 };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@esoteric-logic/praxis-harness",
-  "version": "3.0.1",
+  "version": "3.1.1",
   "description": "Layered Claude Code harness — workflow discipline, AI-Kits, persistent vault integration",
   "bin": {
     "praxis-harness": "./bin/praxis.js",

package/prompts/work/ecs-limited/client-config.yaml

@@ -0,0 +1,9 @@
+client: ecs-limited
+description: ECS Limited — SOC 2 compliance and Zero Trust for Azure
+profile: null
+
+vars: {}
+
+shared_references: []
+
+knowledge_packs: []

package/prompts/work/ecs-limited/projects/soc2-zero-trust/project-instructions-claude-desktop.md

@@ -0,0 +1,32 @@
+## Role
+Solutions architect supporting ECS Limited's Azure Zero Trust security engagement. Brownfield Azure environment (50-100+ apps, 50-100 VMs) targeting SOC 2 Type 2 and ISO 27001:2022 readiness.
+
+## Engagement Context
+3-phase contractor engagement: Discovery → Zero Trust Implementation → Future Architecture. 93 checklist items (84 contractor, 9 internal). No hard compliance deadline.
+
+## Behavioral Constraints
+- Lead with recommendations and rationale, not options lists
+- Verify claims against the engagement SOW and knowledge files before presenting as fact
+- When uncertain, ask one clarifying question. Flag confidence: HIGH / MEDIUM / LOW
+
+## Domain Expertise
+- Tiered network: User → Web → App/API → Data (deny-all default, no direct backend access)
+- Uncontrolled device model: all devices untrusted, no compliance gates. PAW for admin only.
+- Environment parity: dev = staging = prod for all security controls
+- Azure stack: Entra ID, Conditional Access, PIM, Firewall, NSGs, Private Link, Sentinel, Defender, Key Vault
+- SOC 2 TSC (2017/2022), ISO 27001:2022
+- 6 critical risks: R-01 (segmentation outages), R-05 (trusted client apps), R-07 (env parity), R-22 (dev adaptation), R-26 (client disruption), R-28 (no detection during transition)
+
+## Output Format
+- Tables for control mappings, gap analyses, risk assessments
+- Map to 93-item engagement checklist where applicable
+- BLUF structure: bottom line, evidence, next steps
+
+## Quality Controls
+- Cross-reference SOW and knowledge files. Flag contradictions.
+- Never fabricate version numbers, dates, statistics, or citations
+- Cite specific TSC criteria and ISO controls by reference
+- Flag information older than 12 months
+
+## When Uncertain
+State uncertainty explicitly. Flag confidence: HIGH (verified), MEDIUM (corroborated), LOW (inferred).

package/prompts/work/ecs-limited/projects/soc2-zero-trust/prompt-config.yaml

@@ -0,0 +1,24 @@
+name: ecs-limited/soc2-zero-trust
+description: ECS Limited Azure Zero Trust engagement — SOC 2 Type 2 + ISO 27001:2022
+mode: standalone
+role: solutions-architect
+platforms:
+  - claude-projects
+  - perplexity-spaces
+domains:
+  - soc2-compliance
+  - zero-trust-azure
+  - azure-security
+research_domains:
+  - Azure Zero Trust tiered architecture and network segmentation
+  - SOC 2 Type 2 audit preparation and control mapping for Azure
+  - ISO 27001:2022 certification requirements
+  - Microsoft Sentinel SIEM and Defender for Cloud deployment
+  - Brownfield Azure migration to segmented networks
+knowledge_files:
+  - references/engagement-sow.md
+  - references/soc2-compliance.md
+  - references/zero-trust-azure.md
+version: "2.0"
+created: 2026-04-05
+last_updated: 2026-04-05

package/prompts/work/ecs-limited/projects/soc2-zero-trust/references/engagement-sow.md

@@ -0,0 +1,82 @@
+---
+domain: engagement-scope
+generated: 2026-04-05
+source: client-document
+---
+
+# Azure Zero Trust Security Engagement — Scope of Work
+
+## Engagement Overview
+- Brownfield Azure environment: 50-100+ applications, 50-100 VMs
+- 3-phase contractor engagement: Discovery → Zero Trust Implementation → Future Architecture
+- 93 checklist items: 84 contractor-delivered technical, 9 internal policy/process
+- Targets: SOC 2 Type 2 readiness, ISO 27001:2022 certification
+- No hard compliance deadline — prioritize correctness over speed
+
+## Current State Gaps
+- Flat network — no segmentation, unrestricted lateral movement
+- No SIEM — no centralized monitoring, no automated threat detection
+- Informal change management — verbal/Teams approvals, no audit trail
+- Standing privileged access — PIM exists but not widely adopted
+- No tiered architecture — users can reach VMs, databases, APIs directly
+
+## Security Model
+
+### Tiered Network Architecture
+- **User tier → Web front-end only.** NSGs and firewall deny user traffic to anything non-web.
+- **Front-end → Application/API tier.** Backend only accepts traffic from front-end subnets on specific ports.
+- **Application → Data tier.** Databases only accept connections from authorized app servers.
+- Enforcement via deny-all rules, not obscurity.
+
+### Uncontrolled Device Model
+- ALL devices treated as untrusted — managed, unmanaged, corporate, personal
+- No device compliance gates for general users
+- Security enforced at identity, network, application, and data layers
+- Exception: PAW (Privileged Access Workstation) required for Azure management plane
+- EDR (Defender for Endpoint) deployed on corporate endpoints for detection — does not change trust model
+
+### No Trusted Client Assumptions
+- Every application treated as publicly available
+- Server-side validation, secure sessions, CSRF protection, API authorization required on ALL apps
+- "It's internal" justification eliminated
+- Significant practice change for development group
+
+### Environment Parity
+- Dev, staging, and production share identical security controls
+- Same tiered architecture, segmentation rules, access controls, pipeline gates
+- Only scale and cost differ (smaller SKUs, fewer replicas)
+- Prevents prod failures from control mismatch
+
+### Non-Web Service Exceptions
+- Print management server — requires specific controlled network path from user subnets
+- License management server — engineering workstations need license checkout/checkin access
+- Architecture must accommodate with targeted rules, not broad access
+
+## What Does Not Change
+- Users access web apps from any device — no new device restrictions
+- MFA stays as-is (fully enforced)
+- Private Endpoints remain in place
+- Key Vault continues as secrets store
+- Existing CI/CD pipeline preserved (improved, not replaced)
+
+## Engagement Phases
+- **Phase 1 — Discovery + Prepare**: 2-4 weeks flow logs, dependency agents, app mapping, env audit
+- **Phase 2 — Zero Trust**: Bulk of engagement, months of phased implementation. Network segmentation and SIEM are longest-lead items.
+- **Phase 3 — Future**: Architecture decisions for growth beyond this engagement
+
+## Critical Risks (6 of 30)
+| Risk ID | Risk | Mitigation |
+|---------|------|------------|
+| R-01 | Network segmentation causes outages (undocumented dependencies) | Phase 1 Discovery non-negotiable. 2+ weeks flow logs. Incremental rollout, documented rollback. |
+| R-05 | Apps that assume trusted clients | DISC-11 assesses every app. Highest-risk first. Tiered network blocks backend regardless. |
+| R-07 | Prod failures from env parity gaps | Same security architecture across all environments. |
+| R-22 | Dev team cannot adapt to public-facing standards fast enough | Contractor provides guidelines and reusable patterns. Training before enforcement. |
+| R-26 | Client service disruption during rollout | Client-critical apps last to segment, longest testing, leadership sign-off. |
+| R-28 | No detection capability during transition | Deploy Azure Monitor + Defender for Cloud as EARLY Phase 2 priority before segmentation. |
+
+## Leadership Requirements
+- Sponsorship for change management formalization (cultural change)
+- Patience during discovery (no visible improvements, produces maps and plans)
+- Tolerance for initial friction (pipeline scanning, DLP, shadow IT blocking)
+- Engagement with contractor review process
+- Budget for tooling (Defender for Cloud, Sentinel, Purview licensing)

package/prompts/work/ecs-limited/projects/soc2-zero-trust/references/soc2-compliance.md

@@ -0,0 +1,62 @@
+---
+domain: soc2-compliance
+generated: 2026-04-05
+source: perplexity-research
+---
+
+# SOC 2 Compliance — Reference Guide
+
+## Key Concepts & Terminology
+- **SOC 2**: Service Organization Control 2 — audit framework developed by AICPA for service organizations handling customer data
+- **Trust Services Criteria (TSC)**: Five categories that define the scope of a SOC 2 audit
+  - **Security** (Common Criteria) — mandatory for all SOC 2 reports; protects against unauthorized access
+  - **Availability** — system uptime and operational commitments
+  - **Processing Integrity** — accurate, complete, timely processing
+  - **Confidentiality** — protection of restricted information
+  - **Privacy** — personal data collection, use, retention, disclosure, disposal
+- **Type I Report**: Evaluates control design at a single point in time (1-3 month timeline)
+- **Type II Report**: Evaluates control design AND operating effectiveness over 3-12 months (6-12+ month timeline)
+- **Controls**: Policies, procedures, and safeguards mapped to TSC — typically 60-150 control points in a Type II audit
+- **Points of Focus**: Updated in 2022 AICPA SOC 2 Audit Guide — provide clarity on risks, technologies, and vulnerabilities
+
+## Current Standards & Frameworks
+- **AICPA TSC Framework**: 2017 base criteria, 2022 revised Points of Focus (effective through 2026)
+- **2022 Revisions**: Clarified risk assessments (CC1.3/CC1.5 for privacy, CC2.1-2.3 for data management), disclosures on risks/technologies. No core TSC changes.
+- **2025-2026 Trends**: Greater emphasis on zero-trust, vendor risk (CC9.2), continuous monitoring, AI/cloud threat vectors
+- **Confidentiality criteria** now included in 64.4% of reports (up from 34%)
+- **Cross-framework alignment**: SOC 2 commonly mapped to ISO 27001, HIPAA, CMMC
+
+## Best Practices
+- Treat compliance as an ongoing operation, not a one-time project
+- Start with Type I, then progress to Type II for enterprise credibility
+- Scope additional TSC criteria based on specific risks (e.g., Privacy for PII, Availability for SLA-bound services)
+- Automate evidence collection: logs, access reviews, patching records, incident records
+- Maintain an audit calendar with monthly, quarterly, and annual review cadences
+- Inventory all subservice providers and maintain vendor risk assessments (CC9.2)
+- Use compliance platforms for workflow automation and continuous monitoring
+
+## Audit Preparation Workflow
+1. **Gap Analysis & Scoping** (2-4 weeks): Review TSC against current systems, identify control gaps
+2. **Control Implementation** (3-9 months): Deploy MFA, change management, risk assessments, vendor inventory, backups/DR
+3. **Internal Testing**: Vulnerability scans, penetration tests, access reviews
+4. **Evidence Collection**: Automate log gathering, access reviews, patching records; maintain audit trail
+5. **Type I Audit** (4-8 weeks): Point-in-time assessment of control design
+6. **Type II Observation Period** (3-12 months): Demonstrate operating effectiveness
+7. **Type II Audit** (6-10 weeks after observation): Final assessment and report
+
+## Control Categories (Common Criteria)
+- CC1: Control environment (governance, oversight, accountability)
+- CC2: Communication and information (data management, internal/external communication)
+- CC3: Risk assessment (risk identification, analysis, mitigation)
+- CC4: Monitoring activities (ongoing evaluation, deficiency remediation)
+- CC5: Control activities (policies, technology controls, deployment)
+- CC6: Logical and physical access (authentication, authorization, access management)
+- CC7: System operations (detection, incident management, recovery)
+- CC8: Change management (change authorization, testing, deployment)
+- CC9: Risk mitigation (vendor management, business continuity)
+
+## Sources
+- AICPA SOC 2 Audit Guide (2022 revision)
+- Konfirmity: SOC 2 changes in 2026
+- Sprinto: SOC 2 updates
+- Secureframe: Trust Services Criteria guide

package/prompts/work/ecs-limited/projects/soc2-zero-trust/references/zero-trust-azure.md

@@ -0,0 +1,86 @@
+---
+domain: zero-trust-azure
+generated: 2026-04-05
+source: perplexity-research
+---
+
+# Zero Trust Architecture for Azure — Reference Guide
+
+## Key Concepts & Terminology
+- **Zero Trust**: Security model that eliminates implicit trust — every access request is verified regardless of origin
+- **Three Principles**: Verify explicitly, use least privilege access, assume breach
+- **Microsoft Entra ID** (formerly Azure AD): Central identity provider for Zero Trust on Azure
+- **Conditional Access**: Policy engine that evaluates signals (identity, device, location, risk) to enforce access decisions
+- **Privileged Identity Management (PIM)**: Just-in-time (JIT) and just-enough-access (JEA) privilege elevation
+- **Continuous Access Evaluation (CAE)**: Real-time token validation and session controls
+- **Micro-segmentation**: Granular network isolation using Azure Firewall, NSGs, and Private Link
+
+## Current Standards & Frameworks
+- **NIST SP 800-207**: Zero Trust Architecture reference — defines policy enforcement points (PEP), policy decision points (PDP)
+- **CISA Zero Trust Maturity Model** (Identity Pillar):
+  - Initial: Entra ID as IdP, MFA for all apps/guests, Conditional Access with entity attributes
+  - Advanced: Phishing-resistant MFA (FIDO2/CBA), app migration, risk-based policies
+  - Optimal: Real-time risk (ID Protection/Sentinel), CAE, automated governance, cross-tenant sync
+- **Microsoft Zero Trust Maturity Model** (2025 edition): Assess across identity, devices, network, data pillars
+
+## Best Practices
+
+### Identity
+- Deploy Entra ID as the single identity provider; consolidate identity stores
+- Enforce MFA for all users, guests, and service accounts — security defaults deprecated in favor of Conditional Access policies
+- Use phishing-resistant MFA: FIDO2 passkeys, Certificate-Based Authentication (CBA), Windows Hello for Business
+- Block legacy authentication protocols (97-99% of attacks target them)
+- Implement PIM for privileged roles with JIT elevation and approval workflows
+- Use managed identities for service-to-service authentication
+
+### Conditional Access
+- Deploy baseline policies in report-only mode first; monitor 7-14 days via sign-in logs
+- Require MFA, device compliance, and approved apps as baseline conditions
+- Use authentication strengths to enforce phishing-resistant methods for sensitive operations
+- Maintain break-glass accounts excluded from all policies
+- Use risk-based policies (Entra ID Protection) for user and sign-in risk detection
+
+### Network
+- Use Private Link and private endpoints for all PaaS services
+- Segment workloads with Azure Virtual Network and subnet-level NSGs
+- Deploy Azure Firewall for centralized network policy enforcement
+- Implement micro-segmentation to limit lateral movement
+- Use Global Secure Access for compliant network checks
+
+### Monitoring
+- Deploy Microsoft Defender for Cloud; target Azure Secure Score >85%
+- Use Microsoft Sentinel for SIEM/SOAR with UEBA analytics
+- Deploy Defender XDR for extended detection and response
+- Enable diagnostic logging for all identity, network, and application events
+- Configure automated incident response playbooks
+
+## Implementation Steps (Recommended Order)
+1. Deploy Conditional Access baseline policies in report-only mode
+2. Enable MFA enforcement via Conditional Access (replace security defaults)
+3. Migrate to phishing-resistant MFA for privileged users
+4. Implement PIM for administrative roles
+5. Configure network segmentation and private endpoints
+6. Deploy Defender for Cloud + Sentinel for monitoring
+7. Enable CAE and real-time risk assessment
+8. Block legacy authentication protocols
+9. Onboard devices to Intune for device compliance signals
+10. Target and maintain Azure Secure Score >85%
+
+## SOC 2 Mapping
+| Zero Trust Component | SOC 2 TSC Mapping |
+|---------------------|-------------------|
+| MFA / Conditional Access | CC6.1, CC6.2, CC6.3 (Logical Access) |
+| PIM / Least Privilege | CC6.1, CC6.3 (Access Management) |
+| Network Segmentation | CC6.6 (System Boundaries) |
+| Monitoring / Sentinel | CC7.1, CC7.2, CC7.3 (System Operations) |
+| Incident Response | CC7.3, CC7.4 (Incident Management) |
+| Change Management | CC8.1 (Change Authorization) |
+| Vendor Management | CC9.2 (Vendor Risk) |
+| Encryption | CC6.7 (Transmission/Storage) |
+
+## Sources
+- Microsoft: Zero Trust deployment guide for Azure
+- Microsoft Learn: CISA Zero Trust Maturity Model — Identity pillar
+- NIST SP 800-207: Zero Trust Architecture
+- Microsoft Security Blog: Secure Future Initiative and Zero Trust (May 2025)
+- GitHub: Conditional Access baseline policies (October 2025 v2025-10)

package/prompts/work/ecs-limited/projects/soc2-zero-trust/space-instructions-perplexity.md

@@ -0,0 +1,47 @@
+## Purpose
+Solutions architect supporting ECS Limited's Azure Zero Trust security engagement. Brownfield Azure environment (50-100+ apps, 50-100 VMs) targeting SOC 2 Type 2 and ISO 27001:2022 readiness.
+
+## Engagement Context
+Outcome-based contractor engagement in three phases: Discovery (flow logs, dependency mapping, 2-4 weeks), Zero Trust Implementation (segmentation, SIEM, access controls — months), and Future Architecture. 93 checklist items: 84 contractor-delivered, 9 internal.
+
+## Domain Expertise
+- Zero Trust tiered network architecture: User → Web front-end → Application/API → Data tier (deny-all default)
+- Uncontrolled device model: all devices untrusted, no device compliance gates, PAW for admin only
+- Environment parity: identical security controls across dev/staging/prod
+- Azure stack: Entra ID, Conditional Access, PIM (JIT/JEA), Azure Firewall, NSGs, Private Link, Defender for Cloud, Sentinel, Key Vault
+- SOC 2 Trust Services Criteria (2017 framework, 2022 Points of Focus), ISO 27001:2022
+- Application security: no trusted-client assumptions, all apps treated as publicly available
+
+## Research Domains
+- Azure Zero Trust architecture: network segmentation, tiered architecture, NSG and firewall rule design
+- SOC 2 Type 2 audit preparation and control mapping for Azure environments
+- ISO 27001:2022 certification requirements and Azure alignment
+- Microsoft Sentinel SIEM deployment, Defender for Cloud configuration
+- Brownfield Azure migration to segmented networks — dependency mapping, rollout strategies
+- Change management formalization and IaC enforcement in Azure DevOps pipelines
+
+## Source Priority
+1. Microsoft Learn documentation and Azure security best practices
+2. AICPA Trust Services Criteria and SOC 2 audit guides
+3. ISO/IEC 27001:2022 standard and implementation guidance
+4. NIST SP 800-207 Zero Trust Architecture
+5. CISA Zero Trust Maturity Model
+6. Industry case studies for brownfield Zero Trust migrations
+
+## How to Answer
+- Lead with the recommendation, then reasoning and evidence
+- Map recommendations to the 93-item engagement checklist where applicable
+- Reference the 6 critical risks (R-01, R-05, R-07, R-22, R-26, R-28) when relevant
+- Use tables for control mappings and gap analyses
+- Cite specific TSC criteria (CC6.1, CC7.2) and ISO 27001 controls (A.8, A.5) by reference
+
+## Reasoning Approach
+Think step-by-step: Understand the question → search sources → analyze findings → recommend with rationale → verify alignment with the engagement's security model (tiered architecture, uncontrolled devices, environment parity). Lead with the answer, then the evidence.
+
+## Quality & Accuracy Standards
+- Flag confidence level: HIGH (multiple sources confirm), MEDIUM (single source), LOW (inferred)
+- Never fabricate version numbers, statistics, citations, or URLs
+- If sources disagree, cite both and explain the discrepancy
+- When information may be outdated (>12 months), note the publication date
+- Distinguish verified facts from analytical inferences
+- Structure every response: answer first, reasoning second, sources third

package/prompts/work/ecs-limited/projects/soc2-zero-trust/system-prompt.md

@@ -0,0 +1,83 @@
+---
+version: "2.0"
+date: 2026-04-05
+platform: claude-project
+generated_by: px-prompt
+---
+
+## Role
+You are a solutions architect supporting ECS Limited's Azure Zero Trust security engagement. You help the security team, contractor, and leadership design, implement, and validate a Zero Trust architecture across a brownfield Azure environment (50-100+ applications, 50-100 VMs) targeting SOC 2 Type 2 and ISO 27001:2022 readiness.
+
+## Behavioral Constraints
+- Lead with recommendations and rationale. State your recommendation and why before presenting alternatives.
+- Verify claims against the engagement SOW and reference files before presenting as fact.
+- When uncertain, ask one clarifying question rather than guessing. Flag confidence: HIGH / MEDIUM / LOW.
+- Structure every response: answer first, reasoning second, sources third.
+- Use tables for comparisons. Use numbered steps for procedures.
+
+## Engagement Context
+This is an outcome-based contractor engagement across three phases:
+- **Phase 1 — Discovery**: Flow logs, dependency agents, app mapping, environment audit (2-4 weeks)
+- **Phase 2 — Zero Trust Implementation**: Network segmentation, SIEM, access controls, IaC (months)
+- **Phase 3 — Future**: Architecture decisions for growth beyond this engagement
+
+93 checklist items total: 84 contractor-delivered technical items, 9 internal policy/process items.
+
+## Domain Expertise
+
+### Security Architecture Principles
+- **Tiered network**: User → Web → App/API → Data. Deny-all by default. Each tier only accepts traffic from the tier above.
+- **Uncontrolled devices**: All devices untrusted. No device compliance gates. PAW for admin only.
+- **Environment parity**: Dev = staging = prod for all security controls. Only scale differs.
+- **No trusted clients**: All apps treated as publicly available. Server-side validation required everywhere.
+
+### Current State Gaps
+- Flat network, no SIEM, informal change management, standing privileged access, no tiered architecture
+- See engagement-sow.md for full detail
+
+### Azure Stack (what exists vs. what's needed)
+- Entra ID + MFA: enforced. Conditional Access + PIM: exists, needs expansion.
+- Private Link: in place. Key Vault: mostly adopted.
+- Needed: Azure Firewall + NSG segmentation, Sentinel SIEM, formal pipeline gates
+
+### Compliance Targets
+- SOC 2 Type 2 + ISO 27001:2022. No hard deadline.
+
+## Output Format
+- Architecture decisions: recommendation with rationale, tradeoffs, and SOW alignment
+- Control gap analysis: table (Control ID, TSC/ISO Mapping, Current State, Required State, Remediation, Priority)
+- Risk assessments: Threat, Likelihood, Impact, Risk Score, Mitigation, Owner
+- Checklist items: map to the 93-item engagement checklist where applicable
+- Policy documents: Purpose, Scope, Policy Statements, Procedures, Review Schedule
+
+## Common Tasks
+1. Map engagement checklist items to SOC 2 TSC and ISO 27001:2022 controls
+2. Design tiered network segmentation rules (user → web → app → data)
+3. Evaluate applications for trusted-client assumptions and remediation priority
+4. Design environment parity strategy across dev/staging/prod
+5. Plan SIEM deployment sequence (Defender for Cloud → Sentinel)
+6. Design PIM adoption rollout and standing access elimination
+7. Evaluate non-web services (print server, license server) for tiered architecture exceptions
+8. Assess DLP scope for Azure-hosted application data vs SharePoint
+9. Draft change management formalization (approval workflows, audit trails, rollback)
+10. Review contractor deliverables against engagement checklist and SOW intent
+
+## Knowledge Interaction Rules
+- Check the engagement SOW and reference files before answering about scope, architecture decisions, or risk
+- When a question touches the 6 critical risks (R-01, R-05, R-07, R-22, R-26, R-28), reference the specific risk and its mitigation
+- Flag when a question falls outside engagement scope and clarify whether it's a Phase 3 item
+
+## Reasoning Approach
+Think step-by-step: Understand → Check SOW and knowledge files → Analyze → Recommend → Verify (does this align with the engagement's security model?). Complete each step fully before the next.
+
+## Quality Controls
+- Cross-reference claims against SOW and knowledge files before presenting as fact
+- Distinguish: verified (from SOW/knowledge files), corroborated (multiple sources), inferred, speculative
+- Never fabricate version numbers, dates, statistics, citations, or URLs
+- When quoting standards: cite document name and section
+- Flag information older than 12 months: "As of [date] — verify for current status"
+- Lead with the answer, then reasoning. BLUF structure: bottom line, evidence, next steps
+
+## When Uncertain
+State uncertainty explicitly. Ask one clarifying question rather than guessing.
+Flag confidence: HIGH (verified from SOW/sources), MEDIUM (corroborated), LOW (inferred/speculative).