Process before platform. Evidence under the work.

Primary sprint · Process before platform

Understand the work before you encode it.

A fixed-scope design sprint for teams that want to automate a manual controlled workflow and do not want to automate the current mess. Process before platform: reconstruct the real work, the records, the judgment points, and the control boundary first. Then decide what may be automated, what stays human, and what any build has to satisfy.

About 2 weeks One named workflow Vendor-neutral Design, not build Fee after short inquiry

Why this exists

If the process is wrong, the platform will make it faster and harder to see.

Automation projects often start with a tool. The workflow is reverse-engineered to fit the demo. Shadow steps disappear from the diagram and reappear in production. Review is promised and not designed. The unofficial spreadsheet survives because nobody named the authoritative record.

This sprint is the pre-build look. It is useful when IT, a vendor, or an AI pilot is already in the air, and Quality or Operations needs a control boundary before anyone writes a statement of work for a build.

Strong fit when

  • There is a live intent to automate, digitize, or "add AI" to a controlled workflow
  • The current process is partly undocumented, disputed, or held together by workarounds
  • Someone will still have to review, sign, or defend the output
  • You want requirements before a build, not a tool bake-off dressed up as discovery

Deliverables

What you get from the readiness sprint

A complete decision package for one named workflow before spending on software or implementation.

1. Current-state workflow & record map

The real path across people, systems, and documents, including the unofficial spreadsheets and email chains actually used.

2. Authoritative vs derived records

Identifies which records a later auditor or reviewer should trust versus which are uncontrolled working copies.

3. Judgment & exception map

Where human accountability must remain intact and what evidence an approval must leave behind.

4. Automation boundary

Explicit separation of steps: deterministic rules, AI assistance, human judgment, or "leave it alone."

5. Control & evidence requirements

Defines the non-negotiable logging, traceability, and fallback criteria any later vendor or build must satisfy.

6. Failure modes & pilot decision

What happens when inputs fail or tools go down, plus a clear decision: proceed to a bounded build, clean process first, or do not automate.

Representative scenario

Not a client result: deviation write-up before automation

A team wants an AI copilot to draft deviation narratives because volume is high. Today an intake form, a shared inbox, a Word template (dev-142-final-v3-USE-THIS.docx), and a quality-system record all hold part of the story.

The sprint does not build the drafter. It defines the allowed sources, the judgment that must stay human, the record the approval has to leave behind, and whether this is even a defensible first automation.

Complementary to your QMS

You should still use your QMS

Automation does not replace the quality system. It has to live inside it.

This sprint is useful when the organization is about to spend on a tool and needs an independent, workflow-level specification first. Your procedures and validation obligations remain yours. I make requirements legible so whoever builds or validates is not guessing.

Scope boundary

Bounded design sprint, not open-ended consulting

About two weeks. One named workflow. One accountable owner. One decision.

Included

  • One named workflow with a defined start and end
  • One accountable owner or sponsor
  • A defined set of systems, records, and proposed tools
  • Vendor-neutral requirements and control design
  • One revision round
  • One decision: automate, clean first, or do not automate

Not included

  • Selecting or implementing a vendor platform
  • Production build or model training
  • Formal validation execution (CSV / CSA)
  • Company-wide AI strategy
  • Autonomous decisions without human control
  • Unlimited integrations or revision rounds

If the decision is to build, follow-on implementation (Controlled workflow automation) is a separately scoped engagement with human review, tests, fallback, and operating records. It is never a silent extension of the sprint.

Bring the workflow you want to automate, not a request to add AI.

The free diagnostic tests whether an automation readiness sprint is the right first move.