METHODOLOGY STAGE 03

BLUEPRINT — Workflow Redesign & Solution Design

Give process owners and engineers a shared design for how the workflow should operate, including human decisions, exceptions and acceptance criteria.

Value to the engagement

A design the business and engineers can use

Who this helps

Process owner, subject-matter experts, solution architect, engineering and control owners

BLUEPRINT: from starting evidence to a useful output
  1. BringAgreed process goal

    Baseline, constraints and feasibility conditions

  2. Work throughDesign the workflow

    Rules, interfaces, exceptions and human checkpoints

  3. Leave withA reviewable design

    Specifications and testable acceptance criteria

Why this stage matters

BLUEPRINT defines the future process and removes avoidable handoffs before development. We agree what can execute automatically, what requires review and what should happen when inputs or systems fail.

Start with the workflow and control requirements. Detailed interface and platform specifications are refined with COMPASS; they are not assumed complete before the technology choices have been tested.

Who uses the output, and how

Process owner and reviewers
See exactly where people still decide, approve or resolve exceptions.
Engineering team
Build from agreed inputs, outputs and testable rules instead of interpreting an ambiguous request.
IT and operations
Review access, failure handling and support needs before release planning.

How the design becomes buildable

  • Define the target workflow: Map inputs, actions, outputs, handoffs and approval authority. Simplify unnecessary steps with the process owner.
  • Specify normal and exception behavior: Define business rules, validation, retry limits, duplicate prevention, escalation and recovery responsibilities.
  • Agree evaluation and acceptance: Document expected outputs and test cases. For AI-assisted steps, include representative examples, source checks and review thresholds.
  • Resolve integration details: Define approved interfaces, identities and data handling. Refine the solution specification with the platform and infrastructure decisions in COMPASS.

Design and platform selection inform each other

BLUEPRINT and COMPASS can iterate together. If an interface, platform capability or control changes the design materially, update the specification and revisit the relevant GATE assumptions.

What you leave with

The design artifacts tell both business reviewers and engineers what the solution must do:

Deliverables and acceptance criteria are confirmed in the engagement scope.

  • Target workflow and decision map: The normal path, human checkpoints and ownership of handoffs, reviewed with business operations.
  • Process and solution specifications: Process Definition Document (PDD) and Solution Design Document (SDD), proportionate to scope and finalized with platform-dependent details before build.
  • Exception and acceptance pack: Failure paths, recovery rules and representative tests that define acceptable behavior and output quality.
Illustrative application

Invoice disputes and chargebacks

Starting situation: A developer has a list of screens to automate, but disputed items and approval limits are unclear.

Useful output: Finance and engineering share a design showing evidence collection, proposed dispute handling, reviewer authority and what must be tested before any record is updated.

An example of how the stage can be used, not a client result or a promised outcome.

Confirm the technology behind the design.

Work through platform, integration and operating choices with COMPASS, then finalize the parts of the blueprint that depend on them.

Explore COMPASS