Skip to content

Validation Model

The blueprint uses functional gates. No phase is complete until its gate is passed.

Validation in this repository is lab first. A documented operational method is not considered approved until the real lab proves the intended first deployment model works and the evidence is captured.

Validation must also be repeatable. A single ambiguous success is not enough to publish a method as a standard.

Validation states

State Meaning
PASS Expected result achieved and evidenced
FAIL Expected result not achieved
BLOCKED Dependency missing or earlier phase incomplete

Validation sequence

Every implementation validation should follow this order:

  1. Confirm prerequisites.
  2. Verify the current live state.
  3. Execute the change or test in the lab against the same required day-zero design.
  4. Validate the expected outcome.
  5. Capture evidence.
  6. Record the result as PASS, FAIL, or BLOCKED.

Gate format

Each gate must include:

  • What is being validated
  • How it is validated
  • Expected outcome
  • Evidence to capture
  • Blocking impact if it fails

Every implementation runbook must also include a pre-execution verification step for current state. A gate is not valid if the operator skipped confirming what already exists before running changes.

If a Windows procedure uses reusable PowerShell plus a transport such as QGA, WinRM, console, or guest tooling, validation must prove both of these points:

  • the configuration logic produced the expected result
  • the documented execution path worked as written in the validated lab

Design standards such as naming, OU structure, or authoring rules do not pass through a runbook gate by themselves. They become operationally significant only when a lab-validated runbook implements them.

Reducing endpoint count for lab practicality is acceptable. Reducing required day-zero infrastructure roles is not.

Design versus implementation

  • Standards are reviewed for coherence, consistency, and future fit.
  • Runbooks are validated by execution against the lab and by captured evidence.

Do not treat a design decision as operationally approved until the corresponding implementation path has passed its gate.

Mandatory gate categories

  • Network reachability
  • Identity and name resolution
  • Addressing and DHCP behavior
  • Security policy application
  • Resource access
  • Segmentation and isolation
  • Internet egress
  • Recovery point availability