chore: Full consistency scan — AOC->PULSAR, fix training-data claims, fix 90% claim

AOC -> PULSAR across 10 files (engagement-model, retained-capability, modular-engagements, blue-purple-team-foundation, about-cqre, about-cqre-cs, consultant-field-guide, ai-assisted-tvm, m365-e3-hardening, sovereign-tool-stack, risk-register-example). Training-data framing corrected in: - executive-summary.md: opening paragraph and risk table - README.md: 90% solution claim -> 30-60% in 180 days - modular-engagements.md: public API data use claim - cis-controls-mapping.md: data protection framing - antifragile-risk-register.md: risk entry softened to accurate framing - azure-openai-sovereignty-bridge.md: consumer vs enterprise API distinction Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>
feat: Add critical infrastructure adaptation for Rule 5 (greenfield)
2026-06-05 07:05:13 +00:00 · 2026-06-05 06:58:07 +00:00 · 2026-06-05 06:53:31 +00:00 · 2026-06-05 06:44:32 +00:00 · 2026-06-05 05:19:21 +00:00 · 2026-06-05 04:59:20 +00:00
22 changed files with 772 additions and 227 deletions
@@ -47,7 +47,8 @@ Most security and resilience frameworks optimize for **robustness**—the abilit
 │   ├── ad-endpoint-hardening.md    # On-prem AD, Windows endpoint, hybrid identity
 │   ├── zero-budget-hardening.md    # Maximize existing tool investment
 │   ├── implementation-playbook.md  # Step-by-step operational guide
-│   ├── sovereign-tool-stack.md     # Open-source arsenal and capability map
+│   ├── cqre-product-suite.md       # ASTRAL, PULSAR, AURORA: details, alignment, deployment
 │   ├── sovereign-tool-stack.md     # Full arsenal: CQRE products, open-source, and commercial tools
 │   ├── privileged-access-architecture.md # PAM: Teleport, Tailscale/Headscale, JIT access (Module 13)
 │   ├── sovereign-communications.md # Delta Chat chatmail, Matrix/Element, crisis channels (Module 14)
 │   └── business-case-template.md  # Financial justification and ROI framework
@@ -68,11 +69,17 @@ Most security and resilience frameworks optimize for **robustness**—the abilit
 └── assets/                         # Diagrams, visuals, and presentation materials
 ```
 ## What Is Brownhat?
 Brownhat is the delivery brand for CQRE consulting engagements. The name is a deliberate rejection of the traditional hat colour taxonomy in security (black hat / white hat / grey hat) — our work is not about adversarial simulation or compliance theatre. It is about the unglamorous, practical work of making real environments more resilient: brownfield by design, working with what exists, fixing what matters most.
 The **Brownhat methodology** is the operational posture behind every engagement: move fast, extract value from existing investments, and close existential gaps before they become incidents. The **Brownhat Diagnostic** is the specific entry engagement — a structured NIST CSF 2.0 baseline assessment that every new client completes before any module recommendation is made.
 ## Our Posture: Move Fast and Fix Things
 This practice is built on a simple, actionable stance: **move fast and fix things**. We do not wait for perfect plans. We identify the kill chain, extract value from existing investments, and close existential gaps before they become incidents.
- **Speed is a security control.** A 90% solution deployed today outperforms a 100% solution that ships in six months.
+- **Speed is a security control.** A realistic engagement delivers 30–60% of an ideal posture in 180 days — infinitely better than the 100% solution that stays in planning and never ships.
 - **Work beats purchases.** Most organizations own 60-80% of the capabilities they need. We configure and operationalize before we shop.
 - **Every fix must produce a signal.** A remediation without telemetry is a remediation that will rot.
@@ -92,6 +99,9 @@ Our approach is not an alternative to established frameworks. It is the fastest
 - **[CIS Controls v8](reference/cis-controls-mapping.md)** — IG1 as a non-negotiable 90-day floor, achieved primarily through existing tool configuration
 - **[NIST CSF 2.0](reference/nist-csf-mapping.md)** — All six functions addressed with emphasis on GOVERN as the missing keystone
 - **NIS2 (EU 2022/2555)** — Every engagement produces direct evidence for the Article 21 measures: configuration management (ASTRAL), logging and monitoring (PULSAR), access control, and incident detection. Essential and important entities under NIS2 will find the Brownhat module set directly maps to their supervisory obligations.
 - **DORA (EU 2022/2554)** — ICT change management records (ASTRAL Git trail), incident log retention (PULSAR), and ICT third-party risk governance map onto DORA Articles 10 and 11. Designed for financial entities who need demonstrable controls, not documentation exercises.
 - **GDPR Article 32** — Continuous configuration governance and audit log retention constitute "appropriate technical measures" under the accountability principle. Evidence produced by ASTRAL and PULSAR is directly usable in DPA and auditor reviews.
 ## Quick Start for Executives and Board Members
@@ -64,7 +64,7 @@ Risks related to loss of control over data, intelligence, or infrastructure.
 | Risk | Kill Chain | T0? | Antifragile Move |
 |------|-----------|-----|-----------------|
-| Proprietary data trains competitor AI models | Data → cloud AI → model improvement → competitive erosion | Yes | Deploy local or Azure OpenAI with data protection guarantees; classify AI data flows |
+| Proprietary data processed by uncontrolled AI | Data → cloud AI → residency/audit exposure → regulatory or competitive risk | Yes | Deploy sovereign or enterprise AI with verified data residency and audit rights; classify all AI data flows |
 | Cloud vendor changes terms or pricing | Terms change → operational disruption → forced migration under duress | Yes | Document exit architecture; maintain data portability; dual-vendor readiness |
 | Vendor discontinues critical service | Service ends → workflow collapse → emergency procurement | T1 | Maintain abstraction layers; escrow agreements; 90-day exit plans |
@@ -153,14 +153,14 @@ Next review:      14 April 2025
 | **Impact** | 3 — Significant. Primarily a compliance and investigation impact rather than operational failure. |
 | **Traditional risk score** | 9 — P3 (elevated to P2 due to regulatory exposure) |
 | **Optionality impact** | Moderate. Once logs are deleted, the option to investigate and prove scope is permanently lost. |
-| **Convexity** | High. Extending retention to 180 days requires E3 Compliance Add-on (≈€8/user/month) or ingestion into a long-term log store (AOC + blob storage). Cost vs. cost of regulatory non-compliance is asymmetric. |
+| **Convexity** | High. Extending retention to 180 days requires E3 Compliance Add-on (≈€8/user/month) or ingestion into a long-term log store (PULSAR + blob storage). Cost vs. cost of regulatory non-compliance is asymmetric. |
-| **Current control** | M365 Unified Audit Log at 90-day default. No secondary storage. AOC not yet deployed. |
+| **Current control** | M365 Unified Audit Log at 90-day default. No secondary storage. PULSAR not yet deployed. |
-| **Antifragile move** | 1. Deploy AOC to ingest and persist audit logs beyond the 90-day window into the organisation's own infrastructure (MongoDB + blob storage). 2. Alternatively, evaluate E3 Compliance Add-on for extended Microsoft-native retention. 3. Document retention policy and verify it meets applicable regulatory requirements (NIS2 Article 21 recommends 12+ months). |
+| **Antifragile move** | 1. Deploy PULSAR to ingest and persist audit logs beyond the 90-day window into the organisation's own infrastructure (MongoDB + blob storage). 2. Alternatively, evaluate E3 Compliance Add-on for extended Microsoft-native retention. 3. Document retention policy and verify it meets applicable regulatory requirements (NIS2 Article 21 recommends 12+ months). |
 | **Owner** | CISO / IT Manager |
 | **Target date** | 30 April 2025 (P2 — within 90 days) |
 | **Status** | Open |
-| **Stress-to-signal mandate** | If an incident reveals log gaps: AOC deployed immediately post-incident; retention policy reviewed and extended to regulatory minimum; board notified of compliance gap. |
+| **Stress-to-signal mandate** | If an incident reveals log gaps: PULSAR deployed immediately post-incident; retention policy reviewed and extended to regulatory minimum; board notified of compliance gap. |
-| **Verification method** | AOC deployed with log ingestion confirmed. Oldest ingested log age exceeds 180 days within 6 months of deployment. Retention policy documented and signed off. |
+| **Verification method** | PULSAR deployed with log ingestion confirmed. Oldest ingested log age exceeds 180 days within 6 months of deployment. Retention policy documented and signed off. |
 ---
@@ -178,8 +178,8 @@ Next review:      14 April 2025
 | **Traditional risk score** | 12 — P2 |
 | **Optionality impact** | Moderate. Without detection, the organisation cannot exercise the option to contain and eject an attacker early. |
 | **Convexity** | High. Building a detection engineering cell (1 FTE equivalent) costs ≈€150K/year and makes the €102K/year MSSP investment 3× more effective. |
-| **Current control** | MSSP with generic ruleset. AOC not deployed. No custom detection rules. MSSP SLA measures ticket response time, not detection coverage. |
+| **Current control** | MSSP with generic ruleset. PULSAR not deployed. No custom detection rules. MSSP SLA measures ticket response time, not detection coverage. |
-| **Antifragile move** | 1. Conduct a purple team TTP coverage test against the MSSP (5 TTPs, as described in the Retained Capability document). 2. Deploy AOC to add M365-specific detection on top of the MSSP. 3. Write 3–5 custom detection rules for the highest-priority Meridian-specific TTPs (OT/IT boundary crossing, service account anomalies, large SharePoint exports). 4. Add detection coverage rate to the MSSP SLA. 5. Consider a retained capability arrangement to maintain and extend the custom ruleset. |
+| **Antifragile move** | 1. Conduct a purple team TTP coverage test against the MSSP (5 TTPs, as described in the Retained Capability document). 2. Deploy PULSAR to add M365-specific detection on top of the MSSP. 3. Write 3–5 custom detection rules for the highest-priority Meridian-specific TTPs (OT/IT boundary crossing, service account anomalies, large SharePoint exports). 4. Add detection coverage rate to the MSSP SLA. 5. Consider a retained capability arrangement to maintain and extend the custom ruleset. |
 | **Owner** | IT Manager / outsourced CISO |
 | **Target date** | 30 June 2025 (P2 — within 90 days to start; sustained programme) |
 | **Status** | Open |
@@ -75,7 +75,7 @@ Jsme malá, specializovaná praxe. Neprovozujeme 24/7 operační centrum. Nepode
 **6. [PLACEHOLDER: Vaše šestá diferenciace]**
-> **INTERNÍ POZNÁMKA** — Přidejte diferenciaci specifickou pro vaši praxi. Příklady: hluboká odbornost v konkrétním odvětví (OT/energie, české regulatorní prostředí); proprietární nástroje (ASTRAL, AOC, Elysium); jazykové schopnosti; specifické certifikace; metodologický přístup.
+> **INTERNÍ POZNÁMKA** — Přidejte diferenciaci specifickou pro vaši praxi. Příklady: hluboká odbornost v konkrétním odvětví (OT/energie, české regulatorní prostředí); proprietární nástroje (ASTRAL, PULSAR, Elysium); jazykové schopnosti; specifické certifikace; metodologický přístup.
 [PLACEHOLDER: konkrétní diferenciace s jedním konkrétním příkladem nebo důkazem]
@@ -1,5 +1,11 @@
 # About CQRE · Brownhat
 > ⚠️ **TEMPLATE — NOT READY TO SHARE** ⚠️
 >
 > This document contains unfilled `[PLACEHOLDER]` sections. **Do not share this file with clients or external contacts until every placeholder has been replaced with real content and all INTERNAL NOTE sections have been removed.**
 >
 > To check: `grep -r "\[PLACEHOLDER\]" about-cqre.md` should return no results before this file leaves the repository.
 >
 > *This document introduces CQRE and the Brownhat methodology to new clients and new team members. Fill every `[PLACEHOLDER]` section with specific, honest information. Avoid generic consulting language — clients can tell. The sections marked **INTERNAL NOTE** contain guidance for completing the template; remove them before sharing externally.*
 >
 > *A Czech-language version of this document is maintained at [about-cqre-cs.md](about-cqre-cs.md).*
@@ -75,7 +81,7 @@ We are a small, specialist practice. We do not run a 24/7 SOC. We do not sign of
 **6. [PLACEHOLDER: Your sixth differentiator]**
-> **INTERNAL NOTE** — Add a differentiator specific to your practice. Examples: deep expertise in a specific vertical (OT/utilities, Czech regulatory environment); proprietary tools (ASTRAL, AOC, Elysium); language capability; specific certifications; methodology approach.
+> **INTERNAL NOTE** — Add a differentiator specific to your practice. Examples: deep expertise in a specific vertical (OT/utilities, Czech regulatory environment); proprietary tools (ASTRAL, PULSAR, Elysium); language capability; specific certifications; methodology approach.
 [PLACEHOLDER: specific differentiator with one concrete example or proof point]
@@ -1,242 +1,260 @@
 # AI Sovereignty Framework
-> *"The cloud model is smarter at everything, which makes it dumb at your specific thing."*
+> *"The question is not whether you use cloud AI. The question is whether you have the right to stop."*
 ## For the Executive Reader
-Your organization is currently engaged in a **massive, unpaid research project for cloud AI providers**. Every proprietary document, every strategic query, every operational workflow sent to a third-party AI becomes training data for models that will eventually be sold to your competitors.
+Most organisations treat AI as a utility — like electricity. But electricity suppliers cannot change your contract mid-production, cannot decide your use case violates their acceptable-use policy, and cannot be subpoenaed for the data you ran through them. Cloud AI providers can do all three.
-AI sovereignty is not an IT project. It is a **strategic asset protection mandate**. By running artificial intelligence on infrastructure you control, you:
+AI sovereignty is not a refusal to use cloud AI. It is a demand to **control your dependency on it** — to own the option to change direction, to retain audit rights over systems that touch your regulated data, and to maintain operational continuity when a vendor's priorities diverge from yours.
- **Stop funding your competitors** through proprietary data leakage
+By managing AI infrastructure with the same rigour you apply to any critical vendor relationship, you:
 - **Eliminate vendor lock-in** for your organization's cognitive infrastructure
 - **Reduce long-term costs** from unpredictable per-query pricing to fixed capital
 - **Demonstrate regulatory maturity** on data residency and third-party risk
-**The economic argument**: A mid-sized organization spending €5,000-€15,000 monthly on cloud AI APIs will break even on local infrastructure within 12-18 months. After break-even, the cost is a fraction of cloud pricing—and the data remains exclusively yours.
+- **Satisfy data residency requirements** increasingly mandated by NIS2, DORA, GDPR, and sector-specific regulators — without hoping the vendor's data processing addendum is legally sufficient
 - **Retain audit rights** over inference decisions that touch regulated data, sensitive operations, or customer information
 - **Protect operational continuity** from vendor pricing changes, API deprecations, acceptable-use updates, and geopolitical events outside your control
 - **Build intelligence that compounds** — a fine-tuned model trained on your data gets better at your specific workflows, not at everyone's generic tasks
-**The competitive argument**: A fine-tuned local model trained on your proprietary data will outperform a general cloud model on your specific workflows. The cloud model improves at everyone's tasks. Your local model improves at only your tasks. That is sustainable differentiation.
+**The economic argument**: At meaningful scale, cloud AI inference is priced to grow with your usage. Fixed-cost inference infrastructure — local models, private cloud, or auditable sovereign cloud — produces predictable economics. Organisations spending €5,000–€15,000 monthly on cloud AI APIs typically reach break-even within 12–18 months.
 **The competitive argument**: A model fine-tuned on your proprietary data outperforms a general cloud model on your specific workflows. The cloud model improves at everyone's tasks. Your local model improves at your tasks alone. That gap is sustainable differentiation the vendor cannot replicate without access to your data.
 *For board conversation scripts, see [C-Suite Conversation Guide](c-suite-conversation-guide.md).*
 *For financial justification, see [Business Case Template](../playbooks/business-case-template.md).*
 *For the distinction between optional business AI and inevitable operational AI, see [AI Operations Inevitability](ai-operations-inevitability.md).*
 ---
 ## For the Practitioner
-This framework provides the strategic, technical, and ethical arguments for treating artificial intelligence as **sovereign infrastructure** rather than rented utility. It is designed for consultants and architects who must persuade boards, CISOs, and engineering leaders to invest in locally controlled intelligence.
+This framework provides the strategic, technical, and regulatory arguments for treating artificial intelligence as **sovereign infrastructure** rather than a rented utility. It is designed for consultants and architects who must persuade boards, CISOs, and engineering leaders to invest in locally controlled or auditable intelligence — and who need arguments that survive pushback from technically literate audiences.
---
+> **Critical framing note**: Avoid leading with "your prompts are training competitors." Most enterprise AI agreements (Azure OpenAI, Google Workspace AI, Microsoft Copilot) explicitly prohibit training on customer data, and technically literate clients will push back immediately if you lead here. The stronger, more durable arguments are regulatory compliance, audit rights, and operational continuity. Start there. The "training data" counter-argument is documented below as a secondary concern where genuinely applicable.
 ## Executive Summary
 Most organizations are currently engaged in a **massive, unpaid R&D project for cloud AI providers**. Every proprietary prompt, every internal document fed into a third-party model, every workflow built on an external API is a transfer of intellectual capital to an entity whose interests are not aligned with the organization's survival.
 AI sovereignty reverses this extraction. It restores the boundary of trust. It converts intelligence from a rented commodity into an owned asset.
 ---
 ## The Five Strategic Arguments
-### 1. The Data Sovereignty Argument (The Trojan Horse)
+### 1. The Regulatory Compliance Argument (The Mandatory Case)
 **The Problem**
-When proprietary data is sent to cloud AI providers, it does not merely get "processed." It becomes part of a feedback loop that improves general models—models that will eventually be sold to competitors, used to commoditize the client's industry, or deployed to replicate the client's unique edge.
+EU regulatory frameworks have made data residency and audit rights over AI inference a legal requirement — not a preference — for a growing proportion of organisations.
-Every query is a lesson. Every document is a training sample. The client is not a customer; they are an **uncompensated research contributor**.
+- **NIS2 (Article 21)**: Essential and important entities must demonstrate control over ICT systems that process sensitive operational data. "We use Azure OpenAI and trust Microsoft's DPA" is increasingly insufficient as supervisory authorities in Germany, France, and the Netherlands begin active audits.
 - **DORA (Article 28–30)**: Financial entities must conduct ICT third-party risk assessments and maintain contractual controls over critical AI providers. AI used in ICT processes covered by DORA constitutes a critical ICT third-party service.
 - **GDPR Article 28**: Data processed by cloud AI on personal data requires a Data Processing Addendum that satisfies Article 28 requirements. Many organisations are running AI workflows over personal data with no DPA in place.
 - **GDPR Article 44–49**: Transfers of personal data to AI providers with servers outside the EEA require adequate safeguards. US-based AI providers fall under this constraint regardless of their European data centre commitments.
 - **Sector-specific**: Healthcare organisations (special category data under GDPR Article 9), financial entities (BaFin, ACPR, DNB supervision), and public sector bodies face additional layered requirements that generic cloud AI agreements frequently cannot satisfy without supplementary controls.
 **The Pitch**
-> *"By sending our internal data to the cloud, we are effectively training the very system that will eventually commoditize our industry and replace our proprietary edge. We are not just 'using' AI; we are contributing our secrets to the public model."*
+> *"Every AI workflow that processes personal data, strategic operational data, or regulated information is a data processing activity. The question is not whether we trust the provider — it is whether the processing arrangement is legally compliant and auditable. For regulated organisations, 'we assume they comply' is not an acceptable control."*
 **The Antifragile Move**
-Running local models creates a **closed intellectual loop**. The organization's data remains an asset, not a training set for a competitor. It creates a moat that cloud giants cannot cross because they never receive the raw material to replicate it.
+Sovereign or self-hosted AI eliminates the compliance gap entirely. The data never leaves the organisation's controlled environment. There is no sub-processor DPA to maintain, no cross-border transfer to justify, and no audit finding waiting to happen.
-**Key Points for the Room**
+Where full local deployment is not immediately feasible, the stepping-stone is **auditable sovereign cloud** — EU-hosted AI infrastructure with contractually guaranteed data isolation and documented audit rights. Azure OpenAI in EU regions with a complete Microsoft Data Processing Addendum is a defensible starting point; it is not the end state.
 - Cloud AI providers are incentivized to aggregate and generalize. You are incentivized to differentiate and protect.
 - What you consider proprietary operational data, they consider valuable training signal.
 - A local model trained on your data becomes *better* at your workflows over time. A cloud model becomes *better at everyone's workflows*, diluting your advantage.
 ---
-### 2. The Operational Resilience Argument (The "Pulling the Plug" Scenario)
+### 2. The Audit Rights Argument (The Control Gap)
 **The Problem**
-Cloud AI is a dependency with no service-level guarantee of continuity. Terms of service change. Pricing changes. API versions are deprecated. Geopolitical events disable access. "Safety" filters are updated to censor specific industries or use cases. The organization's core operations are, in effect, an application running on someone else's brain.
+An organisation using cloud AI cannot independently verify:
 - What data is retained after inference
 - Whether inference logs are accessible in an incident investigation
 - Whether model outputs are deterministic (same input, same output) across versions
 - What the model's reasoning was for a specific output — relevant when AI-assisted decisions are challenged by regulators or courts
 - Whether the model's behaviour has changed between versions in ways that affect your workflows
 These are not theoretical concerns. DORA explicitly requires that ICT systems be auditable. NIS2 requires that security measures be demonstrable. GDPR Article 22 restricts automated decision-making. A cloud AI black box fails each of these requirements in ways that a local or auditable model does not.
 **The Pitch**
-> *"What happens to our core operations if the cloud-AI provider changes its Terms of Service, raises prices by 1000%, or suffers a geopolitical blackout that disables their API? Our entire business model should not be an app running on someone else's brain."*
+> *"We cannot audit what we do not control. When an AI-assisted decision is questioned by a regulator, a court, or a customer, we need to be able to show our reasoning. A cloud model gives us an output. It does not give us an audit trail. A local model gives us both."*
 **The Antifragile Move**
 Local models are auditable by definition — you have the weights, the inference logs, and the version history. For workflows where regulatory auditability is a requirement, local inference is not an architectural preference; it is the only defensible choice.
 For lower-sensitivity workflows, open-weights models (Llama, Mistral, Qwen) deployed on controlled infrastructure provide a middle path: cloud AI capability with local audit rights.
 **Key Points for the Room**
 - Version-pinned local models produce deterministic outputs. Cloud models update silently, and the same prompt may produce different results across model versions.
 - Inference logs from a local model can be retained and searched. Inference logs from cloud AI are typically inaccessible — a gap that becomes critical in incident investigations.
 - Open-weights models can be independently evaluated for bias, backdoors, and capability claims. Closed-source cloud models cannot.
 ---
 ### 3. The Operational Continuity Argument (The "Pulling the Plug" Scenario)
 **The Problem**
 Cloud AI is a dependency with no contractual guarantee of continuity. Terms of service change. Pricing is restructured. API versions are deprecated. Acceptable-use policies are updated to restrict specific industries or use cases. Geopolitical events impose access restrictions. The organisation's critical workflows are, in effect, running on someone else's infrastructure — and someone else's judgment about what is and is not permitted.
 **The Pitch**
 > *"What happens to our core operations if the cloud AI provider changes its terms of service, raises prices by 500%, or suffers a geopolitical restriction that disables their API? Our operational continuity should not be an application running on someone else's brain."*
 **The Antifragile Move**
 Local models are **sovereign infrastructure**. They operate when:
 - The internet is degraded or unavailable
- The provider is down, acquired, or embargoed
+- The provider is down, acquired, subject to sanctions, or embargoed
- The "safety" filters have been updated to block your use case
+- Acceptable-use policy has been updated to restrict your use case
- Pricing has been restructured beyond recognition
+- Pricing has been restructured beyond budget tolerance
 - The vendor's strategic direction no longer aligns with your operational needs
-This is the ultimate insurance policy—not against data loss, but against **capability loss**.
+This is the operational resilience argument: not about data leakage, but about **capability continuity**.
 **Key Points for the Room**
- Vendor lock-in for compute is expensive. Vendor lock-in for *intelligence* is existential.
+- Vendor lock-in for compute is expensive. Vendor lock-in for *intelligence* — the reasoning layer your operations depend on — is potentially existential.
- Recovery from a cloud exit is measured in quarters if workflows are deeply integrated. Recovery from a local model is measured in minutes.
+- Recovery from a cloud AI exit is measured in quarters if workflows are deeply integrated. Migrating to a local model is measured in weeks.
 - Resilience is not about having a backup. It is about having no single point of failure in your cognitive pipeline.
 - The optionality cost is low. Maintaining the technical capability to run locally — even while using cloud AI today — preserves the exit option at minimal cost.
 ---
-### 3. The Intellectual Property Argument (The Asset Protection)
+### 4. The Intellectual Property Argument (The Asset Protection Case)
 **The Problem**
-When an organization uses cloud AI, it owns neither the weights, the architecture, nor the deterministic behaviour of the system. It cannot audit the reasoning. It cannot guarantee that the same prompt will produce the same result tomorrow. It cannot prevent its proprietary workflows from being absorbed into a general model.
+When an organisation uses cloud AI, it owns neither the weights, the architecture, nor the deterministic behaviour of the system. It cannot audit the reasoning. It cannot guarantee that the same prompt produces the same result tomorrow. It cannot version-control the model itself. Fine-tuned domain knowledge built through intensive proprietary workflow cannot be transferred out of the provider's environment.
 Additionally, in some cloud AI configurations — particularly where enterprise agreements are not in place or are misconfigured — prompt data *can* be used to improve models. This risk exists and should be assessed, even if it is not universal.
 **The Pitch**
-> *"When we run models locally, we own the weights, the architecture, and the outputs. We are not tenants of an intelligence; we are the owners of it. We can tune it for our specific tasks, not the generic tasks the cloud provider cares about."*
+> *"When we run models locally, we own the weights, the architecture, and the outputs. We are not tenants of an intelligence — we are the owners of it. We can fine-tune it for our specific tasks, version it, audit it, and legally defend it. None of that is possible with a cloud black box."*
 **The Antifragile Move**
-The organization moves from being a **consumer of AI** to a **manufacturer of its own intelligence**.
+The organisation moves from **consuming AI** to **manufacturing its own intelligence**.
 This is the difference between:
 - A farm that buys seeds every year and is subject to the seed catalog (cloud AI)
 - A farm that saves, selects, and breeds its own cultivars (sovereign AI)
- A farm that buys seeds every year (cloud AI)
+Over time, the sovereign farm develops capabilities perfectly adapted to its specific environment. The seed-buying farm is permanently dependent on external supply.
 - A farm that saves, selects, and breeds its own (sovereign AI)
 Over time, the sovereign farm develops cultivars perfectly adapted to its soil. The seed-buying farm is at the mercy of the seed catalog.
 **Key Points for the Room**
- Fine-tuned local models on proprietary data outperform general models on domain-specific tasks.
+- Fine-tuned local models trained on proprietary data outperform general models on domain-specific tasks. This is well-documented across legal, medical, financial, and operational domains.
- You can version, audit, and legally defend a local model. You cannot audit a cloud black box.
+- You can version, audit, and legally defend a local model. You can file for trade secret protection over its weights and training data. You cannot do any of this with a cloud model.
- The outputs of your local model are your intellectual property, unencumbered by third-party terms.
+- The outputs of your local model are your intellectual property, unencumbered by third-party terms of service that can change.
 ---
-### 4. Overcoming the Complexity Objection
+### 5. The Strategic Differentiation Argument (The Compounding Moat)
 **The Objection**
 > *"But the cloud models are smarter. And local deployment is complex."*
 **The Counter**
 Cloud models are smarter at *everything*, which makes them *dumb* at your specific thing. A general-purpose model optimized for broad benchmarks is not optimized for your internal processes, your data schemas, your regulatory constraints, or your proprietary logic.
 By training or fine-tuning a smaller, local model on specific, proprietary data, the organization can achieve:
 | Metric | Cloud General Model | Local Fine-Tuned Model |
 |--------|--------------------|------------------------|
 | Performance on generic tasks | 95% | 70% |
 | Performance on proprietary tasks | 60% | 90% |
 | Cost at scale | Linear / unpredictable | Sub-linear / fixed |
 | Data leakage risk | Non-zero and growing | Zero |
 | Operational ownership | None | Complete |
 **The Honest Reframe**
 > *"Most businesses do not need a model that can write Shakespeare. They need a model that knows their internal processes, their data, and their specific workflow. Local models are better at that—and they get better every day you feed them proprietary signal."*
 **Technical Reality**
 Modern quantized models, parameter-efficient fine-tuning (LoRA, QLoRA), and retrieval-augmented generation (RAG) have reduced the barrier to local deployment dramatically. A reasonable AI budget today can achieve what required a dedicated team two years ago.
 ---
 ### 5. The Professional Responsibility Angle
 **The Problem**
-As a security architect, consultant, or technical leader, you are the steward of the organization's crown jewels. Recommending that proprietary strategic intelligence be outsourced to an unauditable third-party black box is not a neutral technical decision. It is a **breach of fiduciary responsibility**.
+Cloud AI democratises baseline capability. Every competitor who subscribes to the same cloud AI service starts with the same baseline. The gap between organisations narrows as general AI capability becomes a commodity — and the only remaining differentiation is proprietary data and domain-specific fine-tuning.
 Organisations that feed their proprietary data into cloud AI rather than their own models are contributing the raw material of their future differentiation to a platform that commoditises it.
 **The Pitch**
-> *"I cannot in good faith recommend that we outsource our strategic intelligence to a third-party black box that we cannot audit and that is actively incentivized to commoditize our data."*
+> *"The cloud model is smarter at everything, which makes it dumb at your specific thing. A model fine-tuned on your data, your workflows, and your domain knowledge will outperform a general model on your actual tasks. And unlike the general model — which improves for everyone — this model improves only for you. That is a moat the vendor cannot replicate without your data."*
-**The Outcome**
+**The Antifragile Move**
-This framing elevates the advisor from a "technical implementer" to a **Strategic Defender of the Company's Future**. It positions the recommendation not as a preference for complexity, but as a principled stand for structural integrity.
+Treat proprietary AI capability as a **T0 strategic asset** — not because the technology is valuable in the abstract, but because the combination of your model, your data, and your domain knowledge produces capability that competitors cannot purchase.
-**Key Points for the Room**
+See the full [T0 Asset Framework](t0-asset-framework.md) for classification guidance.
 - You are not selling local AI. You are protecting the organization's ability to think independently.
 - The conflict of interest is real: cloud AI consultants are often incentivized by provider partnerships. Independent architects have no such conflict.
 - This is the same logic that demands on-premises key management for cryptography. Intelligence is no different.
 ---
-## The T0 Asset Classification
+## Handling Objections
-In cybersecurity and architecture, a **Tier 0 (T0) asset** is something that, if compromised, destroys the entire operation.
+The following objections are common from technically literate audiences. Superficial responses will not work. These are calibrated for audiences who have read the fine print.
-Local AI must be classified as T0. This framing speaks the language of high-stakes infrastructure and immediately elevates the conversation from "tech project" to **foundational pillar of survival**.
+| Objection | Honest Response |
-
+|-----------|----------------|
-### Why T0?
+| "Our enterprise agreement prohibits training on our data." | Most do. The issue is not current policy — it is audit rights over that commitment, the definition of what counts as "your data" vs. metadata, what happens when the agreement renews, and whether you can prove compliance to a regulator. Policy is not architecture. |
-
+| "We use Azure OpenAI, which is EU-hosted and GDPR-compliant." | A defensible starting point, not an end state. Verify your DPA covers all inference use cases. Confirm no data is routed outside the EU/EEA. For DORA-covered entities, complete the ICT third-party risk assessment. Azure OpenAI is the sovereignty bridge, not the destination. |
-1. **It defines the boundary of trust**: Moving intelligence inside the firewall re-establishes a perimeter that has been silently dissolving.
+| "Cloud models are more capable." | For generic tasks, yes. For your specific domain workflows, a fine-tuned local model — trained on your data — will match or exceed general model performance while keeping your data inside. The comparison is not "cloud vs. local on general benchmarks." It is "general model vs. fine-tuned model on your actual tasks." |
-2. **It removes vendor risk**: A local model is vendor-independent. It remains functional regardless of Silicon Valley boardroom decisions.
+| "Local deployment is too expensive." | Cloud AI pricing scales linearly with usage. Locally-run models (or private cloud inference) are a fixed-cost investment with predictable operating costs. Organisations with meaningful AI workloads typically reach break-even within 12–18 months. After break-even, the cost advantage compounds. |
-3. **It signals strategic maturity**: While competitors chase shiny APIs, the T0 advocate is building durable infrastructure for a 5-to-10-year horizon.
+| "We don't have the expertise." | Start with a pilot using modern tooling (Ollama, LM Studio, or a managed private cloud endpoint). The barrier has dropped dramatically. Partner for initial setup; own for ongoing operations. |
-
+| "This will slow us down." | Sovereignty is not a replacement for cloud AI. It is a capability you build alongside it. Start by identifying the 10% of workflows that touch regulated or proprietary data — sovereign those first. Continue using cloud AI for everything else while building toward full capability. |
-See the full [T0 Asset Framework](t0-asset-framework.md) for implementation guidance.
+| "We already have a SOC 2 / ISO 27001 certified vendor." | Certification covers the vendor's internal processes, not your specific data flows. It does not satisfy NIS2 Article 21, DORA Article 28–30, or GDPR Article 32 on its own. Ask your auditor directly whether your current AI processing arrangement would survive a supervisory authority inquiry. |
 ---
-## Implementation Posture
+## The Sovereignty Spectrum
-### Immediate (0-30 days)
+AI sovereignty is not binary. Organisations move along a spectrum from full cloud dependency to full local sovereignty. The appropriate position depends on the sensitivity of workflows, regulatory obligations, and operational risk tolerance.
- **Inventory**: Map all current AI usage—approved and shadow. Identify what data is leaving the perimeter.
+| Position | Description | Typical Use Case |
- **Classify**: Label workflows by sensitivity. Anything involving IP, strategy, or customer data is a sovereignty candidate.
+|----------|-------------|-----------------|
- **Pilot scope**: Select one non-critical, high-signal workflow for local model proof-of-concept.
+| **Cloud AI (unmanaged)** | No enterprise agreement, data processed with no residency guarantee | Consumer tools, non-regulated workflows |
 | **Cloud AI (enterprise)** | Enterprise agreement, data processing addendum, EU residency where required | Most corporate Microsoft 365 / Azure OpenAI usage today |
 | **Sovereign cloud AI** | Dedicated infrastructure, contractually guaranteed data isolation, full audit rights; e.g. Azure OpenAI with committed EU residency and complete DPA | Regulated organisations with EU data requirements |
 | **Self-hosted open-weights** | Open-weights models (Llama, Mistral, Qwen) on organisation-controlled infrastructure | High-sensitivity workflows; NIS2/DORA-regulated operations; organisations with strong data sovereignty requirements |
 | **Fine-tuned local** | Organisation-trained or fine-tuned model on proprietary data, fully isolated | Maximum differentiation; T0 intelligence workflows; trade secret protection |
-### Short-term (30-90 days)
+The CQRE practice does not mandate a specific position. We recommend mapping each AI workflow to its appropriate position on the spectrum based on the sensitivity of the data it processes and the regulatory obligations it creates.
- **Deploy local inference**: Establish on-premises or sovereign-cloud inference infrastructure.
+---
 - **Fine-tune**: Train a small model (7B-13B parameters) on proprietary data for the pilot workflow.
 - **Measure**: Compare accuracy, latency, cost, and leakage risk against the cloud baseline.
-### Medium-term (90-180 days)
+## Practical Starting Points
- **Expand**: Migrate additional workflows based on pilot results.
+### Immediate (0–30 days)
- **Integrate**: Connect local models to internal data pipelines, CMDB, and security tooling.
+
- **Govern**: Establish policies for approved AI usage, data handling, and model versioning.
+- **Inventory**: Map all current AI usage — approved and shadow. Identify what data is leaving the perimeter and under what contractual terms.
 - **Classify**: Label workflows by sensitivity and regulatory exposure. Anything involving personal data, strategic information, or regulated operations is a sovereignty candidate.
 - **Gap analysis**: For each AI workflow, assess: Is there a valid DPA? Is data residency confirmed? Do you have audit rights? Can you exit in 90 days if needed?
 ### Short-term (30–90 days)
 - **Harden existing cloud AI**: Ensure enterprise agreements and DPAs are in place for all cloud AI workflows. Confirm EU data residency where required. Document the ICT third-party risk assessment for DORA-covered entities.
 - **Sovereignty bridge**: For M365 environments, Azure OpenAI with committed EU data residency is the appropriate stepping-stone while local capability is built. See [Azure OpenAI Sovereignty Bridge](azure-openai-sovereignty-bridge.md).
 - **Pilot local inference**: Deploy Ollama or equivalent on controlled infrastructure for one high-sensitivity workflow. Measure performance, latency, and operational overhead.
 ### Medium-term (90–180 days)
 - **Expand local capability**: Migrate additional high-sensitivity workflows to local inference based on pilot results.
 - **Fine-tune**: Train or fine-tune a model on proprietary data for the workflows where domain performance matters most.
 - **Govern**: Establish a documented AI usage policy that maps each workflow to its approved processing tier and the controls required.
 ### Long-term (180+ days)
- **Manufacture**: Build internal capability to train, evaluate, and deploy domain-specific models.
+- **Manufacture**: Build internal capability to train, evaluate, and version domain-specific models.
- **Distribute**: Extend sovereign intelligence to edge locations, OT environments, and disconnected operations.
+- **Integrate**: Connect local models to internal data pipelines, security tooling, and operational systems.
- **Monetize**: Consider whether proprietary model capabilities represent a productizable asset.
+- **Productise**: Assess whether proprietary model capabilities represent a competitive asset worth protecting formally (trade secrets, access controls).
 ---
-## Common Objections and Responses
+## CQRE Tools as Sovereign Intelligence Examples
-| Objection | Response |
+The CQRE product suite is a working example of this framework applied to M365 operations:
-|-----------|----------|
+
-| "Cloud models are more capable." | For generic tasks, yes. For your proprietary tasks, a fine-tuned local model will outperform them—while keeping your data inside. |
+- **ASTRAL** runs on infrastructure you control (Azure DevOps, Git). M365 configuration state — the baseline of your tenant's security posture — never leaves your environment. The intelligence (what changed, what it means) is produced locally.
-| "Local deployment is too expensive." | Cloud AI pricing is linear with usage and unpredictable. Local is a fixed capital expense with predictable operating costs. At scale, it is cheaper. |
+- **PULSAR** retains M365 audit logs on your infrastructure (or CQRE-managed EU infrastructure for hosted deployments). The events that a cloud provider would let expire in 90 days are yours permanently, searchable, and not subject to any vendor's data retention policy.
-| "We don't have the expertise." | Start with a pilot. Modern tooling has reduced the expertise barrier dramatically. Partner for setup, own for operations. |
+- **AURORA** provides AI-assisted diagnostics over your ASTRAL and PULSAR data. Self-hosted AURORA brings its own Azure OpenAI endpoint (BYOAI) — your tenant data is processed by AI infrastructure under your control, not routed through a third-party service with opaque data handling.
-| "Our vendor says they don't train on our data." | Terms of service change. Verbal assurances are not architecture. If the data leaves your perimeter, you have lost control regardless of current policy. |
+
-| "This will slow us down." | A temporary reduction in velocity is preferable to a permanent loss of strategic optionality. Build the vault first; fill it quickly after. |
+This is the sovereignty spectrum in practice: open-source tools, client-controlled data, auditable AI integration, with a hosted tier for organisations that prefer managed infrastructure but require EU data residency.
 ---
 ## The Builder's Mandate
-By pushing for local AI infrastructure in the corporate world, you are **decentralizing the Machine**. You are taking the intelligence that centralized cloud platforms are trying to monopolize and distributing it to the edges—where human-scale organizations live and operate.
+By building sovereign AI capability in the organisations you advise, you are **decentralising intelligence**. You are taking the cognitive infrastructure that centralised cloud platforms are trying to monopolise and returning it to the organisations that generate the underlying data.
-You are building the infrastructure that allows businesses to remain **sovereign entities** rather than terminal sinks for centralized AI extraction.
+This is not anti-cloud ideology. It is a straightforward application of the antifragile principle: **own your critical dependencies, and maintain the option to change everything else**.
-This is the most responsible architecture work possible right now.
+The organisations that build this capability today will retain independent judgment when vendor relationships change. The organisations that don't will discover — too late — that their cognitive infrastructure belongs to someone else.
 ---
 *Next: [T0 Asset Framework](t0-asset-framework.md)*
 *Previous: [Antifragile Manifest](antifragile-manifest.md)*
 *Related: [Azure OpenAI Sovereignty Bridge](azure-openai-sovereignty-bridge.md)*
 *Related: [AI Operations Inevitability](ai-operations-inevitability.md)*
 *Related: [CQRE Product Suite](../playbooks/cqre-product-suite.md)*
@@ -25,6 +25,8 @@ This manifest defines the five foundational pillars of an antifragile enterprise
 Your job as a consultant is to translate each pillar into the specific context of the client. The language should shift (a CISO hears "Stress-to-Signal Conversion" differently than a CFO does), but the underlying logic does not.
 **On sequencing**: The pillars are not equally weighted at the start of an engagement. Pillars 1 and 2 (Structural Decoupling and Optionality Preservation) are foundation work — mapping and removing dangerous dependencies. Pillar 3 (Stress-to-Signal Conversion) requires having something to instrument. Pillar 4 (Sovereign Intelligence) presupposes a foundation worth protecting and a signal worth amplifying. A client excited about AI sovereignty who has not enforced MFA is building a sophisticated roof on a house with no walls. Fix the foundation first. See [Move Fast and Fix Things — The AI Distraction](move-fast-and-fix-things.md#the-ai-distraction).
 For the reasoning *why* these pillars work—drawn from natural systems, distributed networks, and emergent order—see [Spontaneous Order Principles](spontaneous-order-principles.md).
 ---
@@ -45,6 +47,7 @@ Cloud architectures have created an illusion of resilience through scale. In rea
 - **Design graceful degradation**: Every critical function must have a fallback mode that operates at reduced capacity without the external dependency.
 - **Practice controlled failure**: Introduce chaos into non-production environments. If a system cannot survive the simulated failure of a dependency, it will not survive the real one.
 - **Establish exit architectures**: For every major platform dependency, maintain a technical and procedural path to migration that can be executed within 90 days.
 - **Build greenfield capability**: The ultimate expression of structural decoupling is the ability to rebuild the entire environment from scratch — cleanly, from documentation and version-controlled configuration, without inheriting the compromised state. An organisation that can execute a planned greenfield deployment every five years or so is in a structurally different risk position than one for which greenfield is a nightmare scenario. This is the controlled burn: organisations that never rebuild accumulate the technical debt and undocumented dependencies that make eventual failure catastrophic. See [Move Fast and Fix Things — Rule 5](move-fast-and-fix-things.md#rule-5-build-toward-greenfield-capability).
 ### Executive Framing
@@ -118,9 +121,11 @@ An organization that outsources its cognition outsources its future. Sovereign i
 ### The Argument
-The current AI paradigm is extractive. Every prompt sent to a cloud AI is a contribution to a competitor's training set. Every workflow built on a third-party model is a dependency on an intelligence you do not control, cannot audit, and cannot guarantee will serve your interests tomorrow. This is not a privacy concern. It is a **survival concern**.
+The current AI paradigm introduces three underappreciated risks. First, **vendor dependency**: every workflow built on a third-party model is a dependency on an intelligence you do not control, cannot fully audit, and cannot guarantee will serve your interests when the vendor's incentives shift. Second, **data residency and audit rights**: even where enterprise agreements prohibit training on your data, you typically cannot verify this independently — and audit rights over model inference are absent from most SLAs. Third, **operational continuity**: cloud AI services can change pricing, degrade quality, or enforce new acceptable-use restrictions at will. Your workflows break on their schedule, not yours.
-Sovereign intelligence is the antifragile response: local models, proprietary data loops, and owned reasoning infrastructure that improves with use rather than leaking value to external platforms.
+Sovereign intelligence is the antifragile response: owned or auditable models, proprietary data loops, and reasoning infrastructure that improves with use rather than creating dependency. This does not require rejecting all cloud AI. It means treating AI infrastructure with the same dependency analysis you would apply to any critical vendor: map it, stress-test the exit, and ensure you retain options.
 > **Consultant note**: The strongest client argument is not "your prompts are training competitors" — most enterprise agreements explicitly prohibit this, and technically literate clients will push back. The more durable arguments are data residency requirements (NIS2, DORA, GDPR Article 32), audit rights over inference decisions, and operational continuity risk when a critical workflow depends on an endpoint you cannot control. Start there.
 ### Antifragile Moves
@@ -10,7 +10,7 @@ It is designed for M365/Azure consultancies whose clients are not ready for on-p
 ## The Executive Summary
-Your clients are likely using ChatGPT, Claude, or Gemini via public APIs and consumer accounts. Every prompt leaves their perimeter, and the terms of service allow model improvement using that data. This is the worst possible posture.
+Your clients are likely using ChatGPT, Claude, or Gemini via consumer accounts or unmanaged public APIs — where data residency is uncontrolled, audit rights are absent, and (for consumer tiers) terms of service may permit model improvement using submitted data. This is the worst possible posture.
 **Azure OpenAI Service is not fully sovereign.** Microsoft operates the infrastructure. The underlying models are shared. But it offers something critical that public APIs do not:
@@ -204,7 +204,7 @@ For E3 clients, Azure OpenAI is a **separate Azure subscription**—it does not
 |---------|----------|
 | "Is this just another Microsoft lock-in?" | "It reduces lock-in compared to public APIs because your fine-tuned models, embeddings, and RAG pipelines are portable assets. When you are ready for full local AI, you migrate them. We are using Azure as a warehouse, not a prison." |
 | "Why not go straight to local AI?" | "Local AI requires hardware procurement, infrastructure setup, and expertise development—typically 3-6 months. Azure OpenAI stops the data leakage in 2 weeks while we build the local capability in parallel." |
-| "How is this different from just using ChatGPT?" | "ChatGPT trains on your data. Azure OpenAI explicitly does not. ChatGPT has no audit trail. Azure OpenAI logs every prompt. ChatGPT offers no data residency guarantee. Azure OpenAI keeps your data in your region. The difference is governance, not capability." |
+| "How is this different from just using ChatGPT?" | "Consumer ChatGPT may use your data for model improvement; Azure OpenAI explicitly does not. Consumer ChatGPT has no audit trail; Azure OpenAI logs every prompt. Consumer ChatGPT offers no data residency guarantee; Azure OpenAI keeps your data in your chosen region. The difference is governance and compliance, not capability." |
 | "What if Microsoft changes the terms?" | "The data processing agreement is contractually binding. More importantly, the assets we build in Foundry are portable. If terms change unfavorably, we exercise the exit option we have been building toward all along." |
 | "Will this slow down our AI adoption?" | "It will accelerate safe adoption. Employees currently use unauthorized AI because there is no sanctioned alternative. Azure OpenAI gives them a better, safer tool. Adoption goes up; risk goes down." |
@@ -121,7 +121,7 @@ Many organizations have purchased or inherited an impressive security stack:
 **Deliverable**: Operating Rhythm Playbook
-**Tool stack for the operating rhythm**: See the [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md) for the complete open-source SOC architecture. For M365-centric environments, AOC provides audit log intelligence; Wazuh + Sysmon provide endpoint detection; TheHive + Cortex provide case management; Shuffle provides automated response. This stack replaces €200K+/year commercial SOC tooling for clients who prioritise sovereignty.
+**Tool stack for the operating rhythm**: See the [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md) for the complete open-source SOC architecture. For M365-centric environments, PULSAR provides audit log intelligence; Wazuh + Sysmon provide endpoint detection; TheHive + Cortex provide case management; Shuffle provides automated response. This stack replaces €200K+/year commercial SOC tooling for clients who prioritise sovereignty.
 - Weekly, bi-weekly, and monthly cadence definitions
 - RACI matrix for each activity
 - Dashboard definitions and data sources
@@ -245,6 +245,24 @@ Week 1 produces the baseline. It does not produce improvements. Clients sometime
 ---
 **11. Validating the AI Distraction**
 A client opens with: *"We want to implement AI-powered threat detection"* or *"Can AI help us manage our security posture?"* The mistake is engaging with the AI question directly — evaluating vendors, discussing models, building a roadmap — before establishing whether the foundation exists.
 AI security tools are multipliers. A multiplier applied to a broken foundation produces nothing except an expensive invoice and a false sense of coverage. The client who wants AI detection but has no MFA on admin accounts, no tested backups, and unpatched internet-facing systems does not need AI detection. They need MFA.
 **The redirect script**:
 > *"I want to get you to the AI layer — that's where the interesting work is. The fastest path there is closing the gaps that AI can't compensate for first. Otherwise, we're tuning the detection system while the front door is unlocked. Let's run the Brownhat Diagnostic, find your kill chain, close the existential gaps, and then we build the intelligence layer on top of something solid. You'll actually get value from the AI at that point."*
 **When to apply this**: Any time a client's opening request is for an intelligence or detection capability before you have confirmed that basic hygiene is in place. The discovery call question that surfaces it: *"What's your current MFA coverage across admin accounts?"* If the answer is anything other than "100%, enforced by policy," you have a layer-one gap. Fix that before any AI conversation.
 **The one exception**: A client with demonstrably strong fundamentals — IG1 complete, MFA enforced, logging in place, backups tested — who wants to build on that foundation. This is a legitimate AI conversation. But verify the foundation before accepting the premise that it exists.
 See [Move Fast and Fix Things — The AI Distraction](move-fast-and-fix-things.md#the-ai-distraction) for the full philosophical statement.
 ---
 ## Part 5: Technical Onboarding
 ### CQRE tool repositories
@@ -253,8 +271,8 @@ Before leading a module, you need to be able to deploy and use the tools that mo
 | Tool | Repository | Used in |
 |------|-----------|---------|
-| **ASTRAL** | `cqrenet/astral` (public) · `cqrenet/Intune` (internal, full version) | Modules 1, 2, 3 |
+| **ASTRAL** | [github.com/cqrenet/astral](https://github.com/cqrenet/astral) | Modules 1, 2, 3 |
-| **AOC** | `cqrenet/aoc` | Modules 2, 3, 12; retained capability |
+| **PULSAR** | [github.com/cqrenet/pulsar](https://github.com/cqrenet/pulsar) | Modules 2, 3, 12; retained capability |
 | **macOS_IntuneManagement** | `cqrenet/macOS_IntuneManagement` | Module 1; tenant migrations |
 | **Elysium** | `cqrenet/elysium` | Module 6, 10 |
 | **CAExporter** | `vibecoding/CAExporter` | Modules 2, 3 |
@@ -271,7 +289,7 @@ This is the minimum bar for leading (not shadowing) a module. If you are not the
 | Module | Minimum competency |
 |--------|-------------------|
 | **Module 1** (Endpoint) | PowerShell 7+; Intune policy structure; ASTRAL deployment and configuration; E8-CAT scoring |
-| **Module 2** (Identity) | Entra ID architecture; Conditional Access design; PIM/PAM concepts; AOC deployment; CAExporter export and analysis |
+| **Module 2** (Identity) | Entra ID architecture; Conditional Access design; PIM/PAM concepts; PULSAR deployment; CAExporter export and analysis |
 | **Module 3** (M365 Hardening) | Modules 1 and 2 competency; Prowler Azure audit; ASTRAL drift detection; ASR rules |
 | **Module 6** (AD Hardening) | Active Directory architecture; BloodHound collection and analysis; DSInternals and Elysium operation; LAPS deployment; GPO design; Sysmon configuration |
 | **Module 8** (OT Security) | OT/IT network segmentation concepts; NIS2 Article 21 and 23 requirements; SCADA/ICS risk framing; Zeek or Suricata basics |
@@ -283,7 +301,7 @@ This is the minimum bar for leading (not shadowing) a module. If you are not the
 Before your first client engagement, build a personal lab that lets you safely test deployments:
- **M365 developer tenant** — Microsoft's free developer programme provides an E5 tenant. Use it for ASTRAL, AOC, CAExporter, and M365 module testing. Register via the Microsoft 365 Developer Programme.
+- **M365 developer tenant** — Microsoft's free developer programme provides an E5 tenant. Use it for ASTRAL, PULSAR, CAExporter, and M365 module testing. Register via the Microsoft 365 Developer Programme.
 - **A small Linux VM (any cloud)** — For chatmail relay, Wazuh, TheHive, and Shuffle deployments. A €5–10/month VPS is sufficient for personal lab use.
 - **A Windows Server VM** — For AD module testing: BloodHound, Elysium, LAPS, Sysmon. Can be local (Hyper-V, VMware) or cloud.
 - **A CQRE internal environment** — Ask for access to the shared lab environment used for tool testing and client demos.
@@ -166,7 +166,7 @@ Some clients want ongoing support rather than discrete projects. Three models:
 | Type | Description | Typical cadence |
 |------|-------------|----------------|
 | **Retained advisory** | A fixed number of hours per month for questions, threat model reviews, architecture reviews, and strategic guidance. No new module delivery — advisory only. | Monthly retainer, 8–16 hours/month |
-| **Retained capability support** | Active support operating tools we deployed: reviewing ASTRAL alerts, tuning AOC detection rules, running quarterly AD scans with Elysium and PingCastle, reviewing Huntress findings. | Monthly or quarterly, scoped per tool set |
+| **Retained capability support** | Active support operating tools we deployed: reviewing ASTRAL alerts, tuning PULSAR detection rules, running quarterly AD scans with Elysium and PingCastle, reviewing Huntress findings. | Monthly or quarterly, scoped per tool set |
 | **Module continuation** | Ongoing delivery of a multi-module programme at a structured cadence. Each module planned and scoped before it begins. | Quarterly module delivery |
 Retained relationships are renewed quarterly. Either side can exit with 30 days' notice.
@@ -6,13 +6,13 @@
 ## The Problem in One Sentence
-Your organization is currently engaged in a **massive, unpaid research project for its competitors**—sending proprietary data, strategic reasoning, and operational intelligence to cloud platforms that are incentivized to commoditize your industry.
+Your organization depends on technology infrastructure it does not fully control — cloud platforms whose incentives are not aligned with your survival, AI tools processing your operational intelligence under agreements you cannot audit, and vendors whose pricing, terms, and continued existence are outside your influence.
 ## What Is at Stake
 | Asset Category | Current Risk | If Compromised or Extracted |
 |---------------|-------------|----------------------------|
-| Strategic intelligence | Rented from cloud AI providers | Competitors replicate your edge; your strategy becomes public model training data |
+| Strategic intelligence | Rented from cloud AI providers | Vendor dependency, data residency risk, no audit rights over inference — and a strategy that improves their platform, not yours |
 | Customer trust | Protected by compliance theater | Regulatory fines, class-action liability, irreversible reputational damage |
 | Operational continuity | Dependent on vendor stability | Single API change or geopolitical event halts revenue-critical workflows |
 | Technical talent | Wasted on maintenance of fragile systems | Burnout, attrition, inability to attract security-conscious engineers |
@@ -34,16 +34,24 @@ An antifragile organization does not merely survive shocks. It **grows stronger
 ## The Strategic Mandate: AI Sovereignty
-The current AI paradigm is **extractive**. Every prompt sent to a cloud AI teaches that system how to replace you. By running artificial intelligence on infrastructure you control, you:
+Cloud AI introduces three risks that most organisations have not priced. **Vendor dependency**: your critical workflows run on an endpoint you cannot audit, cannot predict, and cannot replace overnight. **Data residency and audit rights**: even where enterprise agreements prohibit training on your data, you typically cannot verify this, and regulators increasingly want proof — not assurances. **Operational continuity**: cloud AI services change pricing, restrict acceptable use, and degrade quality on the vendor's timeline, not yours.
- **Protect your intellectual property** from becoming public training data
+By running intelligence on infrastructure you control, you:
 - **Retain audit rights** over every inference decision — increasingly required by GDPR, NIS2, and DORA auditors
 - **Ensure operational continuity** regardless of vendor decisions, geopolitics, or API changes
 - **Eliminate data residency risk** — EU customers in particular face regulatory requirements that cloud AI processing often cannot satisfy
 - **Reduce long-term costs** from unpredictable per-token pricing to fixed infrastructure
 - **Demonstrate regulatory maturity** to auditors who increasingly scrutinize data residency and third-party risk
 > *"If our company's intelligence were a physical pile of cash, would we store it in a public bank that takes a 'training fee' off every dollar and reserves the right to change the currency? Or would we keep it in our own vault?"*
-Local AI is the vault.
+Local AI — or auditable AI with clear data residency — is the vault.
 ## The Regulatory Context
 For organisations operating in the EU, the compliance case is now as compelling as the security case. **NIS2** (in force October 2024) requires essential and important entities to demonstrate configuration management, logging, and incident detection. **DORA** (applying to financial entities from January 2025) mandates ICT change management records and audit log retention. **GDPR Article 32** requires appropriate technical measures that are increasingly interpreted as continuous, evidenced controls — not annual point-in-time reviews.
 Every engagement we deliver produces evidence that maps directly to these requirements. This is not coincidence — it is by design.
 ## The 180-Day Commitment
@@ -61,7 +69,7 @@ We do not propose a three-year transformation. We propose **four phases, 180 day
 This is not a cost centre. It is **optionality insurance**.
 - **Cost of the program**: Primarily configuration and process—existing tools are leveraged first.
- **Cost of inaction**: A single ransomware incident averages €4.5M in recovery. A single regulatory fine under DORA can reach 2% of global turnover. A single competitor trained on your data renders your proprietary advantage worthless.
+- **Cost of inaction**: A single ransomware incident averages €4.5M in recovery. A single regulatory fine under DORA can reach 2% of global turnover. A single uncontrolled AI vendor relationship can expose your operational data to residency and audit failures that NIS2, DORA, or sector regulators will not overlook.
 - **ROI timeline**: Risk reduction is visible in 30 days. Regulatory evidence is demonstrable in 90 days. Competitive advantage from sovereign intelligence compounds over 12-24 months.
 ## The Decision Required
@@ -73,7 +73,7 @@ We do not sell monolithic transformation projects. We sell **building blocks** t
 - Legacy authentication blocked tenant-wide
 - Privileged access workstation (PAW) architecture for admins
 - PIM deployment (if E5/Entra ID P2) or manual JIT process (if E3)
- AOC deployment for audit log intelligence and anomalous admin detection
+- PULSAR deployment for audit log intelligence and anomalous admin detection
 - Guest access audit and time-bounding
 - OAuth consent governance
@@ -168,7 +168,7 @@ We do not sell monolithic transformation projects. We sell **building blocks** t
 **Executive pitch**:
-> *"Your teams are already using AI—through personal accounts, browser tabs, and mobile apps. Every proprietary document they paste into ChatGPT trains a model that will eventually be sold to your competitors. We stop that leakage in two weeks by giving them a better, safer alternative. Then we build your first custom AI asset on data that never leaves your Azure region."*
+> *"Your teams are already using AI—through personal accounts, browser tabs, and mobile apps. Every proprietary document they send to an unmanaged AI service is processed under terms you haven't reviewed, on infrastructure outside your control, with no data residency guarantees. We stop that leakage in two weeks by giving them a better, safer alternative. Then we build your first custom AI asset on data that never leaves your Azure region."*
 **Natural next modules**: Module 9 (Organizational Resilience), Module 4 (Data Governance), Module 10 (Red Team & Validation)
@@ -31,7 +31,9 @@ The Brownhat Diagnostic — a structured [NIST CSF 2.0 baseline assessment](../a
 ### Speed Is a Security Control
-The organizations that survive are not the ones with the most comprehensive plans. They are the ones that **execute fastest** against the gaps that actually matter. A 90% solution deployed today outperforms a 100% solution that ships in six months—because the attacker does not wait for your roadmap.
+The organizations that survive are not the ones with the most comprehensive plans. They are the ones that **execute fastest** against the gaps that actually matter. A realistic engagement delivers 30–60% of an ideal posture in 180 days. That is the honest target. It is also, in almost every case, an enormous improvement over what existed before — and infinitely better than the 100% solution that stays in planning and never ships.
 The correct comparison is not "30% today vs. 100% in six months." It is "30% today vs. the 0% that will still be there in two years if you wait for the perfect plan." Momentum beats completeness. Imperfect progress beats perfect paralysis.
 ### Fixing Things Is Strategic
@@ -47,7 +49,7 @@ The antifragile consultant's first duty is not to recommend new spending. It is
 ---
-## The Three Rules
+## The Five Rules
 ### Rule 1: Start With What You Own
@@ -85,17 +87,81 @@ A fix that does not generate intelligence is a fix that will rot. Every remediat
 | "We rotated the password." | "We rotated the password and vaulted it in the PAM with checkout logging." |
 | "We fixed the firewall rule." | "We fixed the firewall rule and added a monthly rule review to the change process." |
 ### Rule 4: Run Housekeeping as a Permanent Stream
 This is the rule most often acknowledged and least often followed. In every engagement, cleanup is identified as necessary. In almost no engagement is it ever finished. Stale accounts accumulate. Orphaned permissions persist. Old devices stay enrolled. Legacy protocols remain enabled because removing them requires a change window that never gets scheduled.
 The correct response is not to add cleanup to the project backlog. It is to **establish housekeeping as a dedicated, permanently resourced stream with its own queue, its own cadence, and its own accountability**.
 Housekeeping is not janitorial work. It is attack surface reduction at a structural level. Every stale account is a credential that can be compromised without detection. Every orphaned permission is a privilege escalation path that BloodHound will find. Every legacy protocol still enabled is an authentication downgrade waiting to happen. The environment accumulates new objects continuously — every employee, every project, every vendor relationship adds accounts, permissions, and configurations. Almost nothing removes them automatically. Without a permanent housekeeping stream, the attack surface grows without bound regardless of what else you fix.
 **What housekeeping covers:**
 - Stale user accounts: departed employees, contractors, service accounts with no owner
 - Orphaned group memberships and permissions that outlasted the project that created them
 - Old app registrations and service principals — often the most overlooked and most dangerous
 - Enrolled devices that are no longer in use
 - Conditional Access policies with no named owner and no documented purpose
 - Legacy protocols: NTLM, basic authentication, SMBv1, NTLMv1 — things that should have been disabled years ago
 - DNS records for decommissioned services
 - Firewall rules added for temporary access that became permanent
 - Old GPOs, old admin rights, old certificates
 **The engagement implication**: Every module scoping conversation must include a housekeeping component. It is not optional and not deferrable. The client names a resource, a cadence (minimum monthly), and a queue. The queue is populated from module findings and from continuous discovery. Progress is tracked and reviewed at every steering committee. If there is no resourcing for housekeeping, the engagement model must reflect that — because every fix we make will be partially undone within 18 months by new accumulation if the stream does not exist.
 ---
 ### Rule 5: Build Toward Greenfield Capability
 The cheapest and fastest recovery from a serious breach is often a greenfield deployment — rebuilding the environment from scratch on clean infrastructure rather than remediating a compromised one. Most organisations treat this as a nightmare scenario. The goal is to treat it as a **standard operational capability exercised every five years or so** — not something that wakes you up at night, but something you have done before and know how to do again.
 This is the ultimate defender's power move. An attacker's leverage in a breach depends largely on your inability to walk away from the compromised environment. If you can build the parallel company and burn the old one, that leverage disappears. Ransomware becomes an inconvenience rather than an existential event. The threat model changes fundamentally.
 **What greenfield capability requires:**
 - **Everything documented as code**: infrastructure configuration, security baselines, identity architecture, network topology. If you cannot rebuild it from documentation in a clean environment, you do not own it — you are renting it from accumulated history.
 - **Configuration under version control**: M365 policy state in ASTRAL, infrastructure definitions in IaC, runbooks in a repository. The new environment can be provisioned from the same source of truth.
 - **Clean data separation**: you know where your data is, what form it is in, and how to migrate it. Data that cannot be migrated cleanly is a dependency you have not acknowledged.
 - **Tested migration procedures**: the greenfield capability is not real until it has been exercised. Partial migrations, parallel-environment tests, and recovery drills build the muscle. Each module completion should leave the client one step closer to a documented, tested rebuild path.
 - **Vendor independence at critical layers**: you cannot rebuild greenfield if the new environment depends on the same compromised vendor. Optionality (Pillar 2) is the prerequisite.
 **The cadence target**: An organisation that can execute a planned greenfield migration in 90 days — with data integrity, minimal service disruption, and full security posture — is in a structurally different risk position than one for which greenfield is theoretical. This is not a one-time project. It is a capability you build, test, and maintain.
 **The controlled burn**: forests that are never burned accumulate the fuel for catastrophic fires. Organisations that are never greenfield-deployed accumulate technical debt, legacy dependencies, and accumulated compromise that makes eventual failure more severe. Planned greenfield on a 5-year cycle is the controlled burn that prevents the uncontrolled one.
 ### The Critical Infrastructure Adaptation
 For organisations operating OT/NT environments — power generation, transmission, water utilities, telecoms network infrastructure — a full greenfield rebuild is often genuinely not possible. Protection relays run for 30 years. PLCs controlling turbines cannot be taken offline for a rebuild exercise. Safety systems require regulatory approval for any change. The controlled burn, taken literally, cannot be applied.
 The goal remains the same. The method changes.
 **The purpose of greenfield capability is to eliminate inherited compromise and return to a known-good operational state.** In OT environments, this is achieved through a different set of moves — but the test is identical: *"If our control systems were completely compromised and had to be restored, could we maintain critical service delivery and return to full automated operation from a verified baseline?"*
 **IT layer greenfield protects the OT layer.** The corporate IT environment, SCADA servers, historian, HMI workstations, and M365 tenant can almost always be made greenfield-capable even when the OT hardware cannot. When the IT layer can be rebuilt clean, an adversary who compromised it loses their persistence and pivot path without a single OT system being touched. IT greenfield is the outer defence of an OT environment that cannot be rebuilt itself.
 **Configuration as code for OT.** PLC logic, IED settings, protection relay configurations, SCADA databases, and DCS configurations belong in version control. The ability to restore a verified configuration to existing hardware is the OT equivalent of greenfield: the hardware stays, but the software state is erased and rebuilt from a known-good baseline. Configuration backup and integrity checking for OT systems is not optional — it is the closest available substitute for the rebuild capability that IT environments take for granted. ASTRAL for M365 is the pattern; the same discipline applied to OT configuration archives is the OT equivalent.
 **Manual operation capability is a form of "drop the compromised layer."** A power utility that can maintain 80% of service from manual procedures during a SCADA compromise has a fundamentally different risk profile than one that cannot. The ability to operate without the automation layer is, in effect, the ability to sacrifice the compromised layer and continue. Manual override procedures, validated quarterly, are the OT sector's equivalent of a tested greenfield playbook. If operators have not practised running manually in the past 12 months, the capability does not exist.
 **Compartmentalisation over total rebuild.** OT environments are often sectionable. Grid islanding, corridor isolation, plant-level segmentation, and control centre failover allow the operator to sacrifice a section while maintaining critical service elsewhere. The burn is localised rather than total — but the principle is the same: designed-in ability to contain, recover, and restore in sequence rather than all at once.
 **Long-cycle planned refresh.** OT systems have 20–40 year lifetimes, but those lifetimes should be planned, not accidental. A utility with a documented 20-year OT refresh programme — component-by-component replacement milestones, firmware escrow, spare parts inventory — is doing the OT equivalent of periodic greenfield: the environment is continuously re-established in controlled segments. Organisations that do not have this programme are not avoiding greenfield; they are deferring it until a crisis forces it under the worst possible conditions.
 **What the test looks like for OT**: *"If our SCADA and IT layers were fully compromised tonight, could we maintain critical service from manual procedures within 4 hours, rebuild the IT layer from clean baselines within 48 hours, and restore full automated operation from verified OT configuration backups within two weeks?"* If any of those answers is no, the gap is in manual procedures, IT rebuild capability, or OT configuration management — not in greenfield per se, but in the prerequisites that make any form of recovery possible.
 For the full OT/critical infrastructure treatment, see [Vertical: Power and Utilities](../reference/vertical-power-utilities.md).
 ---
 ## Mapping to Antifragile Pillars
 | Antifragile Pillar | Move Fast and Fix Things Expression |
 |-------------------|-------------------------------------|
-| **Structural Decoupling** | Identify and eliminate hidden dependencies before they become fatal. Do not add new platforms to solve problems that abstraction can solve. |
+| **Structural Decoupling** | Identify and eliminate hidden dependencies before they become fatal. Greenfield capability is the ultimate expression: if you can rebuild cleanly, no single vendor or compromise holds you hostage. |
-| **Optionality Preservation** | Maximize existing investments to preserve budget for strategic optionality. Every unnecessary purchase reduces your ability to pivot. |
+| **Optionality Preservation** | Maximize existing investments to preserve budget for strategic optionality. Greenfield deployment requires vendor independence at every critical layer — build and maintain that independence now. |
 | **Stress-to-Signal Conversion** | Every fix must generate telemetry. Incidents are not failures; they are unpaid penetration tests. Convert their lessons into structure. |
-| **Sovereign Intelligence** | Use what you own first. Local AI on existing hardware beats cloud AI on a credit card. Your data should improve your models, not someone else's. |
+| **Sovereign Intelligence** | Use what you own first. Your data, your configurations, your runbooks — all under version control, all portable, all yours. Housekeeping keeps it clean. Greenfield capability proves it. |
-| **Asymmetric Payoff Design** | Small, fast fixes on the kill chain yield disproportionate risk reduction. Do not distribute effort evenly; concentrate it where failure is existential. |
+| **Asymmetric Payoff Design** | Small, fast fixes on the kill chain yield disproportionate risk reduction. Housekeeping and greenfield capability are the highest-leverage long-term investments: small ongoing cost, enormous reduction in catastrophic risk. |
 ---
@@ -151,6 +217,102 @@ When you walk into a client environment, bring these assumptions:
 ---
 ## The AI Distraction
 There is a recurring pattern in security consulting: a client opens with "we want AI-powered threat detection" or "can AI help us with our security posture?" and the instinct — especially from vendors — is to say yes and start selling.
 The correct response is to ask: *"Do your domain admins have MFA enforced?"*
 We call this pattern the **AI Mythos**: the belief that intelligence-layer tooling is the primary answer to security problems. It is not. AI is a multiplier. A multiplier applied to an absent foundation produces nothing. An AI-powered SOC that generates alerts from a network with no MFA, no patching cadence, and no tested backups is generating expensive noise about a patient who already has a terminal condition.
 ### The Multiplier Principle
 Security capabilities stack in layers. Each layer requires the layer below it to function.
 ```
 Foundation   → Identity hygiene, endpoint coverage, patching, tested backups, basic logging
 Signal       → Logging turned on, SIEM ingesting the right sources, alerts with owners
 Intelligence → Detection engineering, threat hunting, AI-assisted analysis
 ```
 AI lives at layer three. Organisations that have not completed layer one do not benefit from layer three — they buy something that has nothing to amplify.
 **The test**: Ask "what would have stopped this breach?" For the overwhelming majority of incidents — credential theft, ransomware, insider threat, misconfiguration exploitation — the answer is a layer-one control: MFA, patched systems, least-privilege accounts, a working backup. Not AI detection. Not an AI SOC. Not AI-powered SIEM correlation.
 The CIS Controls make this explicit. IG1 — 56 safeguards covering basic inventory, secure configuration, data protection, account management, patching, and backup — is the minimum viable security posture. Every organisation should complete IG1 before spending money on anything above it. AI-powered security tools are not IG1 controls. They are IG3 multipliers applied to an IG1 foundation.
 ### What to Do When a Client Leads with AI
 The client who opens with AI is not wrong to want it. They are wrong about sequencing. Your job is to redirect without dismissing.
 **The redirect**:
 > *"AI security tools are most valuable when you have a strong signal to amplify. The fastest path to benefiting from AI is making sure the basics are right first — because AI on a broken foundation is just expensive noise. Let's start with the Brownhat Diagnostic, find your kill chain, and close the gaps that AI can't compensate for. Then you'll actually get value from the AI layer on top."*
 This reframes AI as a reward for good hygiene, not a substitute for it. It respects the client's interest in AI while directing the budget where it produces real risk reduction.
 ### The Sequencing Rule
 The antifragile pillars are not equally weighted at the start of an engagement. They are sequenced:
 1. **Structural Decoupling** (Pillar 1) and **Optionality Preservation** (Pillar 2) are foundations — you establish these first by mapping and removing dangerous dependencies.
 2. **Stress-to-Signal Conversion** (Pillar 3) requires having something to instrument — logging, monitoring, telemetry. This is layer two.
 3. **Sovereign Intelligence** (Pillar 4) — AI sovereignty, local models, owned cognitive infrastructure — presupposes that you have a foundation worth protecting and a signal worth amplifying. It is not the starting point.
 4. **Asymmetric Payoff Design** (Pillar 5) is the lens applied throughout — concentrate effort where failure is existential.
 A client excited about Pillar 4 who has not addressed Pillar 1 is building a sophisticated roof on a house with no walls.
 ### What "Move Fast" Means Here
 Moving fast does not mean buying AI tools quickly. It means closing the kill chain quickly — with unglamorous, proven controls that stop breaches:
 - Enforce MFA on every account. Today.
 - Patch internet-facing systems. This week.
 - Verify that backups restore. This month.
 - Remove stale privileged accounts. In week one.
 - Turn on logging where it is off. Before anything else.
 These are not interesting. They are not cutting-edge. They are the interventions that would have prevented most of the incidents in the headlines. The AI tools that make headlines did not prevent those incidents.
 ---
 ## When the Vulnerability Surface Is Effectively Infinite
 Recent AI-assisted security research — including large-scale automated vulnerability discovery across entire software stacks — has surfaced a reality that was always true but is now undeniable: **the number of exploitable vulnerabilities in any complex environment exceeds any organisation's capacity to patch them.** This is not a new problem. It is a shift in visibility. The vulnerabilities existed before. We can now find them faster than we can fix them.
 The vendor response to this is predictable: "You need AI-assisted patching." Faster discovery paired with faster remediation, AI all the way down.
 This is the wrong frame. It accepts a race you cannot win.
 ### The Architectural Response
 The correct response to an effectively infinite vulnerability surface is not to patch faster. It is to **move to a realm where most vulnerabilities matter less** — by designing systems architecturally so that the exploitation of any single vulnerability does not lead to existential compromise.
 This is not a new idea. It is the fundamental premise of defence in depth, blast radius limitation, and kill chain thinking. What has changed is the urgency: when AI can identify thousands of vulnerabilities across your stack in hours, the "patch-first" strategy is exposed as insufficient. The architectural strategy becomes the only viable long-term position.
 The moves:
 **Kill chain awareness** — Not every CVE is existential. The ones that matter are the ones that sit on the path from "nothing bad has happened yet" to "the organisation cannot operate." Concentrate protection there. A critical vulnerability in a segmented, non-privileged system is a low-priority finding. The same vulnerability on a domain controller, a backup server, or an OT control system is P0. The vulnerability is the same; the kill chain position is what changes the priority.
 **Blast radius limitation** — Segmentation, least privilege, and structural decoupling mean that exploiting a vulnerability in one component cannot pivot freely through the environment. A flat network with over-privileged accounts converts every vulnerability into a potential total compromise. A segmented, least-privilege environment converts most vulnerabilities into limited-scope incidents.
 **Assume breach posture** — Design for rapid detection and recovery rather than prevention of every entry. If architectural controls are in place, a compromised component is an isolated incident, not a catastrophe. The question shifts from "how do we keep attackers out?" to "how quickly do we detect, contain, and recover?" This is Pillar 3 (Stress-to-Signal Conversion) applied to the vulnerability layer.
 **Known-good baseline** — Configuration management (ASTRAL) and system state tracking mean that after a compromise, you can restore to a verified baseline. The ability to rebuild rapidly from a known-good state reduces the cost of successful exploitation dramatically.
 ### What This Means for Prioritisation
 When clients ask how to respond to the AI vulnerability discovery story, the answer is not a new patching tool. It is a sequenced architectural programme:
 1. Map and close the kill chain — the vulnerabilities that sit on the path to existential compromise get patched first, regardless of CVSS score.
 2. Reduce blast radius — segmentation and least privilege limit the value of any single exploit.
 3. Build detection and recovery capability — assume some vulnerabilities will be exploited; make exploitation detectable and recoverable.
 4. Then consider tooling to accelerate patch velocity for the long tail.
 The correct posture is: **a well-segmented, least-privilege, T0-protected environment with fast recovery capability survives more CVEs than a flat, over-privileged environment with a fast patch programme.** Architecture beats velocity in the vulnerability race. It is the only bet you can actually win.
 ---
 ## Contrast With "Move Fast and Break Things"
 The Silicon Valley mantra was an excuse for externalizing harm. "Move fast and fix things" is its responsible successor:
@@ -32,7 +32,7 @@ When you outsource a security function, you should retain three capabilities int
 | Retained Capability | Why It Cannot Be Outsourced | What It Produces |
 |--------------------|---------------------------|------------------|
-| **Detection Engineering** | Only you know what "normal" looks like in your environment. Only you can write rules that detect anomalies specific to your architecture, your applications, and your user behaviours. | Custom detection rules (KQL, Sigma, YARA, Wazuh) and M365-specific detections via AOC that catch threats generic rules miss |
+| **Detection Engineering** | Only you know what "normal" looks like in your environment. Only you can write rules that detect anomalies specific to your architecture, your applications, and your user behaviours. | Custom detection rules (KQL, Sigma, YARA, Wazuh) and M365-specific detections via PULSAR that catch threats generic rules miss |
 | **Threat Context & Prioritization** | Only you know which assets are crown jewels. Only you can prioritize a vulnerability on your payment gateway over a vulnerability on your marketing blog. | Risk-ranked remediation that aligns with business impact |
 | **Integration & Orchestration** | Only you can connect the SOC to your change management, your identity team, your OT engineers, and your executives. | Closed-loop incident response that produces structural improvement |
@@ -59,7 +59,8 @@ Operational and persuasion documents used in engagements. **Start every new clie
 | [AD and Endpoint Hardening](playbooks/ad-endpoint-hardening.md) | On-prem AD, Windows endpoints, hybrid identity | Infrastructure Consultants, Security Engineers |
 | [Zero-Budget Hardening](playbooks/zero-budget-hardening.md) | Maximize existing tools, minimize new purchases | Consultants, CISOs, IT Managers |
 | [Implementation Playbook](playbooks/implementation-playbook.md) | Tactical step-by-step delivery guide | Technical Leads, Security Engineers |
-| [Sovereign Tool Stack](playbooks/sovereign-tool-stack.md) | Open-source arsenal: Prowler, BloodHound, CISO Assistant, ASTRAL, AOC, Wazuh, Shuffle | Consultants, CTOs, CISOs |
+| [CQRE Product Suite](playbooks/cqre-product-suite.md) | ASTRAL, PULSAR, and AURORA: product details, framework alignment, deployment, and positioning | Consultants, Account Managers |
 | [Sovereign Tool Stack](playbooks/sovereign-tool-stack.md) | Full arsenal: Prowler, BloodHound, CISO Assistant, ASTRAL, PULSAR, AURORA, Wazuh, Shuffle | Consultants, CTOs, CISOs |
 | [Privileged Access Architecture](playbooks/privileged-access-architecture.md) | PAM design: Teleport, Tailscale/Headscale, JIT access, vendor access governance | Security Architects, Infrastructure Consultants, OT Leads |
 | [Sovereign Communications](playbooks/sovereign-communications.md) | Delta Chat chatmail relay, Matrix/Element, crisis out-of-band channels | CISOs, Operations Leads, Incident Response |
 | [Business Case Template](playbooks/business-case-template.md) | Financial justification, ROI, risk quantification | CFOs, Boards, Consultants |
@@ -125,25 +126,26 @@ Operational and persuasion documents used in engagements. **Start every new clie
 8. [NIST CSF 2.0 Baseline Assessment](assessment-templates/nist-csf-baseline.md) — run this first with every new client (the Brownhat Diagnostic)
 9. [Modular Engagements](core/modular-engagements.md) — the full module menu (Modules 1–14) and platform adaptation guide
-10. [Sovereign Tool Stack](playbooks/sovereign-tool-stack.md) — the full arsenal: CQRE tools, open-source stack, commercial partnerships, and when to use each
+10. [CQRE Product Suite](playbooks/cqre-product-suite.md) — ASTRAL, PULSAR, and AURORA: what they do, how they fit the framework, and how to deploy them
-11. [M365 E3 Hardening](playbooks/m365-e3-hardening.md) — primary client environment for MS clients (most are E3)
+11. [Sovereign Tool Stack](playbooks/sovereign-tool-stack.md) — the full arsenal: CQRE tools, open-source stack, commercial partnerships, and when to use each
-12. [AD and Endpoint Hardening](playbooks/ad-endpoint-hardening.md) — on-premises identity and endpoint depth
+12. [M365 E3 Hardening](playbooks/m365-e3-hardening.md) — primary client environment for MS clients (most are E3)
-13. [Privileged Access Architecture](playbooks/privileged-access-architecture.md) — Module 13: Teleport, Tailscale/Headscale, JIT access, vendor remote access governance
+13. [AD and Endpoint Hardening](playbooks/ad-endpoint-hardening.md) — on-premises identity and endpoint depth
-14. [Sovereign Communications](playbooks/sovereign-communications.md) — Module 14: Delta Chat chatmail relay, Matrix/Element, crisis out-of-band channels
+14. [Privileged Access Architecture](playbooks/privileged-access-architecture.md) — Module 13: Teleport, Tailscale/Headscale, JIT access, vendor remote access governance
 15. [Sovereign Communications](playbooks/sovereign-communications.md) — Module 14: Delta Chat chatmail relay, Matrix/Element, crisis out-of-band channels
 **Reference when needed:**
-15. [AI Sovereignty Framework](core/ai-sovereignty-framework.md) — persuasive arguments and objection handling
+16. [AI Sovereignty Framework](core/ai-sovereignty-framework.md) — persuasive arguments and objection handling
-16. [AI Operations Inevitability](core/ai-operations-inevitability.md) — why defensive AI is not optional
+17. [AI Operations Inevitability](core/ai-operations-inevitability.md) — why defensive AI is not optional
-17. [Organizational Resilience](core/organizational-resilience.md) — shift left and Dev/Sec/Ops merger talking points
+18. [Organizational Resilience](core/organizational-resilience.md) — shift left and Dev/Sec/Ops merger talking points
-18. [Retained Capability](core/retained-capability.md) — what to keep in-house when outsourcing SOC, pentest, compliance
+19. [Retained Capability](core/retained-capability.md) — what to keep in-house when outsourcing SOC, pentest, compliance
-19. [Zero-Budget Hardening](playbooks/zero-budget-hardening.md) — extract value from existing tools in 30 days
+20. [Zero-Budget Hardening](playbooks/zero-budget-hardening.md) — extract value from existing tools in 30 days
-20. [Zero-Budget Vulnerability Discovery](playbooks/zero-budget-vulnerability-discovery.md) — script-based and osquery-based discovery before scanner procurement
+21. [Zero-Budget Vulnerability Discovery](playbooks/zero-budget-vulnerability-discovery.md) — script-based and osquery-based discovery before scanner procurement
-21. [Osquery: The Sovereign Discovery Platform](playbooks/osquery-custom-platform.md) — build owned vulnerability and asset inventory capability
+22. [Osquery: The Sovereign Discovery Platform](playbooks/osquery-custom-platform.md) — build owned vulnerability and asset inventory capability
-22. [Rapid Modernisation Plan](playbooks/rapid-modernisation-plan.md) — structured engagement roadmap
+23. [Rapid Modernisation Plan](playbooks/rapid-modernisation-plan.md) — structured engagement roadmap
-23. [Implementation Playbook](playbooks/implementation-playbook.md) — tactical delivery guidance
+24. [Implementation Playbook](playbooks/implementation-playbook.md) — tactical delivery guidance
-24. [Vertical: Power and Utilities](reference/vertical-power-utilities.md), [Vertical: Telco](reference/vertical-telco.md), or [Vertical: Banking](reference/vertical-banking.md) — sector-specific adaptations
+25. [Vertical: Power and Utilities](reference/vertical-power-utilities.md), [Vertical: Telco](reference/vertical-telco.md), or [Vertical: Banking](reference/vertical-banking.md) — sector-specific adaptations
-25. [CIS Controls Mapping](reference/cis-controls-mapping.md) and [NIST CSF Mapping](reference/nist-csf-mapping.md) — standards alignment for auditors and regulators
+26. [CIS Controls Mapping](reference/cis-controls-mapping.md) and [NIST CSF Mapping](reference/nist-csf-mapping.md) — standards alignment for auditors and regulators
 ---
@@ -70,7 +70,7 @@ AI-assisted TVM does not replace basic hygiene. It **accelerates it by an order
 | **Cloud security posture** (Defender for Cloud, Prisma, Wiz) | Cloud resource misconfigurations | AI identifies cloud-specific kill chains (e.g., overly permissive S3 → compromised IAM → lateral movement) |
 | **Zero-budget discovery** (PowerShell, SSH scripts, Syft/Grype, osquery) | Server inventory, SBOMs, package-level CVE correlation | AI aggregates script-based findings into unified risk view. See [Zero-Budget Vulnerability Discovery](zero-budget-vulnerability-discovery.md) |
 | **osquery + FleetDM** | Cross-platform endpoint inventory, real-time process/network data, policy compliance | AI queries live endpoint state for prioritization and kill chain simulation. See [Osquery: The Sovereign Discovery Platform](osquery-custom-platform.md) |
-| **AOC (Admin Operations Center)** | M365 audit log intelligence, anomalous admin behaviour, privilege escalation detection | AI enriches insider-threat context with external vulnerability data for complete kill chain picture. See [Sovereign Tool Stack](sovereign-tool-stack.md) |
+| **PULSAR (Platform for Unified Log Search, Alerting & Review)** | M365 audit log intelligence, anomalous admin behaviour, privilege escalation detection | AI enriches insider-threat context with external vulnerability data for complete kill chain picture. See [Sovereign Tool Stack](sovereign-tool-stack.md) |
 | **Prowler** | Multi-cloud security posture (AWS, Azure, GCP) | AI correlates cloud misconfigurations with endpoint and identity findings for cross-layer risk scoring. See [Sovereign Tool Stack](sovereign-tool-stack.md) |
 | **Attack surface management** (Cortex Xpanse, Shodan, Nuclei, Amass) | External-facing assets unknown to IT | AI maps shadow IT and forgotten assets faster than manual discovery. See [Perimeter Scanning Capability](perimeter-scanning-capability.md) |
 | **Software bill of materials (SBOM)** | Known vulnerable components in applications | AI monitors SBOMs against real-time CVE disclosure and exploit availability |
@@ -0,0 +1,213 @@
 # CQRE Product Suite: ASTRAL, PULSAR, and AURORA
 > *"Three questions every M365 administrator eventually asks: what does my configuration look like, what happened in my tenant, and what does it mean? The CQRE suite is built to answer all three — each product independently valuable, progressively more powerful in combination."*
 This document describes the three CQRE-built products, how they fit into the antifragile consulting framework, and how to position and deploy them in engagements.
 ---
 ## Suite Overview
 | Product | Full Name | What It Answers | Model | Repo |
 |---------|-----------|-----------------|-------|------|
 | **ASTRAL** | Admin Security: Tenant Review, Automation & Lifecycle | *What does my M365 configuration look like and what has changed?* | Free, open source | [github.com/cqrenet/astral](https://github.com/cqrenet/astral) |
 | **PULSAR** | Platform for Unified Log Search, Alerting & Review | *What happened in my tenant, when, and by whom?* | Free, open source | [github.com/cqrenet/pulsar](https://github.com/cqrenet/pulsar) |
 | **AURORA** | Audit, Unified Review, Observability & Remediation for Administrators | *What does it mean and what should I do?* | Paid | [aurora.cqre.net](https://aurora.cqre.net) |
 **The product narrative in one sentence**: PULSAR captures the signal, ASTRAL holds the baseline, AURORA makes sense of both.
 ---
 ## Framework Alignment
 Each product maps directly to specific antifragile pillars from the [Antifragile Manifest](../core/antifragile-manifest.md).
 ### ASTRAL → Pillar 1 (Structural Decoupling) + Pillar 5 (Asymmetric Payoff Design)
 ASTRAL treats M365 configuration as code — Git-tracked snapshots with PR-based review, drift detection, and baseline restore. Every Intune profile, Conditional Access policy, and Entra setting is versioned, auditable, and recoverable.
 **Pillar 1 alignment**: ASTRAL surfaces hidden coupling in M365 configuration. Conditional Access policies with undocumented exclusion groups, Intune profiles silently competing, admin roles accumulating without review — these are the dependencies that produce fragility. ASTRAL makes them visible and governable.
 **Pillar 5 alignment**: The deployment cost is low (one Azure DevOps project, one Entra app registration). The protection payoff is disproportionately large: compliance evidence produced automatically, configuration changes reviewed before they become incidents, rollback available in minutes.
 **Kill chain relevance**: A compromised admin account that modifies Conditional Access policies is a kill-chain event. ASTRAL detects this drift within minutes via the event-driven change probe and surfaces it as a PR requiring review.
 ### PULSAR → Pillar 3 (Stress-to-Signal Conversion)
 PULSAR ingests M365 audit events — Entra directory changes, Intune actions, Exchange/SharePoint/Teams operations — into a searchable, retained store with alerting and SIEM forwarding.
 **Pillar 3 alignment**: PULSAR is the instrumentation layer for M365. Without it, admin actions are visible for 90 days in the M365 portal and then gone. With it, every admin action becomes permanent, searchable signal. An incident that would have been un-investigable three months later becomes reconstructible in minutes.
 The antifragile principle is explicit: **every stress event produces a signal**. PULSAR ensures no signal is lost.
 **Kill chain relevance**: When a threat actor enumerates admin accounts, modifies authentication methods, or creates a new enterprise application for persistence, PULSAR captures these events. Combined with alerting rules, PULSAR converts audit noise into actionable detection.
 ### AURORA → Pillar 4 (Sovereign Intelligence) + Pillar 2 (Optionality Preservation)
 AURORA connects to PULSAR and ASTRAL via their MCP servers and exposes a unified AI-assisted interface for cross-tool diagnostics, multi-scope orchestration, and enriched SIEM forwarding.
 **Pillar 4 alignment**: AURORA is sovereign intelligence applied to M365 operations. The cross-tool diagnostic tools — correlating audit events with configuration state — produce intelligence that no commercial tool natively generates. This intelligence lives in your infrastructure (self-hosted) or in EU-hosted infrastructure (managed tier), not in a vendor platform you cannot control.
 **Pillar 2 alignment**: AURORA is designed for optionality at every layer. It stores no data itself — data lives in PULSAR's MongoDB and ASTRAL's Git repository, both under your control. The AI layer is pluggable (Azure OpenAI, Ollama, or the managed `llm.cqre.net` endpoint). Switching the underlying model requires one config line.
 ---
 ## Product Details
 ### ASTRAL
 **What it tracks**:
 *Intune*: App Configuration, App Protection, Applications, Compliance Policies, Device Configurations, Enrollment Configurations, Filters, Scope Tags, Scripts, Settings Catalog, and more.
 *Entra*: Named Locations, Authentication Strengths, Conditional Access, App Registrations, Enterprise Applications.
 **How it works**:
 1. An Azure DevOps pipeline runs daily (and on-demand via an event-driven change probe) to export the full tenant configuration.
 2. Drift from the committed baseline is committed to a drift branch and surfaced as a rolling PR.
 3. Reviewers approve or reject individual changes in the PR. Approved changes merge; rejected changes trigger an automated restore.
 4. The entire history lives in Git — indefinite, auditable, diff-able.
 **AI (optional)**: Bring your own Azure OpenAI endpoint to generate human-readable PR narratives. ASTRAL is complete without it — AI is supplementary, not required.
 **MCP server**: ASTRAL includes an MCP server (Azure Container Apps) that exposes tenant state and drift history to AI assistants via natural-language queries. This is what AURORA connects to.
 **Deployment**: Azure DevOps, one pipeline set per tenant. Full setup guide in [`deploy/onboarding-runbook.md`](https://github.com/cqrenet/astral/blob/main/deploy/onboarding-runbook.md).
 **Engagement module pairings**: Modules 1–5 (all M365 modules), Module 3 (M365 Hardening) as primary drift detection layer. Used in the first-week baseline checklist for every M365 engagement.
 ---
 ### PULSAR
 **What it ingests**:
 - Entra ID directory audit logs
 - Intune audit logs
 - Exchange Online, SharePoint, and Teams via the Office 365 Management Activity API
 **Core capabilities**:
 - Watermark-based incremental ingestion with MongoDB persistence
 - Search and filter UI with REST API
 - Alerting rules engine with webhook delivery *(see maturity note below)*
 - SIEM forwarding *(see maturity note below)*
 - MCP server (stdio and SSE): `search_events`, `get_event`, `get_summary`
 - Entra OIDC auth and Azure Key Vault integration
 > **Maturity note — alerting and SIEM forwarding**: Both features are functional but proof-of-concept quality. They are suitable for evaluation and non-critical environments. Alerting has no UI for rule management and webhook delivery has no retry logic. SIEM forwarding is basic with no delivery guarantees. Production hardening of both is on the roadmap. Do not recommend these features for production use in critical environments without documenting this caveat to the client.
 **MCP server**: PULSAR's MCP server exposes audit event search to AI assistants. AURORA connects to this endpoint for cross-tool diagnostics.
 **Deployment**: Docker Compose. Full quickstart in the [GitHub README](https://github.com/cqrenet/pulsar). Azure deployment guide in `DEPLOY-AZURE.md`.
 **Engagement module pairings**: Module 12 (Blue/Purple Team Foundation) as the M365 detection layer; Module 10 (AI-Assisted TVM) for audit-trail enrichment; any retained capability engagement where M365 log retention is a client requirement.
 ---
 ### AURORA
 **What it does**: A unified operations platform that sits in front of PULSAR and ASTRAL. Connects to both via MCP, exposes a single AI interface, and provides cross-tool diagnostics that neither product can answer alone.
 AURORA stores no data. All data lives in PULSAR (MongoDB) and ASTRAL (Git).
 **Cross-tool diagnostic tools**:
 | Tool | What It Answers |
 |------|----------------|
 | `diagnose_policy_errors` | "Why is this Intune compliance policy succeeding on most devices but erroring on some?" — pulls ASTRAL policy config and PULSAR audit events for the same policy |
 | `explain_device_compliance` | "Why did this device suddenly become non-compliant?" — combines ASTRAL assignment data with PULSAR event timeline |
 | `correlate_drift_with_audit` | "Who in the portal triggered this configuration drift commit?" — matches ASTRAL Git commits with PULSAR audit events by timestamp |
 | `tenant_security_summary` | "What happened in my tenant this week that I should know about?" — combines open ASTRAL drift PRs with PULSAR event summary, generates executive briefing |
 | `compare_scopes` | "What's different between my production and development Conditional Access policies?" — cross-scope comparison |
 **Multi-scope orchestration**: AURORA connects to multiple named ASTRAL instances. Production read-only and development read-write in the same interface. Directly useful for clients with strict prod/non-prod separation.
 **Enriched SIEM forwarding**: PULSAR forwards raw audit events. AURORA forwards enriched events — audit events correlated with ASTRAL configuration state at the time of the event. This produces materially higher-quality data for SIEM detection rules.
 **Pricing** (EUR, ex. VAT):
 | Tier | Self-hosted | Hosted (fully managed) |
 |------|-------------|----------------------|
 | Single tenant | €259/mo (€2,590/yr) | €389/mo (€3,890/yr) |
 | Up to 5 scopes | €429/mo (€4,290/yr) | €599/mo (€5,990/yr) |
 | Enterprise | Custom | Custom |
 Self-hosted customers bring their own Azure OpenAI endpoint (or any OpenAI-compatible API including Ollama for local models). Hosted tier includes managed AI (~500 queries/month fair use).
 ---
 ## Regulatory Alignment (EU)
 The CQRE suite was designed with EU regulatory requirements as primary constraints, not afterthoughts.
 | Regulation | Requirement | CQRE capability |
 |------------|-------------|-----------------|
 | **NIS2** Art. 21 | Configuration management, logging and monitoring, access control | ASTRAL (config), PULSAR (logging), AURORA (cross-tool analysis) |
 | **DORA** Art. 10 | ICT incident log retention and monitoring | PULSAR (permanent audit log retention, searchable) |
 | **DORA** Art. 11 | ICT change management records | ASTRAL Git trail (timestamped, reviewed, approved) |
 | **GDPR** Art. 5(2) | Accountability principle — demonstrate compliance | ASTRAL Git history is directly usable as audit evidence |
 | **GDPR** Art. 32 | Appropriate technical measures for data protection | Continuous config governance + audit log retention |
 | **GDPR** Art. 33 | 72-hour breach notification | PULSAR enables rapid incident reconstruction |
 | **ISO 27001** A.8.9 | Configuration management | ASTRAL |
 | **ISO 27001** A.8.15–16 | Logging and monitoring | PULSAR |
 **Consultant talking point**: For clients in NIS2-regulated sectors (health, finance, digital infrastructure, public sector), the CQRE suite is not a nice-to-have — it directly maps onto mandatory Article 21 measures. Frame the deployment cost against the supervisory authority's enforcement posture in their country, not against a generic security ROI.
 ---
 ## Positioning in Engagements
 ### Combination A — PULSAR + ASTRAL (free entry, any engagement)
 Deploy the free stack at the start of any M365 engagement. ASTRAL provides the baseline capture that week 1 requires. PULSAR provides the audit trail that retained capability clients need. Both are free — there is no procurement barrier.
 ### Combination B — ASTRAL only (compliance-driven clients)
 Clients with ISO 27001 in progress, DORA obligations, or NIS2 scope often need the config change governance story before they need event correlation. ASTRAL alone answers the auditor's question: "show me every M365 change in the last 12 months with evidence it was reviewed and approved."
 ### Combination C — PULSAR only (incident-response or log-retention clients)
 Clients who have had a recent incident and discovered their audit logs were gone, or clients facing insurance requirements for log retention, are natural PULSAR deployments. Value is immediate — longer retention, bulk search, alerting.
 ### Combination D — Full stack with AURORA (mature clients, retained relationships)
 Clients who have run PULSAR + ASTRAL for at least one module cycle are ready for AURORA. The upsell requires no education — they already know the cross-tool investigation pain that AURORA removes. AURORA self-hosted is the right recommendation for technically capable clients with data sovereignty requirements. AURORA hosted is the right recommendation for SMBs who want zero operational burden.
 ### What to avoid
 Do not lead with AURORA in a first engagement. The value of the cross-tool diagnostics is only legible to clients who have experienced the investigation friction of running PULSAR and ASTRAL separately. Clients who have not felt that pain will not pay for the solution.
 ---
 ## Deployment Prerequisites
 | Product | Prerequisites |
 |---------|--------------|
 | ASTRAL | Azure DevOps organisation, Entra app registration (provisioned by bootstrap script), write access to ADO Git repo |
 | PULSAR | Docker Compose capable host (or Azure Container Apps for cloud deploy), Entra app registration (provisioned by bootstrap script), MongoDB |
 | AURORA | Running PULSAR + ASTRAL with MCP servers enabled; AURORA licence key; Docker Compose or Azure Container Apps |
 ---
 ## Objection Handling
 **"We already have Microsoft Purview / Sentinel."**
 Purview and Sentinel are E5 features — €28+/user/month. The CQRE free stack provides comparable log retention and config governance for the entire engineering cost of deploying it. For clients already at E5, AURORA provides the correlation layer that Sentinel and Purview still do not natively deliver.
 **"We don't want to run our own infrastructure."**
 AURORA hosted solves this. CQRE manages the entire stack. Single tenant starts at €389/month — less than one day of external incident response.
 **"We tried open source tools before and found them too complex."**
 The complexity objection is usually a maintenance objection, not a deployment objection. Address it directly: who will own this after we leave? If the client cannot name a person, the sovereign stack requires a retained capability support arrangement. If they can, the deployment is a few hours of consultant time.
 **"Can we see the code?"**
 ASTRAL and PULSAR are fully open source (MIT licensed) on GitHub. AURORA is commercial source — clients can request a code review under NDA as part of enterprise procurement.
 ---
 *For the full sovereign tool stack including third-party open source tools, see [Sovereign Tool Stack](sovereign-tool-stack.md).*
 *For module pairings and engagement sequencing, see [Modular Engagements](../core/modular-engagements.md).*
 *For retained capability support arrangements, see [Retained Capability](../core/retained-capability.md).*
@@ -122,7 +122,7 @@ Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true
 - Retention: 90 days (E3 default); document the gap vs. 1-year requirement in some regulations
 - Export for analysis: `Search-UnifiedAuditLog` or use Microsoft Purview Audit (Standard) if available
- **AOC integration**: For clients with AOC deployed, unified audit logs are ingested automatically and correlated with Entra ID sign-in events to surface anomalous admin behaviour without manual PowerShell queries
+- **PULSAR integration**: For clients with PULSAR deployed, unified audit logs are ingested automatically and correlated with Entra ID sign-in events to surface anomalous admin behaviour without manual PowerShell queries
 **Enable Mailbox Auditing**
@@ -344,6 +344,6 @@ See [Vertical: Banking](../reference/vertical-banking.md) for full regulatory al
 *Previous: [Zero-Budget Hardening](zero-budget-hardening.md)*
 *Next: [AD and Endpoint Hardening](ad-endpoint-hardening.md)*
-*For the complete open-source tool arsenal including ASTRAL and AOC, see [Sovereign Tool Stack](sovereign-tool-stack.md)*
+*For the complete open-source tool arsenal including ASTRAL and PULSAR, see [Sovereign Tool Stack](sovereign-tool-stack.md)*
 For how Intune deployment becomes the natural entry point for broader security transformation, see [Endpoint Management Entry Vector](endpoint-management-entry-vector.md).
@@ -6,7 +6,7 @@ This document provides the complete capability map for our consulting practice:
 1. **Clients** who want to understand what we bring to an engagement
 2. **Consultants** who need to select the right tool for the right module
-3. **Our own product team** who are building ASTRAL and AOC to close the M365-native gap
+3. **Our own product team** who are building ASTRAL and PULSAR to close the M365-native gap
 ---
@@ -115,11 +115,11 @@ This document provides the complete capability map for our consulting practice:
 | **Antifragile pillar** | Sovereign Intelligence, Asymmetric Payoff Design |
 | **Engagement modules** | Module 4 (Data Governance); Module 11 (Embedded Quality); all compliance-driven clients |
 | **Typical output** | Live compliance dashboard: "DORA Article 12: 14 of 17 controls evidence-complete; 3 gaps assigned to owners with due dates" |
-| **Integration** | Pulls findings from Prowler, osquery, BloodHound, and AOC into unified evidence packages |
+| **Integration** | Pulls findings from Prowler, osquery, BloodHound, and PULSAR into unified evidence packages |
 **The conversation**:
-> *"Your auditor wants evidence that you monitor privileged access. CISO Assistant links the BloodHound scan, the Purple Knight score, the AOC admin activity report, and the osquery listening-ports query into a single evidence package for DORA Article 8. No scrambling for screenshots the night before the audit."*
+> *"Your auditor wants evidence that you monitor privileged access. CISO Assistant links the BloodHound scan, the Purple Knight score, the PULSAR admin activity report, and the osquery listening-ports query into a single evidence package for DORA Article 8. No scrambling for screenshots the night before the audit."*
 ---
@@ -129,16 +129,29 @@ This document provides the complete capability map for our consulting practice:
 | Attribute | Detail |
 |-----------|--------|
-| **What it does** | Intelligent backup, configuration drift detection, and change management for Microsoft Intune, Entra ID, and M365 tenant configurations. Captures baseline state, detects unauthorised or accidental changes, and enables rapid rollback. |
+| **What it does** | Git-tracked snapshots of Microsoft Intune and Entra ID configuration with Azure DevOps pipeline-driven drift detection, PR-based review and approval workflow, and baseline restore capability. Answers: *"what does my tenant configuration look like, what changed, and can we revert it?"* |
-| **Why we built it** | No existing tool treats M365 configuration as code. A tenant with 500 conditional access policies, 200 Intune profiles, and 50 compliance policies is unmanageable without version control and drift detection. ASTRAL provides GitOps for M365. |
+| **Why we built it** | No existing tool treats M365 configuration as code. A tenant with 200 CA policies, 500 Intune profiles, and dozens of authentication methods is unmanageable without version control and drift detection. ASTRAL provides GitOps for M365. |
-| **Antifragile pillar** | Structural Decoupling, Stress-to-Signal Conversion |
+| **Antifragile pillar** | Structural Decoupling (surface hidden dependencies), Asymmetric Payoff Design (high protection from low deployment cost) |
 | **Engagement modules** | Module 1 (Endpoint Management); Module 2 (Identity Security); Module 3 (M365 Security Hardening); retained capability engagements |
-| **Typical output** | "Configuration drift detected: 3 conditional access policies modified outside change window; 1 Intune profile deleted; all changes attributable to [admin account]; rollback initiated automatically" |
+| **Typical output** | Rolling PR: "Drift detected: 3 Conditional Access policies modified outside change window; 1 Intune profile deleted; changes attributed to admin@contoso.com via audit log. Reviewer decision: /accept or /reject." |
-| **Integration** | Feeds change logs into AOC for audit intelligence; exports configuration state to CISO Assistant for compliance evidence |
+| **Repository** | [github.com/cqrenet/astral](https://github.com/cqrenet/astral) — free, open source (MIT) |
 | **Integration** | Entra ID and Intune baseline; feeds CISO Assistant for compliance evidence; AURORA connects to ASTRAL's MCP server for cross-tool diagnostics |
 **What it tracks** (current scope):
 *Intune*: App Configuration, App Protection, Applications, Compliance Policies, Device Configurations, Enrollment Configurations, Filters, Scope Tags, Scripts, Settings Catalog.
 *Entra*: Named Locations, Authentication Strengths, Conditional Access, App Registrations, Enterprise Applications. Admin role assignments and auth methods policies in development (Phase 1 roadmap).
 **Key capabilities**:
 - Event-driven change probe (Azure Function App) triggers backup within minutes of a tenant change — no more hourly polling
 - Reviewer `/accept` and `/reject` commands in ADO PR threads; auto-queued restore on rejection
 - MCP server (Azure Container Apps) exposes tenant state and drift history to AI assistants
 - Optional Azure OpenAI PR narratives — BYOAI, fully optional, ASTRAL is complete without it
 **The conversation**:
-> *"Your M365 tenant has 400 configuration objects and no version control. When an admin accidentally deletes a conditional access policy at 2 AM, you discover it 6 hours later because users are complaining. ASTRAL detects the deletion in 60 seconds, attributes it to the specific admin session, and offers one-click rollback. This is not backup. This is configuration immunity."*
+> *"Your M365 tenant has 400 configuration objects and no version control. When an admin accidentally deletes a Conditional Access policy at 2 AM, you discover it 6 hours later because users are complaining. ASTRAL detects the deletion within minutes via its event-driven change probe, attributes it to the specific admin session, and offers one-click rollback through the restore pipeline. This is not backup. This is configuration governance."*
 **ASTRAL companion utilities (CQRE)**:
@@ -152,20 +165,63 @@ This document provides the complete capability map for our consulting practice:
 ### M365 Audit Log Intelligence
-#### AOC — Admin Operations Center (Our Platform)
+#### PULSAR (Our Platform)
 | Attribute | Detail |
 |-----------|--------|
-| **What it does** | Correlates Microsoft 365 Unified Audit Log, Entra ID sign-in logs, and Intune operational logs into actionable intelligence. Detects anomalous admin behaviour, privilege escalation, shadow IT creation, and data exfiltration patterns. |
+| **What it does** | Ingests Microsoft 365 admin audit events (Entra, Intune, Exchange, SharePoint, Teams) into MongoDB and exposes a UI, REST API, and MCP server for search, filtering, alerting, and SIEM forwarding. Answers: *"what happened in my tenant, when, and by whom?"* |
-| **Why we built it** | The native M365 audit log is a firehose: 10,000+ events per day in a typical tenant, searchable only via slow PowerShell or expensive Sentinel. AOC extracts the 50 events that matter and enriches them with identity context, device state, and business impact. |
+| **Why we built it** | Native M365 audit log retention is capped at 90 days (E3) or 180 days (E5) — searchable only via slow PowerShell or expensive Sentinel. PULSAR provides permanent retention, fast search, and an MCP interface so AI assistants can query audit history directly. |
-| **Antifragile pillar** | Sovereign Intelligence, Stress-to-Signal Conversion |
+| **Antifragile pillar** | Stress-to-Signal Conversion — every admin action becomes permanent, searchable signal |
-| **Engagement modules** | Module 12 (Blue/Purple Team Foundation); retained capability (Detection Engineering); all M365 hardening engagements |
+| **Engagement modules** | Module 12 (Blue/Purple Team Foundation); retained capability (Detection Engineering); any engagement with log retention requirements |
-| **Typical output** | Daily brief: "3 anomalous events flagged: Global Admin [X] added external user at 03:14; Exchange Admin [Y] exported 12,000 mailboxes; Service Principal [Z] granted Mail.Read to unverified publisher. All require validation within 4 hours." |
+| **Typical output** | UI search: "Show me all Conditional Access policy changes by GlobalAdmin@contoso.com in the last 30 days." MCP query: `search_events(actor="globaladmin@contoso.com", operation="Update conditional access policy", days=30)` |
-| **Integration** | Receives alerts from osquery/FleetDM, Wazuh, and Prowler; pushes cases to CISO Assistant for risk register tracking; enriches AI-assisted TVM with insider-threat context; **MCP server** enables Claude and other AI clients to query audit logs in natural language directly from the analyst's desktop |
+| **Repository** | [github.com/cqrenet/pulsar](https://github.com/cqrenet/pulsar) — free, open source (MIT) |
 | **Integration** | AURORA connects to PULSAR's MCP server for cross-tool diagnostics; alerting rules forward to webhook endpoints; SIEM forwarding to Sentinel/Splunk *(see maturity note)* |
 **Sources ingested**:
 - Entra ID directory audit logs
 - Intune audit logs
 - Exchange Online, SharePoint, and Teams via the Office 365 Management Activity API
 **MCP tools**: `search_events`, `get_event`, `get_summary` — available over stdio (local) or SSE (remote, with API key or Entra OIDC auth).
 > **Maturity note — alerting and SIEM forwarding**: Both features are functional but proof-of-concept quality, suitable for evaluation and non-critical environments. Alerting has no rule management UI and webhook delivery has no retry logic. SIEM forwarding is basic with no delivery guarantees and is not tested at volume. Do not recommend these features for production use in environments where reliability is required — hardening is on the roadmap. AURORA provides production-grade enriched SIEM forwarding for clients who need it now.
 **The conversation**:
-> *"Microsoft gives you the audit log. They do not give you the story. AOC reads 50,000 events per night and tells you the three that need human attention: an admin added an external user at 3 AM, another exported 12,000 mailboxes, and a service principal granted Mail.Read to an unverified app. These are not false positives. These are the events that precede breaches."*
+> *"Microsoft gives you the audit log. They also take it away after 90 days. PULSAR keeps it forever. When you have an incident six months from now — and you will — and you need to know who added that external user, who modified that CA policy, and what that service principal was doing at 3 AM the week before the breach — PULSAR answers in seconds. Without it, the question is unanswerable."*
 ---
 ### M365 Governance Intelligence
 #### AURORA (Our Platform — Paid)
 | Attribute | Detail |
 |-----------|--------|
 | **What it does** | A unified operations platform connecting PULSAR and ASTRAL via their MCP servers. Provides AI-assisted cross-tool diagnostics, multi-scope orchestration, and enriched SIEM forwarding that neither product can produce alone. Answers: *"what does it mean and what should I do?"* |
 | **Why we built it** | Running PULSAR and ASTRAL separately leaves an investigation gap: audit events and configuration state live in different places with no correlation layer. AURORA closes that gap. |
 | **Antifragile pillar** | Sovereign Intelligence (owned observability and reasoning infrastructure), Optionality Preservation (data stays yours; AI layer is pluggable) |
 | **Engagement modules** | Retained capability engagements; any client running the full PULSAR + ASTRAL stack |
 | **Pricing** | Self-hosted: €259/mo (single tenant), €429/mo (≤5 scopes). Hosted: €389/mo, €599/mo. Enterprise: custom. |
 | **Repository** | [aurora.cqre.net](https://aurora.cqre.net) — commercial, self-hosted or CQRE-managed |
 **Cross-tool diagnostic tools**:
 | Tool | What it answers |
 |------|----------------|
 | `diagnose_policy_errors` | "Why is this Intune compliance policy erroring on some devices but not others?" — pulls ASTRAL policy config and PULSAR audit events for the same policy |
 | `explain_device_compliance` | "Why did this device suddenly become non-compliant?" — combines ASTRAL assignment data with PULSAR event timeline |
 | `correlate_drift_with_audit` | "Who triggered this configuration drift commit?" — matches ASTRAL Git commits with PULSAR audit events by timestamp |
 | `tenant_security_summary` | "What happened this week that I should know about?" — combines open ASTRAL drift PRs with PULSAR event summary |
 | `compare_scopes` | "What's different between my production and development CA policies?" |
 **AURORA stores no data.** All data lives in PULSAR (MongoDB) and ASTRAL (Git) under the client's control. AURORA is purely the query, orchestration, and intelligence layer.
 **When to recommend**: After at least one module cycle with PULSAR + ASTRAL deployed. The upsell is natural — clients who have investigated an incident using both tools separately will immediately understand AURORA's value.
 **The conversation**:
 > *"You have ASTRAL showing you what changed and PULSAR showing you who did what. AURORA answers the question neither product answers alone: are those two things related? Did the admin action in PULSAR trigger the drift commit in ASTRAL? Was that a legitimate change or a compromise? That correlation currently takes 20 minutes of manual investigation. AURORA does it in 30 seconds."*
 ---
@@ -180,7 +236,7 @@ This document provides the complete capability map for our consulting practice:
 | **Antifragile pillar** | Structural Decoupling, Stress-to-Signal Conversion |
 | **Engagement modules** | Module 2 (M365 Identity Security); Module 3 (M365 Security Hardening); compliance audits requiring CA policy evidence (NIS2, ISO 27001, DORA) |
 | **Typical output** | Excel workbook with one row per policy: policy name, conditions, controls, named groups and apps (not object IDs), assignment scope, current state (enabled/disabled/report-only), and export timestamp. Audit-ready without a single screenshot. |
-| **Integration** | Export feeds into ASTRAL as the human-readable CA policy baseline (state at engagement start); CISO Assistant links the workbook as evidence for Entra ID hardening controls; AOC change alerts are cross-referenced against the export to identify which named policy changed |
+| **Integration** | Export feeds into ASTRAL as the human-readable CA policy baseline (state at engagement start); CISO Assistant links the workbook as evidence for Entra ID hardening controls; PULSAR change alerts are cross-referenced against the export to identify which named policy changed |
 **The conversation**:
@@ -199,7 +255,7 @@ This document provides the complete capability map for our consulting practice:
    ┌───────────────┬───────────────┼───────────────┬───────────────┐
    ▼               ▼               ▼               ▼               ▼
 ┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐
-│ Prowler │   │BloodHound│   │ ASTRAL  │   │  AOC    │   │ osquery │
+│ Prowler │   │BloodHound│   │ ASTRAL  │   │ PULSAR  │   │ osquery │
 │(Cloud)  │   │  (AD)   │   │ (M365)  │   │(Audit)  │   │(Endpoint)│
 └────┬────┘   └────┬────┘   └────┬────┘   └────┬────┘   └────┬────┘
     │             │             │             │             │
@@ -221,7 +277,7 @@ This document provides the complete capability map for our consulting practice:
 **Data flow**:
 1. **Discovery layer** (Prowler, BloodHound, osquery, ASTRAL) collects raw security state
-2. **Intelligence layer** (AOC, AI-assisted TVM) correlates, enriches, and prioritises
+2. **Intelligence layer** (PULSAR, AI-assisted TVM) correlates, enriches, and prioritises
 3. **Governance layer** (CISO Assistant) maps findings to compliance frameworks and tracks remediation
 4. **Validation layer** (Purple Knight, Forest Druid, purple team exercises) proves fixes work
@@ -233,7 +289,7 @@ Our current stack covers cloud posture, AD security, GRC, M365 configuration, an
 ### Gap 1: Endpoint Detection and Response (EDR) — The Visibility Gap
-**Current state**: osquery provides structured endpoint inventory and compliance. AOC ingests M365 audit logs. What is missing is real-time behavioural detection on the endpoint itself.
+**Current state**: osquery provides structured endpoint inventory and compliance. PULSAR ingests M365 audit logs. What is missing is real-time behavioural detection on the endpoint itself.
 **Recommended close**: **Wazuh + Sysmon** (open-source EDR stack)
@@ -252,7 +308,7 @@ Our current stack covers cloud posture, AD security, GRC, M365 configuration, an
 ### Gap 2: Security Orchestration and Automated Response (SOAR) — The Response Gap
-**Current state**: AOC detects anomalous admin behaviour. ASTRAL detects configuration drift. What is missing is automated response: disabling a compromised account, isolating a device, or revoking an OAuth grant at machine speed.
+**Current state**: PULSAR detects anomalous admin behaviour. ASTRAL detects configuration drift. What is missing is automated response: disabling a compromised account, isolating a device, or revoking an OAuth grant at machine speed.
 **Recommended close**: **Shuffle** (open-source SOAR)
@@ -263,7 +319,7 @@ Our current stack covers cloud posture, AD security, GRC, M365 configuration, an
 | Self-hosted: data never leaves client infrastructure |
 | Replaces €100,000+/year commercial SOAR platforms |
-**Example playbook**: AOC detects impossible-travel sign-in → Shuffle disables account → ASTRAL revokes all active sessions → Slack alerts SOC → CISO Assistant logs incident → Ticket created in client ITSM.
+**Example playbook**: PULSAR detects impossible-travel sign-in → Shuffle disables account → ASTRAL revokes all active sessions → Slack alerts SOC → CISO Assistant logs incident → Ticket created in client ITSM.
 **When to deploy**: Module 12 (Blue/Purple Team Foundation); retained capability engagements.
@@ -271,7 +327,7 @@ Our current stack covers cloud posture, AD security, GRC, M365 configuration, an
 ### Gap 3: Incident Response Case Management — The Coordination Gap
-**Current state**: Findings are scattered across Prowler, BloodHound, AOC, and osquery. What is missing is a single case management system that tracks incidents from detection through remediation to post-mortem.
+**Current state**: Findings are scattered across Prowler, BloodHound, PULSAR, and osquery. What is missing is a single case management system that tracks incidents from detection through remediation to post-mortem.
 **Recommended close**: **TheHive + Cortex** (open-source SOC case management)
@@ -330,7 +386,7 @@ Our current stack covers cloud posture, AD security, GRC, M365 configuration, an
 |----------|--------------|
 | Protocol analysis: extracts metadata from HTTP, DNS, TLS, SMB without full packet storage | IDS/IPS with 30,000+ signatures and emerging threat rules |
 | Scales to 10 Gbps+ on commodity hardware | Can drop malicious traffic inline (IPS mode) |
-| Output is structured JSON—easy to feed into Wazuh or AOC | Native file extraction and malware detection |
+| Output is structured JSON—easy to feed into Wazuh or PULSAR | Native file extraction and malware detection |
 **When to deploy**: Module 8 (OT Security Assessment) for industrial network segmentation validation; Module 12 (Blue/Purple Team) for detection engineering.
@@ -345,7 +401,7 @@ Our current stack covers cloud posture, AD security, GRC, M365 configuration, an
 | AD security assessment | **Purple Knight / Forest Druid** | PingCastle, ADRecon | Semperis Directory Services Protector | AD hardening engagements |
 | GRC and compliance | **CISO Assistant** | OpenGRC, SimpleRisk | ServiceNow GRC, RSA Archer | DORA, NIS2, SOC 2 clients |
 | M365 backup/change mgmt | **ASTRAL** | — (no open-source equivalent) | Veeam, AvePoint, SkyKick | All M365 clients; retained capability |
-| M365 audit intelligence | **AOC** | — (no open-source equivalent) | Microsoft Sentinel, ManageEngine | All M365 clients; SOC co-management |
+| M365 audit intelligence | **PULSAR** | — (no open-source equivalent) | Microsoft Sentinel, ManageEngine | All M365 clients; SOC co-management |
 | CA policy documentation | **CAExporter** | — (no equivalent) | — | Every Module 2 engagement; CA audits |
 | AD password audit | **Elysium** | — (DSInternals manual use) | Netwrix Password Policy, Specops | Every AD engagement; Module 6 |
 | Intune baseline deployment | **macOS_IntuneManagement** | — (no cross-platform equivalent) | — | Tenant migrations; brownfield baseline |
@@ -382,13 +438,13 @@ Our current stack covers cloud posture, AD security, GRC, M365 configuration, an
 **CQRE utilities**: macOS_IntuneManagement (baseline deployment, cross-tenant migration); IntunePolicyParser (policy audit register); M365-Scripts (MDE device lifecycle); E8-CAT (pre/post hardening Essential Eight score)
 ### Module 2: M365 Identity Security
-**Primary**: AOC (audit log intelligence) + BloodHound (hybrid identity attack paths)
+**Primary**: PULSAR (audit log intelligence) + BloodHound (hybrid identity attack paths)
 **Augmentation**: Purple Knight (AD security baseline)
 **CQRE utilities**: CAExporter (CA policy documentation baseline — run first, before any CA hardening)
 ### Module 3: M365 Security Hardening
 **Primary**: ASTRAL (configuration state) + Prowler (Azure posture)
-**Augmentation**: AOC (continuous monitoring of security control changes)
+**Augmentation**: PULSAR (continuous monitoring of security control changes)
 **CQRE utilities**: CAExporter (CA policy register as audit evidence); E8-CAT (macro restriction and application hardening verification)
 ### Module 6: On-Premise AD Hardening
@@ -406,10 +462,10 @@ Our current stack covers cloud posture, AD security, GRC, M365 configuration, an
 ### Module 12: Blue/Purple Team Foundation
 **Primary**: Wazuh + Sysmon + TheHive + Cortex + Shuffle
-**Augmentation**: AOC (M365-specific detections) + Velociraptor (endpoint forensics) + OpenCanary (deception) + OpenCTI (threat intel correlation)
+**Augmentation**: PULSAR (M365-specific detections) + Velociraptor (endpoint forensics) + OpenCanary (deception) + OpenCTI (threat intel correlation)
 ### Retained Capability: Detection Engineering
-**Primary**: Wazuh (rule authoring) + AOC (M365 detections) + Shuffle (response playbooks)
+**Primary**: Wazuh (rule authoring) + PULSAR (M365 detections) + Shuffle (response playbooks)
 **Augmentation**: Zeek + Suricata (network detection rules)
 ---
@@ -423,7 +479,7 @@ Our current stack covers cloud posture, AD security, GRC, M365 configuration, an
 | Purple Knight | 30 minutes | None | Low | Medium (AD scan) |
 | CISO Assistant | 1 day | Docker host or VM | Low | Low-Medium (compliance data) |
 | ASTRAL | 2 hours | SaaS or client-hosted | Low | High (M365 configuration) |
-| AOC | 4 hours | SaaS or client-hosted | Medium | High (audit logs, identity data) |
+| PULSAR | 4 hours | SaaS or client-hosted | Medium | High (audit logs, identity data) |
 | CAExporter | 30 minutes | None (runs from PowerShell) | Low | Low (read-only CA policy export) |
 | Elysium | 1–2 hours | Dedicated secure host (on-premises) | Medium | High (domain password hashes — stays on-prem) |
 | macOS_IntuneManagement | 1 hour | None (PowerShell 7+) | Low | Medium (Intune policy data) |
@@ -463,7 +519,7 @@ Beyond the core stack, these tools address specific niches that arise in sophist
 | **What it does** | Open-source cross-platform adversary simulation and command-and-control (C2) framework. Replaces Cobalt Strike for red team engagements at zero licensing cost. |
 | **Why we use it** | Cobalt Strike costs €30,000+/year and is fingerprinted by most EDR. Sliver is free, actively maintained by Bishop Fox, and supports DNS, HTTPS, mutual TLS, and WireGuard C2 channels. It generates implants for Windows, macOS, and Linux. |
 | **When to deploy** | Module 10 (Red Team & Validation); purple team exercises; EDR efficacy testing |
-| **Integration** | Red team activity detected by Wazuh + Sysmon feeds into TheHive cases; AOC correlates any M365 session anomalies with red team timing |
+| **Integration** | Red team activity detected by Wazuh + Sysmon feeds into TheHive cases; PULSAR correlates any M365 session anomalies with red team timing |
 **The conversation**:
@@ -502,7 +558,7 @@ Beyond the core stack, these tools address specific niches that arise in sophist
 | **What it does** | Runtime security detection for containers, Kubernetes, and Linux hosts. Uses system call monitoring to detect anomalous behaviour: unexpected outbound connections, privileged container escapes, sensitive file access. |
 | **Why we use it** | Syft + Grype find vulnerable packages at build time. Falco detects exploitation at runtime. Without Falco, a container with a CVE can be exploited silently. |
 | **When to deploy** | Any client with Kubernetes or containerised workloads; Module 9 (Organisational Resilience) for CI/CD security gates |
-| **Integration** | Falco alerts feed into Wazuh or directly to TheHive; AOC correlates container events with M365 identity context for supply-chain attack detection |
+| **Integration** | Falco alerts feed into Wazuh or directly to TheHive; PULSAR correlates container events with M365 identity context for supply-chain attack detection |
 ---
@@ -568,7 +624,7 @@ Beyond the core stack, these tools address specific niches that arise in sophist
 | **What it does** | Scans Git repositories for hardcoded secrets: API keys, passwords, tokens, private keys. Supports pre-commit hooks and CI/CD integration. |
 | **Why we use it** | The most common cloud breach vector is not zero-day exploitation. It is a developer committing an AWS access key to GitHub. GitLeaks finds it before the commit—or scans historical commits for existing leakage. |
 | **When to deploy** | Module 9 (Organisational Resilience); DevSecOps engagements; any client with active software development |
-| **Integration** | CI/CD pipeline integration; findings fed into CISO Assistant for evidence tracking; AOC monitors for any M365 session using leaked credentials |
+| **Integration** | CI/CD pipeline integration; findings fed into CISO Assistant for evidence tracking; PULSAR monitors for any M365 session using leaked credentials |
 ---
@@ -592,7 +648,7 @@ Beyond the core stack, these tools address specific niches that arise in sophist
 | **What it does** | Open-source phishing simulation framework. Build campaigns, track click rates, capture credentials (in training mode), and measure user susceptibility over time. |
 | **Why we use it** | Commercial phishing platforms cost €5-15/user/year. GoPhish is free, self-hosted, and produces equivalent metrics. It integrates with LDAP for realistic email targeting. |
 | **When to deploy** | Module 3 (M365 Security Hardening); security awareness programmes; post-incident user training |
-| **Integration** | Results feed into CISO Assistant for training evidence; high-risk users flagged in AOC for enhanced monitoring |
+| **Integration** | Results feed into CISO Assistant for training evidence; high-risk users flagged in PULSAR for enhanced monitoring |
 ---
@@ -682,7 +738,7 @@ These are partnerships we invest in deeply. We train the team, build integration
 | **What they provide** | Managed EDR for SMBs and mid-market: 24/7 threat hunting, incident response, ransomware rollback. Agent deployment via RMM or Intune. |
 | **Why we partner** | Our open-source EDR stack (Wazuh + Sysmon) is excellent for clients who want sovereignty. But it requires us to tune rules, investigate alerts, and respond to incidents. Huntress provides the 24/7 layer we cannot staff at 5-20 people. We bring the strategic context; they bring the night shift. |
 | **Client archetype** | E3 clients without Defender P2; municipalities; professional services; any client who needs EDR but cannot justify CrowdStrike or SentinelOne |
-| **Engagement model** | We deploy and configure Huntress as part of Module 1 or 3. We retain the relationship and add our own detection rules via AOC for M365 context. Huntress handles the endpoint. We handle the narrative. |
+| **Engagement model** | We deploy and configure Huntress as part of Module 1 or 3. We retain the relationship and add our own detection rules via PULSAR for M365 context. Huntress handles the endpoint. We handle the narrative. |
 | **Financial model** | Per-endpoint licensing with partner margin. We bill labour for deployment, tuning, and quarterly reviews. The recurring license revenue funds our growth without proportional labour increase. |
 | **When NOT to use** | Clients who require air-gapped networks; clients with sovereign-data mandates that prohibit third-party agent telemetry; clients who explicitly want to own their detection logic (then we deploy Wazuh) |
@@ -748,7 +804,7 @@ These are tools we purchase for our own team to deliver services more effectivel
 | **Burp Suite Professional** | Web application penetration testing | The industry standard. Community edition is too limited for professional engagements. |
 | **Cobalt Strike** (or **Sliver** for budget-conscious) | Red team C2 and adversary simulation | When clients specifically require Cobalt Strike for insurance or compliance validation. Sliver is our default; Cobalt Strike is the enterprise alternative. |
 | **Offensive Security / SANS training** | Consultant skill development | Our team must maintain current certifications. Training is a cost of doing business, not a partnership. |
-| **Microsoft Action Pack / CSP** | Internal M365 licensing for testing | We need sandbox tenants to test ASTRAL and AOC before client deployment. Microsoft's partner programme provides this at low cost. |
+| **Microsoft Action Pack / CSP** | Internal M365 licensing for testing | We need sandbox tenants to test ASTRAL and PULSAR before client deployment. Microsoft's partner programme provides this at low cost. |
 ---
@@ -757,9 +813,9 @@ These are tools we purchase for our own team to deliver services more effectivel
 | Category | Example | Why We Refuse |
 |----------|---------|---------------|
 | **All-in-one security platforms** | CrowdStrike, Palo Alto, SentinelOne | They replace our entire stack with a black box. We become a reseller, not a consultant. The client loses sovereignty. We lose differentiation. |
-| **Generic SIEM** | Splunk, Datadog, Elastic Cloud | Wazuh + TheHive + AOC covers 90% of client needs. Splunk requires a €100K+ commitment and a dedicated engineer. We refer complex SIEM needs to specialists rather than pretending to be one. |
+| **Generic SIEM** | Splunk, Datadog, Elastic Cloud | Wazuh + TheHive + PULSAR covers 90% of client needs. Splunk requires a €100K+ commitment and a dedicated engineer. We refer complex SIEM needs to specialists rather than pretending to be one. |
 | **AI security startups** | Any vendor claiming "AI-powered" threat detection with no transparent model | Our AI strategy is sovereign: Azure OpenAI bridge and local LLMs. We do not resell opaque AI tools that we cannot explain to a board. |
-| **M365 management competitors** | CoreView, AdminDroid, Quest | ASTRAL and AOC are our proprietary differentiators. Partnering here would undermine our own product investment. |
+| **M365 management competitors** | CoreView, AdminDroid, Quest | ASTRAL and PULSAR are our proprietary differentiators. Partnering here would undermine our own product investment. |
 ---
@@ -775,7 +831,7 @@ These are tools we purchase for our own team to deliver services more effectivel
 - Tier 1: Huntress + Thinkst + Tenable (full enterprise VM partnership)
 - Tier 2: Delinea, KnowBe4, Veeam, Proofpoint (active partner status, trained engineers)
 - Tier 3: Cobalt Strike license for red team; additional SANS/training budget
- ASTRAL and AOC monetised as SaaS products with their own revenue stream
+- ASTRAL and PULSAR monetised as SaaS products with their own revenue stream
 **The rule**: Every commercial partnership must either (a) provide a capability we cannot build, (b) generate recurring revenue without proportional labour, or (c) satisfy a compliance requirement that open-source cannot meet. If it does none of these, we decline.
@@ -802,11 +858,11 @@ These are tools we purchase for our own team to deliver services more effectivel
 | Document | Integration |
 |----------|-------------|
 | [Zero-Budget Vulnerability Discovery](zero-budget-vulnerability-discovery.md) | Syft + Grype container pipeline; osquery endpoint discovery; Prowler cloud-native discovery; GitLeaks secrets scanning |
-| [AI-Assisted TVM Blueprint](ai-assisted-tvm.md) | All discovery tools feed the AI prioritisation engine; AOC provides insider-threat context; OpenCTI enriches with threat actor context |
+| [AI-Assisted TVM Blueprint](ai-assisted-tvm.md) | All discovery tools feed the AI prioritisation engine; PULSAR provides insider-threat context; OpenCTI enriches with threat actor context |
 | [Perimeter Scanning Capability](perimeter-scanning-capability.md) | Nuclei + Amass + Naabu form the open-source active scanning layer; Prowler covers cloud perimeter; CertStream monitors for new subdomains |
 | [Osquery: The Sovereign Discovery Platform](osquery-custom-platform.md) | osquery + FleetDM is the endpoint discovery layer; Wazuh extends to behavioural detection; Velociraptor adds forensic hunting |
-| [Blue/Purple Team Foundation](../core/blue-purple-team-foundation.md) | Wazuh + TheHive + Cortex + Shuffle form the open-source SOC stack; AOC adds M365-specific detection; Sliver enables adversary simulation; OpenCanary provides deception |
+| [Blue/Purple Team Foundation](../core/blue-purple-team-foundation.md) | Wazuh + TheHive + Cortex + Shuffle form the open-source SOC stack; PULSAR adds M365-specific detection; Sliver enables adversary simulation; OpenCanary provides deception |
-| [Retained Capability](../core/retained-capability.md) | Detection Engineering retained capability is built on Wazuh + AOC + Shuffle; Threat Context on TheHive + Cortex + OpenCTI |
+| [Retained Capability](../core/retained-capability.md) | Detection Engineering retained capability is built on Wazuh + PULSAR + Shuffle; Threat Context on TheHive + Cortex + OpenCTI |
 | [Modular Engagements](../core/modular-engagements.md) | Each module has a recommended tool pairing in the matrix above; partnership doctrine defines when commercial tools supplement open-source |
 | [AD and Endpoint Hardening](ad-endpoint-hardening.md) | BloodHound maps attack paths; Purple Knight / Forest Druid score AD security; Velociraptor hunts for indicators of compromise on domain controllers |
 | [Business Case Template](business-case-template.md) | Partnership financial models (Huntress recurring, Thinkst margin, Tenable compliance) feed into client ROI calculations |
@@ -38,7 +38,7 @@ IG1 is the **safeguards that every organization should implement to protect agai
 | Sovereignty (Days 60-90) | Ensure proprietary AI data never leaves perimeter | Local AI infrastructure |
 | Antifragility (Days 90-180) | Automated data loss prevention | Existing CASB or DLP |
-**Antifragile Angle**: Data protection is not encryption at rest. It is **ensuring your proprietary signal does not train your competitor's model**. Local AI is a data protection control.
+**Antifragile Angle**: Data protection is not encryption at rest. It is **ensuring your proprietary operational data stays under your control, with audit rights and data residency you can verify**. Local or sovereign AI is a data protection control.
 ### Control 4: Secure Configuration of Enterprise Assets and Software
@@ -279,6 +279,53 @@ See [M365 E3 Hardening](../playbooks/m365-e3-hardening.md) for tactical hardenin
 ---
 ## The Controlled Burn Adaptation: When Greenfield Is Not an Option
 The antifragile framework holds that organisations should build toward the ability to deploy greenfield — rebuild from scratch, on clean infrastructure, from version-controlled configuration. This is the ultimate expression of structural decoupling: if you can rebuild the environment, no adversary and no vendor holds you hostage.
 Power utilities, water suppliers, and telecom network operators frequently view this principle as inapplicable. The grid does not go dark for a rebuild exercise. Protection relays cannot be factory-reset during a fault. OT systems operate under safety cases that require regulatory approval for any configuration change. The controlled burn, taken literally, cannot happen.
 This is correct. It is also not the end of the conversation.
 **The goal of greenfield capability is to eliminate inherited compromise and return to a known-good operational state.** For IT environments, the method is rebuild. For OT/NT environments, the method is different — but the goal is identical, and it is achievable. The absence of a literal rebuild path does not justify the absence of a recovery plan.
 ### The OT-Adapted Greenfield Stack
 **Layer 1: IT greenfield protects OT.** The corporate IT environment, M365 tenant, SCADA servers, historian, engineering workstations, and HMI layer can almost always be made greenfield-capable even when OT hardware cannot. An adversary who compromises the IT layer and finds a clean rebuild path loses their persistence and pivot path without a single OT device being touched. IT greenfield is the outer perimeter of an OT environment that cannot be rebuilt itself. This is the first investment.
 **Layer 2: OT configuration as code.** PLC logic, IED settings files, protection relay configuration archives, SCADA database snapshots, DCS export files — all of these belong in version-controlled backups with integrity verification. The ability to restore a known-good configuration to existing hardware is the OT equivalent of greenfield: the hardware remains, but the software state is wiped and rebuilt from a verified baseline. This is not a backup exercise. It is a discipline — with the same rigour that ASTRAL applies to M365 configuration, applied to OT configuration archives. Every piece of OT configuration that exists only in the device and nowhere else is a single point of failure.
 **Layer 3: Manual operation as the fallback layer.** The ability to operate critical systems without the automation layer is, in practice, the ability to drop the compromised layer and continue service. A power utility that can maintain 70–80% of service from manual procedures during a SCADA compromise has a fundamentally different risk profile than one that cannot. Manual override procedures must be:
 - Documented in detail, not just referenced in an emergency plan
 - Tested under realistic conditions, not just reviewed in a tabletop
 - Known by currently assigned operations staff, not just veterans who may have left
 - Validated at least annually — capability that is not practised does not exist when it is needed
 **Layer 4: Compartmentalisation as partial burn.** OT environments are typically sectionable. Grid islanding, substation isolation, plant-level control separation, and control centre failover allow the operator to sacrifice and rebuild one section while maintaining critical service in others. This is the OT equivalent of the controlled burn: localised rather than total, sequential rather than simultaneous, but governed by the same principle — designed-in ability to contain, recover, and restore without waiting for a complete environment to be clean.
 **Layer 5: Planned long-cycle refresh.** OT systems have 20–40 year operational lifetimes, but those lifetimes should be a programme, not an accident. Organisations without a documented OT refresh schedule — with component-by-component replacement milestones, firmware escrow requirements, spare parts inventory targets, and vendor succession planning — are not avoiding greenfield. They are deferring it until a crisis forces it under the worst possible conditions: compromised hardware, unavailable vendors, missing documentation, and no tested procedures.
 ### The Acceptance Statement
 Some OT components in critical infrastructure genuinely cannot be replaced on any timescale that security planning can influence. Legacy protection relays on operational transmission lines. Nuclear instrumentation systems under active safety cases. Water treatment chemical dosing controllers that predate the organisation's current IT function.
 For these systems, the correct position is explicit acceptance, not avoidance:
 1. **Name them.** Identify specifically which systems are outside the rebuild envelope and why.
 2. **Isolate them.** The isolation must be proportional to the acknowledged unrepairability. A system that cannot be patched, cannot be replaced, and cannot be rebuilt must be surrounded by compensating controls so thorough that its compromise cannot propagate.
 3. **Monitor them obsessively.** Configuration integrity monitoring, network traffic baselining, and anomaly detection for these specific systems — because when you cannot fix the asset, detection and containment are the only remaining defences.
 4. **Plan their eventual replacement.** "This system cannot be replaced in the current operational context" is acceptable. "This system will never be replaced" is not a security posture — it is a deferred decision that will be made under worse conditions later.
 The acceptance statement is not a sign of weakness. It is the honest foundation of a credible security programme. Regulators, insurers, and incident responders all prefer an organisation that knows exactly where its limits are and has compensating controls in place over one that claims no limits and has no plan.
 ### The OT Greenfield Test
 *"If our IT and SCADA layers were fully compromised tonight: could we maintain critical service from manual procedures within 4 hours? Rebuild the IT layer from clean baselines within 48 hours? Restore full automated operation from verified OT configuration backups within two weeks? And have we actually tested each of these in the past 12 months?"*
 If any answer is no, the gap is in manual procedures, IT rebuild capability, OT configuration management, or test cadence — not in the impossibility of the OT environment itself.
 ---
 ## Evidence Package for Regulators
 | Requirement | Evidence from Antifragile Program |
Author	SHA1	Message	Date
Claude Sonnet 4.6	3062e435ca	chore: Full consistency scan — AOC->PULSAR, fix training-data claims, fix 90% claim AOC -> PULSAR across 10 files (engagement-model, retained-capability, modular-engagements, blue-purple-team-foundation, about-cqre, about-cqre-cs, consultant-field-guide, ai-assisted-tvm, m365-e3-hardening, sovereign-tool-stack, risk-register-example). Training-data framing corrected in: - executive-summary.md: opening paragraph and risk table - README.md: 90% solution claim -> 30-60% in 180 days - modular-engagements.md: public API data use claim - cis-controls-mapping.md: data protection framing - antifragile-risk-register.md: risk entry softened to accurate framing - azure-openai-sovereignty-bridge.md: consumer vs enterprise API distinction Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>	2026-06-05 07:05:13 +00:00
Claude Sonnet 4.6	bcebf8ebb3	feat: Add critical infrastructure adaptation for Rule 5 (greenfield) move-fast-and-fix-things.md: 'The Critical Infrastructure Adaptation' section in Rule 5. OT/NT environments where full greenfield is impossible. Five-layer adapted stack: IT greenfield protects OT, OT config as code, manual operation as fallback, compartmentalisation as partial burn, long-cycle planned refresh. OT greenfield test with 4h/48h/2w targets. vertical-power-utilities.md: New 'The Controlled Burn Adaptation' section. Full treatment of when greenfield is not an option. Five-layer OT-adapted stack. Explicit acceptance statement framework for genuinely irreplaceable OT components (name, isolate, monitor, plan replacement). The OT greenfield test. Reference back to Rule 5. Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>	2026-06-05 06:58:07 +00:00
Claude Sonnet 4.6	a337af7ddf	feat: Add housekeeping stream and greenfield capability as Rules 4 and 5 move-fast-and-fix-things.md: Three Rules -> Five Rules. Rule 4: Housekeeping as a permanent stream (named owner, cadence, queue). Rule 5: Greenfield capability as standard operational activity every 5 years. Updated pillar mapping table. antifragile-manifest.md: Pillar 1 Antifragile Moves: greenfield capability as the ultimate expression of structural decoupling. Controlled burn framing. Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>	2026-06-05 06:53:31 +00:00
Claude Sonnet 4.6	6e86f0844e	fix: Correct speed claim and add infinite vulnerability surface section Speed Is a Security Control: Replace overconfident '90% solution today' with honest target: 30-60% in 180 days. Real comparison is progress vs. the 0% that stays when waiting for the perfect plan. New section 'When the Vulnerability Surface Is Effectively Infinite': AI-scale vulnerability discovery (e.g. Project Glasswing) does not call for AI-assisted patching. It calls for architecture that makes most vulnerabilities matter less: kill chain prioritisation, blast radius limitation, assume-breach posture, known-good baseline. Architecture beats velocity in the vulnerability race. Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>	2026-06-05 06:44:32 +00:00
Claude Sonnet 4.6	46a1f7e005	feat: Add AI Mythos counter-narrative; rewrite ai-sovereignty-framework move-fast-and-fix-things.md: 'The AI Distraction' section. Multiplier principle, CIS IG1 sequencing, client redirect script. antifragile-manifest.md: Pillar sequencing note (Pillar 4 after 1-3). consultant-field-guide.md: Mistake #11 + AOC->PULSAR rename. ai-sovereignty-framework.md: Full rewrite with regulatory framing, sovereignty spectrum, updated objections, CQRE product examples. Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>	2026-06-05 05:19:21 +00:00
Claude Sonnet 4.6	48f891db36	feat: Fix review issues and integrate ASTRAL, PULSAR, AURORA product suite Framework fixes: - antifragile-manifest.md: Correct AI Sovereignty pillar (data residency/audit rights framing); add consultant note - executive-summary.md: Same AI sovereignty correction; add EU Regulatory Context (NIS2, DORA, GDPR) - README.md: Add Brownhat brand explanation; expand Standards Alignment with NIS2/DORA/GDPR - core/about-cqre.md: Prominent TEMPLATE WARNING banner to prevent accidental sharing - index.md: Add CQRE Product Suite; renumber consultant nav 1-26 consistently New: playbooks/cqre-product-suite.md - ASTRAL/PULSAR/AURORA product reference with antifragile pillar alignment, regulatory mapping, deployment prerequisites, and objection handling Updated: sovereign-tool-stack.md - ASTRAL updated to GitHub product spec; AOC replaced with PULSAR; AURORA section added Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>	2026-06-05 04:59:20 +00:00