Maintaining Model Alignment Through Structured Workspaces and Progressive Refinement

What's up all. This is an article based on the SOC Lab I am building. I was thinking about adding some visuals, but before I do I wanted to post it here to see what people think. Let me know if any sections are hard to understand or written poorly. Thanks!

# How to Build Anything With AI Without Losing Control of the Project

Most AI-assisted projects don't fail because the AI can't do the work. They fail because nobody told it when to stop, what to check, or what "done" looks like. The model drifts. Scope creeps. You end up with a pile of generated output and no clear path from where you are to where you meant to be.

The fix isn't less AI. It's more structure.

I built a workflow to solve this and tested it on a home SOC lab — key management, SIEM deployment, Windows attack surface, network segmentation, firewall hardening — with an AI agent executing the bulk of the build across multiple phases. The AI rarely went off-script. Not because it couldn't, but because the structure didn't leave room for it.

The SOC lab was the proof case. The workflow is the product. You can plug any project into it and get the same result: sequential, verifiable, drift-resistant execution.

Here's how it works, stage by stage.

---

## Stage 1 — Project Initiation

Before anything gets built, you need three things: a clear goal, an organized workspace, and a defined scope.

**Define the goal in one paragraph.** Not a feature list — a statement of what success looks like and why this project matters right now. This becomes your project charter. Every future decision filters through it.

**Set up your workspace.** A clean folder structure where every file has an obvious home. Project docs, reference materials, build logs, and configuration files each get their own location. This sounds basic, but it's what prevents the AI from scattering output across your filesystem and losing track of state.

**Identify your reference documents.** What standards, vendor docs, or specifications govern this work? Collect them before you start building. Pin the version — not "Splunk docs" but "Splunk Enterprise 10.4.0 install guide." The AI works from these instead of its training data, which may be outdated or wrong.

> **SOC lab example:** The charter defined the goal — become a hire-ready SOC analyst with a portfolio proving infrastructure competence, daily analyst workflow execution, and AI-augmented analysis. The workspace was a single build manual (project spec + walkthrough in one file). Reference docs were pinned per phase: NIST SP 800-53 Rev 5, CIS Benchmarks for Ubuntu and Docker, MITRE ATT&CK, and version-specific vendor documentation for every tool in the stack.

---

## Stage 2 — Project Planning (Progressive Refinement)

This is where most people over-plan and most AI workflows under-plan. The solution is progressive refinement — plan the skeleton in full, but only polish the next phase.

**Break the project into sequential phases.** Each phase is a major milestone that can be independently verified. Order them by dependency — what must exist before the next thing can be built on top of it.

**Rough-sketch every phase.** Each one gets a one-line goal, a list of likely components, and a general sense of what the start and finish conditions look like. This is deliberately rough. You know these will change once you start building, because every completed phase teaches you something about what comes next.

**Polish only Phase 1.** Write detailed steps, pin exact reference docs, define precise gate checklists. This is the phase you're about to execute, so it gets full attention. Everything after it stays rough on purpose.

**Why not plan everything in detail upfront?** Because it wastes time. During the SOC lab build, the original Phase 2 planned for a cloud deployment on Google Cloud using Splunk Attack Range automation. During planning, we discovered Attack Range v5 had removed local deployment mode entirely. Phase 2 was restructured to a manual KVM build on the local server instead, and cloud infrastructure was pushed to a later phase. If we had spent days writing detailed steps for every phase upfront, that work would have been thrown away. The rough sketch absorbed the change in minutes.

This is the core discipline: the completed phase informs the next phase. Each layer you build gives you concrete knowledge about your exact configurations, real resource constraints, and actual tool behavior — things you can't know from documentation alone. Build, learn, refine, repeat.

> **SOC lab example:** The project broke into nine phases — host hardening, key management, SIEM deployment, analyst fundamentals, cloud infrastructure, secondary SIEM, agent enrollment, adversary emulation, and portfolio assembly. Phases 3 through 9 were one-paragraph rough sketches. Phase 1 (host hardening) was fully detailed with eight numbered steps, each with prechecks and verification commands. When Phase 1 completed, Phase 2 was polished using what we learned — actual RAM availability, real disk constraints, confirmed network topology — none of which matched our initial assumptions exactly.

---

## Stage 3 — Project Execution (Stage-Gate + Verified Steps)

This is the engine. Every phase runs through the same structure, and that structure is what prevents drift.

**Gate - Start (preflight).** Before a phase begins, a checklist confirms all prerequisites are met. The previous phase is verified complete. Required access and credentials exist. Resources (disk, memory, network) are confirmed available. Reference docs for this phase are pinned. Nothing starts until every preflight item is green.

**Numbered steps with built-in verification.** Inside each phase, work is broken into steps using dotted-decimal notation (1.1, 1.2, 2.1, 2.1.1). Every step follows the same five-part shape:

- **Goal** — one sentence on what this step achieves

- **Precheck** — read-only check capturing current state before any changes

- **Action** — exactly what gets executed

- **Verification** — read-only re-check proving the change landed correctly

- **Log entry** — what happened and why, timestamped

The verification isn't bolted on at the end of the phase. It's baked into every single step. Change something, prove it worked, then move on. Every five steps (or before anything destructive), a cumulative checkpoint confirms overall state. If any check fails, work stops — no blind retries, no workarounds. Diagnose first, then decide.

This is what keeps the AI honest. It can't skip ahead because the next step's precheck catches missing state. It can't quietly fail because every change has an immediate verification. The structure is self-enforcing.

**Gate - Finish (postflight).** When all steps are complete, a finish gate runs a comprehensive checklist against the phase's exit criteria. Every deliverable is verified. A recovery snapshot is taken. Only when every postflight item is green does the next phase unlock.

> **SOC lab example:** Phase 1 (key management) had 18 steps and an 11-item finish gate. Step 5 was "first boot of the secrets manager container." The precheck confirmed the compose file and config were valid. The action started the container. The verification confirmed it was running in the expected sealed/uninitialized state. The log entry captured three mid-flight fixes that were needed (entrypoint override, environment variable addition, a capability that had been removed in the current version). Step 6 was a key ceremony requiring the human operator physically present — the AI couldn't execute it, and the structure made that explicit. The finish gate verified all 11 items: container hardening posture, network binding, audit logging, credential storage, backup automation, and recovery materials. All green before Phase 2 began.

---

## Stage 4 — Monitoring and Controlling

Structure without enforcement is just documentation. Three mechanisms keep the project on track during execution.

**Cross-cutting guardrails.** Some rules govern every phase, not just one. These sit above the phase list and apply universally:

- **Version-pinned reference docs per phase.** The AI works from specific, cited standards — not from memory. When a tool's behavior doesn't match the docs, work stops and the version is re-verified before proceeding.

- **Explicit execution authority.** The human decides and orchestrates. The AI executes and verifies. Destructive operations (deleting data, modifying credentials, changing network exposure) require fresh human approval every time — no standing permission carries across phases.

- **Access verified at every gate, not assumed.** Before claiming a task is AI-executable, the AI proves the access actually exists. If setup is needed, it happens during the gate — scoped narrowly, not granted broadly.

**Decision logging.** Every step logs what happened and why. Every pivot, workaround, and mid-flight fix is timestamped with rationale. When something breaks three phases later, you walk the log back to the exact step where state diverged instead of guessing.

**Progressive refinement checkpoints.** After each phase completes, the rough sketches for upcoming phases are reviewed against what was actually learned. Phases get reordered, restructured, or scoped differently based on real information — not predictions.

> **SOC lab example:** During Phase 0 (host hardening), the precheck for SSH configuration discovered that root login was set to "prohibit-password" (Ubuntu's default) rather than "no." This was technically secure with the root account locked, but the guardrail standard (CIS Ubuntu Benchmark) called for full disablement. The step was added to the hardening sequence, logged with the rationale, and the config was tightened — all before moving to the next step. Without the precheck/verify pattern, this gap would have been invisible until a future audit.

---

## Stage 5 — Project Closure

Each phase has its own closure (the finish gate). The overall project closes when the final phase gate is green and the deliverables match the original charter.

**What closure produces:**

- A complete decision trail — every step logged, every pivot documented, every workaround explained

- Recovery snapshots at every phase boundary — rollback to any known-good state

- Verified exit criteria — not "it seems to work" but "these specific checks passed"

- Lessons learned fed back into the workflow itself — the structure improves with each project

---

## The Takeaway

The workflow is five stages, but the core idea is simpler than that: structure the work so the AI can't drift, and verify every step so failures are caught immediately instead of three phases later.

**Progressive refinement** keeps planning efficient — you never waste time detailing phases that will change once you start building.

**Stage-Gate execution** keeps the build sequential and verifiable — nothing advances without proving the current phase delivered what it promised.

**Built-in verification** keeps the AI honest — it can't skip ahead, and it can't quietly fail.

The SOC lab was the first project through this workflow. It won't be the last. The structure works because it's not about the project — it's about the process. A home server, a SaaS deployment, an infrastructure migration, a certification study plan — anything with sequential dependencies and a need to be right, not just done.

Structure the work. Constrain the model. Verify every step. That's it.

9 comments

Maintaining Model Alignment Through Structured Workspaces and Progressive Refinement