Methods · Process · Governance
A repeatable process for turning AI-assisted design work into usable training products.
The method is practical: frame the problem, govern the source, build the workflow, review against explicit criteria, validate in execution, and revise from evidence.
Frame the problem before using the model.
The work starts with the design problem, user pressure, acceptance criteria, and failure modes. AI is useful only after the operator defines what good means and what cannot drift.
Govern the source
Source truth, review gates, and traceability rules control the production system. Generated outputs stay subordinate to approved inputs until a human clears them for use.
Build the workflow
The deliverable is a usable system, not a pile of drafts: prompts, packages, templates, review aids, scripts, and runtime artifacts that reduce work under pressure.
Review against acceptance criteria
Outputs are tested against explicit standards before they reach users. Review is a production gate, not a polish step — it decides whether AI-generated content is fit for execution.
Validate in execution
The product is not finished when the documents look complete. Live facilitation reveals what structured review cannot: whether controllers can use it under real pressure.
Iterate from evidence
Post-execution evidence, not document-level opinion, drives changes. Each execution creates a record; each revision traces back to something observed.
The process is deliberately simple.
- Frame the problem: define the user, pressure, decision, constraint, and success marker.
- Govern the source: establish the approved material and reject outputs that drift from it.
- Build the tool/workflow: create reusable artifacts, scripts, templates, or packages that make the work repeatable.
- Review against acceptance criteria: test outputs against explicit standards before they reach users.
- Validate in execution: observe whether the product works under real use, not just whether the document reads well.
- Iterate from evidence: change the system when evidence justifies the change.
Every project should prove the same six things.
The public project format mirrors the method: problem, design move, system built, supporting tools, proof, and transferable skill. That keeps the top of each page concise while preserving deeper detail lower on the page.
View project proofsGovernance Layer
Decisions make the method auditable.
The decisions archive records the constraints behind the work: source truth, AI authority boundaries, controller package architecture, adjudication discipline, plain-language delivery, and evidence-driven evolution.
Review operating decisionsExplore the work
The project pages show the proof format in use. The decisions archive shows how the method was constrained, defended, and refined.