Skip to content

🛠️ SOP – Preparing an Analysis to Produce an MFO Workflow Description

1. Introduction

This procedure explains how to prepare an analysis to formalise an MFO (MINDFLIGHT AI ORCHESTRATOR) workflow in the form of a complete YAML file. SOP stands for Standard Operating Procedure. It is intended to guide business analysts, project managers or developers in identifying the elements necessary for the accurate modelling of a business process as a workflow that can be executed by the MFO server/client system.

2. Scope

This SOP approach applies to anyone responsible for designing or formalising an automated workflow in MINDFLIGHT AI ORCHESTRATOR, particularly for use cases involving triggers (webhooks, cron, websockets, etc.), sequences of operations (taskflows) and business rules (conditions) to be applied to tasks.

3. Responsibilities

  • Business analyst: Identifies and describes the business steps and their dependencies.
  • Developer: Validates technical feasibility and formalises the YAML definition.
  • Project manager: Oversees the overall consistency of the workflow in relation to the expressed needs.

4. Prerequisites

  • Basic knowledge of YAML.
  • Access to the technical specifications of the APIs used.
  • Recommended tools: YAML editor (Visual Studio Code or equivalent), JSON/YAML validation schema.

5. MFO SOP Process

worflow mfo

Step 1️⃣ – Identify business requirements

  1. Identify the name of the business process to be modelled.
  2. Define the expected result (e.g. automatic sending of an email after content analysis).
  3. Note the actors involved (user, third-party system, etc.).

Step 2️⃣ – Define the triggers

  1. List the triggering events:
  2. Webhook (external HTTP event)
  3. Schedule (periodic planning)
  4. Manual (manual launch/API)

  5. Event (internal system event)

  6. For each trigger:

  7. Specify the unique identifier.
  8. Determine the type (webhook, schedule, etc.).
  9. Describe the configuration:
    • For a webhook: provider, webhook_id, security (secret key), payload schema.
  10. For a schedule: cron_expression.

Step 3️⃣ – Analyse the business logic (taskflow)

  1. Break down the process into unit tasks:

  2. Example: data retrieval, API call, document processing.

  3. For each task:

  4. Define:
  5. id (unique)
  6. type (mfo_api_tool_execute, mfo_api_chat_send, etc.)
  7. config (required arguments, templates, resources to use)
    • The inputs (INPUT.<field_name>, or data from a trigger)

  8. The expected outputs (for use by other tasks)

  9. Identify dependencies and the execution sequence:

  10. Determine which tasks depend on the results of others.
  11. Use the dependencies and successors fields.

Step 4️⃣ – Define conditional rules (if necessary)

  1. List the decision points:

  2. Example: if the amount > £100, perform action A, otherwise perform action B.

  3. Specify:

  4. id of the condition
  5. Condition type (simple threshold, Boolean expression)
  6. Configuration schema (value to be tested, operator, threshold)
  7. Mapping of condition results to the following tasks.

Step 5️⃣ – Design the schemas

  1. Define the validation schemas:
  2. For inputs (input_schema): expected structure of the initial data.
  3. For triggers (expected_payload_schema): structure of the data received by the webhook/schedule.
  4. For secrets (global_configs): names of the secret keys used (example: unipile_secret).

Step 6️⃣ – Formalise the YAML

  1. Write the complete YAML structure:
  2. workflow_name, description, version
  3. global_configs
  4. triggers
  5. taskflows (with tasks, conditions, subflows if applicable)

  6. schemas

  7. Check:

  8. Consistency of identifiers (trigger vs. taskflow)
  9. Syntactic validity and compliance with expected schemas.

6. References

Questions to help define a workflow

🔍 Step 1️⃣ – Identify business requirements

  • What is the main business objective of this workflow?
  • What are the expected measurable results?
  • Who are the actors involved (humans, third-party systems)?
  • Does this process already exist in manual or semi-automatic form?
  • What are the specific constraints (regulatory, security, real-time)?
  • Are there any known exceptions or special scenarios?
  • What are the external or internal data sources involved?

🔍 Step 2️⃣ – Define the triggers

  • What events should trigger execution?
  • Is the trigger:
  • a webhook (external HTTP event)?
  • a scheduled cron?
  • an internal system event?
  • a manual/API trigger?
  • What is the expected frequency (for schedules)?
  • What data is received by the trigger (payload schema)?
  • Are there any security specifications for this trigger (e.g. secret key for signature)?
  • Do you need to manage multiple event sources that point to the same workflow?

🔍 Step 3️⃣ – Analyse the business logic (taskflow)

  • What are the specific business steps to be performed (exhaustive list)?
  • How are these steps sequenced?
  • What are the expected inputs for each task?
  • What are the expected outputs for each task?
  • Do certain tasks require specific resources (APIs, SLOP tools, databases, MCP servers, Providers)?
  • Are there any tasks that can be executed in parallel?
  • Are there any explicit dependencies (e.g., Task B must wait for Task A to finish)?
  • Should retry or recovery mechanisms be provided in case of error?
  • What is the maximum acceptable duration for each step?

🔍 Step 4️⃣ – Define conditional rules

  • Are there any decision points where the workflow needs to branch or to loop ?
  • What data or criteria are used to make decisions?
  • What is the business logic behind each condition (e.g. if > £100, do X)?
  • Should edge cases or default values be provided?
  • How are failed cases of conditions handled (e.g. missing data)?
  • How many alternative paths should be considered for each condition?

🔍 Step 5️⃣ – Design the schemas

  • What data types are handled at each step (string, int, map, etc.)?
  • What are the required fields in:
  • the task flow input?
  • the trigger payload?
  • Is there any sensitive data requiring secure reference (secrets)?
  • Are there any reusable schemas already defined in other workflows?
  • What are the validation constraints (formats, sizes, authorised values)?
  • What negative scenarios (malformed or missing data) should be anticipated?
  • Do the outputs also need to be schematised for other workflows or for auditing purposes?

🔍 Step 6️⃣ – Formalise the YAML

  • Are all identifiers consistent and unique?
  • Are the schemas referenced correctly throughout?
  • Are dependencies and conditions correctly linked?
  • Is the YAML readable and well documented (comments, descriptions)?
  • Has the file been syntactically validated (YAML lint tools)?
  • Are unit tests or simulation scenarios ready to verify the correct behaviour of the workflow?

These questions are intended to: - avoid blind spots in the thinking process, - anticipate risks and edge cases, - and help structure a comprehensive business and technical analysis before even coding or modelling.