Methodology — How AI-Orchestrated Infrastructure Works

Framework 01

Knowledge Trust Pipeline

Not all knowledge is equal. Community answers (Class C) never promote directly to execution-validated truth (Class A). Every fact must pass through an execution chain that produces measurable output before it earns trust.

Class A knowledge comes from production. A Bicep deployment that succeeded, a backup that restored, a hook that blocked. Class B comes from official vendor documentation. Class C is community knowledge: Stack Overflow, blog posts, forum threads. Class C can inform a hypothesis, but it cannot validate one.

The graveyard log captures demoted knowledge: things that were once trusted but failed under execution. This is drift detection. If your knowledge base only grows and never shrinks, you are not validating.

See the live gate log

Knowledge Trust Pipeline: Class C through B through execution to Class A, with graveyard branch for demoted knowledge

Framework 02

PreToolUse vs PostToolUse

The difference between an audit trail and actual governance is when enforcement fires. PostToolUse hooks detect violations after the write completes. PreToolUse hooks prevent the write from happening at all.

This is not a theoretical distinction. Three rounds of agentic testing with 256 assertions proved that PostToolUse-only governance creates a false sense of safety. The AI writes the file, the hook fires, it logs the violation, but the damage is done. PreToolUse fires before the tool executes. Exit code 2 blocks the operation entirely.

One line of configuration. One fundamental difference in outcome.

Read the doctrine enforcement case study

Two-path diagram: PreToolUse prevents writes (teal), PostToolUse only detects after write completes (amber)

Framework 03

Build, Validate, Explain

Build: Custom AI tooling for your specific environment. Not generic templates. Infrastructure-as-code that accounts for your naming constraints, your compliance requirements, your existing resource topology.

Validate: Pre-deploy test suites that catch silent failures. Backup coverage that claims to exist but doesn't. NSG rules that look right but leave ports exposed. The validation layer runs before production, not after an incident.

Explain: A knowledge layer so the next person can ask the platform what it does. Every decision is captured, every trade-off documented, every constraint explained. The system accumulates intelligence instead of losing it when people leave.

Three sequential tiers: Build (teal), Validate (green), Explain (blue) with connecting arrows

Framework 04

Governance Stack

Five layers, each reinforcing the others. Infrastructure at the base. CLAUDE.md rules as advisory guidance. PreToolUse hooks as deterministic enforcement. Trust-tiered knowledge as the validation backbone. Graveyard and drift detection at the top, catching what slips through.

Advisory guidance alone is not governance. The AI can ignore CLAUDE.md. It cannot ignore a hook that returns exit code 2. The stack works because each layer compensates for the weaknesses of the layer below it.

See the full AWACS OS architecture View the governance repository

Five-layer governance architecture: Infrastructure, CLAUDE.md, PreToolUse Hooks, Trust-Tiered Knowledge, Graveyard/Drift Detection

Framework 05

Compounding Session Arc

Session 1 started with no access, no documentation, and no working knowledge of the target environment. By Session 8, the system was performing live VM restores with validated rollback procedures.

The curve is not linear. Each session compounds on the knowledge, tooling, and governance established in prior sessions. Session 3's recovery rules become Session 5's deployment constraints. Session 6's observability findings feed Session 7's dashboard rebuild.

This is the thesis: disciplined AI-assisted work compounds. The ebook documents every session in detail.

Read the WDAC deployment case study Download the ebook (PDF)

Timeline from Session 1 to Session 8 showing exponential acceleration of capability