Framework stage

Exploration

Set boundaries and run a measurable pilot with foresight, review, and a named owner.

Exploration tests one bounded workflow. It is where an organization turns a plausible opportunity into evidence without treating an experiment as permission for uncontrolled use.

Recognize this stage

Your organization is in Exploration when one or more pilots exist, but results are not yet repeatable, connected to core systems, or supported by durable ownership and controls.

Entry evidence

  • a specific workflow and measurable problem are selected
  • a business owner, technical contact, and human reviewer are named
  • baseline time, cost, quality, or service measures exist
  • permitted data, prohibited data, and decision boundaries are documented
  • affected staff understand the experiment and escalation path

Work to complete

  • write the pilot objective and non-goals
  • define what AI may produce, recommend, or trigger
  • create representative test cases, including difficult exceptions
  • record model, tool, data, and configuration choices
  • compare output against the baseline and human work
  • test review effort, override paths, and failure recovery
  • gather feedback from people doing and receiving the work
  • estimate recurring cost and operational ownership

Staying in charge

The pilot remains reversible. AI output cannot silently become a consequential decision. A named reviewer can stop the workflow, trace material inputs and outputs, and explain what evidence would justify continuing.

Evidence package

Before expansion, retain:

  • the baseline and pilot results
  • accepted and rejected test cases
  • known failure modes and residual uncertainty
  • review and escalation instructions
  • data-access and retention decisions
  • owner approval for the next scope

Decision gate

Move to Integration only when the pilot produces repeatable value, exceptions are understood, human review is workable, affected people have been heard, and the organization is prepared to own the workflow after the experiment ends.

Useful measures

  • cycle-time or effort change against baseline
  • output acceptance and rework rates
  • reviewer effort and override frequency
  • frequency and severity of exceptions
  • user confidence and affected-party feedback
  • cost per completed workflow

Connected next steps

Review jurisdiction-specific funding and grant orientation before committing implementation spend. Use the Use Cases library to compare delegation, monitoring, and ownership patterns.

Back to framework