Home SOC Lab
Active Directory hardening, CIS-aligned Group Policy, advanced audit policy, Sigma detections, Wazuh rules, incident triage, and compliance mapping.
These are not decorative dashboard promises. They are public GitHub repositories with runnable code, real Markdown, tests, incident writeups, and the standards each design decision is meant to satisfy.
Start with the problem statement, inspect the implementation, read the philosophy behind the design, then check the standards or operational practice it references. Synthetic data is labeled. Private client systems are never presented as public proof.
What was broken, risky, slow, or hard to audit?
Where are the code, manifests, tests, and runnable instructions?
Why this architecture, boundary, control, or tradeoff?
Active Directory hardening, CIS-aligned Group Policy, advanced audit policy, Sigma detections, Wazuh rules, incident triage, and compliance mapping.
A full-stack security findings demo that normalizes AWS, Azure, endpoint, and GitHub findings, applies explainable risk scoring, maps controls, and exports evidence.
A local kind reconstruction of a scheduling stampede, with good and broken manifests, probes, resource controls, PDB, HPA, observability, CI, and recovery runbook.
Lead intake, explainable prioritization, follow-up drafting, idempotent ingestion, and an explicit owner approval before outbound action.
Checkpointed planning, artifact creation, bounded execution, recovery states, and a fail-closed stop before external action. The repository also documents the MCP host boundary: namespaced tools, allowlists, schema filtering, and policy-aware routing.
Local source-grounded retrieval with matter boundaries, citations, explicit no-answer behavior, and a clear not-legal-advice boundary.
The repositories use standards as reasoning tools, not as decorative badges. The linked docs show exactly where each standard enters the design.
These repositories use synthetic data, local labs, or sanitized reconstructions. They demonstrate how we think and build. Credentials, private dashboards, customer records, and production access stay out of public proof.
Inspect the source ↗A public repository can prove that code, documentation, tests, and reasoning exist. It does not by itself prove a production deployment, a client outcome, or compliance certification. Those claims require separate evidence and a scoped engagement.
Source code, Markdown rationale, local execution paths, tests, manifests, and standards references.
Synthetic data, local clusters, reconstructed incidents, drafts, and known implementation limits.
Production deployment, client-specific controls, confidential evidence, and measured outcomes.
These repositories are sanitized public templates. They show the same operating discipline in a household context while keeping real family data, devices, addresses, and infrastructure private.
Service health, backup freshness, recovery procedures, local model availability, and supervision patterns.
Inspect the health-check code ↗Household questions, reminders, drafting, and approval before purchases, messages, deletion, or security changes.
Inspect the approval policy ↗Markdown-first manuals, warranties, maintenance procedures, provenance, sensitivity labels, and review dates. Optional screenshot-aware retrieval preserves diagrams and scanned records. Source hashes flag stale answers for review instead of silently publishing changed guidance; see PixelRAG ↗ for the visual retrieval reference.
Read the record template ↗Role-based training, safe-use patterns, workflow redesign, verification, and manager feedback loops. The reference path includes Microsoft AI for Beginners ↗, paired with local policy, approval controls, and a bounded task-decomposition lesson ↗.
Read the training module ↗Creative briefs, constraints, review state, accessibility metadata, provenance, and approval before publication.
Inspect the approval code ↗Focused implementation for small businesses, defined workstreams for mid-market teams, and scoped architecture or engineering support for larger organizations.
Choose a repository, bring the business problem, and we can map the smallest defensible next build.