The capstone assembles the whole curriculum into one system: a troubleshooting assistant that takes an error code or pasted log and returns cause, fix and verification. Architecture: USER → AI Assistant → {Error Database, RAG} → AI Reasoning → {Cause, Fix, Commands} → Verification. It understands Intune, Autopilot, Win32 app, PowerShell, Windows, WDAC, firewall, proxy, Entra ID, Conditional Access, BitLocker and Windows Update errors — and CloudEngineerHub’s own /rca Logs Analyzer is a live example of exactly this concept.
This capstone assembles the entire curriculum into one system: a troubleshooting assistant that takes an error code or pasted log and returns cause, fix and verification. The architecture: USER → AI Assistant → {Error Database, RAG} → AI Reasoning → {Cause, Fix, Commands} → Verification. The error database is deterministic — curated rules mapping codes to meaning, causes and fixes (Intune 0x87D1xxxx policy errors, Autopilot 0x800705B4, BitLocker 0x8031xxxx, WDAC Event 3077, WinHTTP 12002-12175, AADSTS codes). RAG adds your internal documentation. The reasoning stage weighs both, asks context questions when evidence is thin, and emits a structured diagnosis. Crucially, it understands the error families IT actually fights: Intune errors, Autopilot errors, Win32 app errors, PowerShell errors, Windows errors, WDAC events, firewall events, proxy errors, Entra ID errors, Conditional Access, BitLocker and Windows Update.
Diagnosis is where IT time disappears — and where AI gives leverage with verifiable output. A rule-based core gives determinism and auditability; the AI layer adds language understanding so “ESP hangs at account setup” finds the right rule without an exact code. This is not hypothetical: CloudEngineerHub’s own Logs Analyzer at /rca is a live example of this exact concept — a 260-rule error library, staged analysis (detect → match → context → reasoning) and AI narration with a deterministic fallback. Build this capstone and you have a portfolio artifact demonstrating embeddings (13), RAG (14), API engineering (15), agent-style orchestration (16), tool calling (17), context management (18) and security hardening (19) in one deployable system.
Staged pipeline, each stage testable. 1) Detect: regex extractors pull HRESULTs (0x87D1041C), AADSTS codes, WinHTTP codes (12xxx) and event IDs from free text, with context guards — “Event 3077” is only WDAC when WDAC/AppLocker words are nearby. 2) Match: exact rule lookup first (deterministic), then vector search for symptom phrases — with explicit trap rules (“0x0 means success, not an error”; “0x8007xxxx is a generic Windows layer, not automatically Intune”) and clarifying questions when confidence is low. 3) Reason: the LLM receives the matched rules plus retrieved chunks and produces a structured diagnosis JSON {cause, fix, commands[], verification} at temperature 0 with JSON-mode output. 4) Verify: every diagnosis ends with how to confirm the fix — the exact log line to expect or the PowerShell check to run. Ship with rate limiting, token streaming, a rule-based fallback when the AI times out, and full logging of detection → match → reasoning.
USER
↓
AI Assistant
├────────────┐
Error Database RAG
└──────┬─────────┘
↓
AI Reasoning
↓
Cause · Fix · Commands
↓
VerificationThe live reference is on this site: CloudEngineerHub’s Logs Analyzer (/rca) — paste 0x87D1041C and it detects the HRESULT, matches the Win32 app detection-failure rule (product, component, causes, step-by-step fix, verification commands, related codes), streams expert reasoning, and offers a 0x0/symptom path with context questions when no code is present. The same shape scales to an internal enterprise assistant: swap the public rule set for your runbooks, point RAG at your SharePoint or Confluence, and connect tool calls to your ticketing system — and you have the assistant your L1 team consults before escalating.
Start with 50-100 rules for your highest-volume errors: code, product, component, meaning, common causes, step-by-step fix, verification, PowerShell commands, log locations, related codes, severity. Store in a database, not markdown — it must be queryable.
Regex extractors for 8-hex HRESULTs, AADSTS-, WinHTTP- (12xxx) patterns and event IDs, with context guards (treat “Event 3077” as WDAC only when WDAC/AppLocker words are near). Encode the traps: 0x0 = success; 0x8007xxxx is a generic Win32 layer, not automatically Intune.
Index your documentation and past incident write-ups. When no exact code matches, embed the symptom text (“company portal stuck at account setup”) and retrieve the nearest rules and docs — topic 13/14 built exactly these muscles.
Prompt: “Given matched rules and retrieved context, output strict JSON {rootCause, confidence, fix[], commands[], verification}. If evidence is insufficient, output clarifying questions instead of guessing.” temperature 0, bounded max_tokens, JSON-mode/structured output on.
No diagnosis ships without a verification step: the exact expected log line, event, or Get- cmdlet output that proves the fix worked. This is what makes the assistant trustworthy to senior engineers.
Rate limit per user (e.g. 20 analyses/5 min), stream stages so users see progress, fall back to the rule-only path when the AI times out, log every stage, and add a feedback loop (thumbs up/down) that feeds new rules into the database.
https://cloudengineerhub.com/rca — paste 0x87D1041C and watch the rule library + AI reasoning in action.The capstone concentrates every risk from topic 19. Inputs are untrusted — prompt injection can arrive inside pasted logs; outputs include commands that admins may run, so sanitize and review command suggestions and mark anything destructive; the tool layer stays least-privilege and read-only unless gated by approval; prompts and analyses are logged for audit but redacted for secrets; and the service runs under its own identity with rate limits so it can become neither a data-exfiltration path nor a DoS vector against your own APIs. An assistant that touches production must fail closed: no match and low confidence means “ask clarifying questions”, never a confident guess.
Because determinism and language understanding fail differently. Rules are auditable, versioned and always correct for known codes; they catch exact matches instantly. RAG catches paraphrases and internal documentation. The LLM alone is confident but unverifiable — it will invent plausible causes for codes it has never seen. The hybrid gives known-answer precision plus natural-language recall, and a clear fallback path.
Build a test set of real past incidents — input text plus the verified root cause — and measure: detection rate, top-1 rule accuracy, faithfulness of the AI reasoning to the matched rules (no invented facts), and whether the verification step would actually have confirmed the fix. Also test the trap inputs: 0x0, unknown codes, mixed logs and injected instructions. Regression-test this set on every rule change.
Rate limiting and abuse protection, streaming with staged progress, deterministic fallbacks when AI is down, structured and validated outputs, full stage logging for debugging and audit, secrets management, feedback collection, and documented failure behavior — the assistant that says “not confident, here are clarifying questions” instead of hallucinating. A demo answers once on camera; production answers every day, including when components fail.
Build the capstone end to end at small scale: 25 rules (Intune, Autopilot, BitLocker, Entra ID), regex detection, a vector index over 5 documents, a reasoning stage with structured JSON output, and a verification line per diagnosis. Then paste these five inputs and check every stage: “0x87D1041C”, “0x0”, “ESP stuck at account setup”, “WDAC Event 3077 and 0x800704EC”, “help the laptop is broken”.
CloudEngineerHub’s Logs Analyzer at https://cloudengineerhub.com/rca is a live implementation of this architecture: a 260-rule error library spanning Intune, Autopilot, Entra ID, Windows, security events and network codes, staged analysis with context questions, and AI reasoning with a deterministic fallback — paste any error code and compare its output to the design in this topic.
Far fewer than you think: the 50-100 rules covering your top recurring errors deliver most of the value, because real-world error volume follows a steep power law. Start with your helpdesk’s last quarter of tickets, take the top codes, and let feedback drive the roadmap.
Yes — with topic 17’s tool calling and topic 19’s guardrails: read-only lookups auto-approved, write actions (ticket creation, policy change) behind human approval. Start diagnosis-only; add actions once the diagnosis accuracy is proven on your test set.