Algorithmation Playbook: Complete Guide for AI Integrators

Algorithmation is the discipline of converting implicit business knowledge—the processes, decisions, and rules that exist in people's heads, documents, and tribal knowledge—into explicit, machine-readable, executable algorithms.

Think of it as "Process as Code": just as software developers version and test their code, algorithmation applies the same rigor to business processes. The result is a versioned, testable, auditable representation of how your organization actually operates.

Why Algorithmation Matters for AI

AI agents like Claude are powerful—but they hallucinate when rules are ambiguous. When you ask an AI to "process a loan application," it doesn't inherently know your organization's:

• Credit score thresholds
• Debt-to-income ratio limits
• Exception handling procedures
• Escalation paths
• Compliance requirements

Algorithmation solves this by encoding these rules explicitly. The AI agent then executes the algorithm rather than inventing the logic.

In practice, algorithmation shifts AI from reasoning about what to do to executing what is already defined. This is the same distinction that exists between free-form scripting and compiled software.

The Three Standards

Algorithmation builds on three OMG (Object Management Group) standards:

What is UAPF?

UAPF (Unified Algorithmic Process Format) is the packaging standard that bundles BPMN, DMN, and CMMN models together with metadata, documentation, and resource mappings into a single, portable, versionable artifact.

A .uapf file is simply a ZIP archive containing:

my-process.uapf
├── manifest.json          # Package metadata and entry points
├── models/
│   ├── bpmn/             # Workflow definitions
│   ├── dmn/              # Decision tables
│   └── cmmn/             # Case models (optional)
├── resources/
│   └── resource-mapping.yaml
├── tests/
│   └── scenarios.json
└── docs/
    └── README.md

UAPF Package Requirements

Required Tools

Recommended Knowledge

• Basic understanding of business processes and workflows
• Familiarity with XML and JSON
• Git basics (commit, push, branch)
• Basic understanding of REST APIs

Not every process is a good candidate for algorithmation. Use this scoring framework to identify high-impact opportunities.

Process Selection Criteria

Scoring guide:

• 25-30 points: Excellent candidate—start here
• 18-24 points: Good candidate—proceed with some discovery work
• 12-17 points: Marginal—may require significant documentation effort
• Below 12: Poor fit—consider other processes first

Industry Process Examples

High-impact processes by industry that are typically good algorithmation candidates:

Red Flags: When NOT to Algorithmate

• Too simple: No decision logic needed (just a checklist)
• Too chaotic: No repeatable pattern exists
• Pure creativity: Requires genuine human judgment that can't be codified
• No measurable outcome: You can't tell if it was done "correctly"
• One-time process: Only happens once, not worth the investment

Before you can algorithmate a process, you need to understand it completely. This section provides a structured approach to extracting process knowledge.

Step 4.1: Define the Process Boundary

Answer these questions first:

Step 4.2: Map the Happy Path

Start by documenting the ideal case—when everything goes smoothly. List each activity in sequence:

1. [Trigger Event] →
2. [Activity 1: verb + noun] →
3. [Activity 2: verb + noun] →
4. [Decision Point: question?] →
   - If yes: [Activity 3]
   - If no: [Activity 4]
5. [Activity 5] →
6. [End Event: outcome]

Step 4.3: Identify Decision Points

For each decision in the process, capture:

Step 4.4: Document Exceptions

Real processes have exceptions. For each exception:

• What triggers the exception?
• How is it currently handled?
• Who handles it?
• What are the possible outcomes?

Step 4.5: List Systems and Integrations

Document every system the process touches:

Discovery Output Checklist

• Process boundary definition (trigger, end states, scope)
• Happy path sequence documented
• All decision points identified with inputs/outputs/rules
• Exception scenarios documented
• All systems and integrations listed
• Roles and responsibilities identified
• Current pain points noted

Definition of Done: Process Discovery

• Process boundary is explicitly defined and agreed with the process owner
• At least one happy path is fully documented end-to-end
• All decision points have named inputs and outputs
• Exceptions are explicitly listed (not assumed)
• All external systems and integrations are identified
• Roles and responsibilities are documented

BPMN (Business Process Model and Notation) is the standard for modeling workflows. This section covers the essential elements you'll actually use.

Essential BPMN Elements

Common BPMN Patterns

Pattern 1: Simple Sequence

Start → Task A → Task B → Task C → End

Pattern 2: Decision Branch

Start → Check → Gateway(X) → [Yes: Path A] or [No: Path B] → End

Pattern 3: Parallel Execution

Start → Gateway(+) → [Task A || Task B || Task C] → Gateway(+) → End

Pattern 4: Loop / Rework

Review → Gateway → [Approve: End] or [Rework: Fix → back to Review]

Step-by-Step: Creating a BPMN Model

Step 5.1: Create the File Structure

models/bpmn/main-process.bpmn

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions 
    xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
    xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
    xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
    xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
    id="Definitions_1"
    targetNamespace="http://algomation.io/schema/bpmn">

    <bpmn:process id="Process_Main" name="Main Process" isExecutable="true">
        <!-- Process elements go here -->
    </bpmn:process>

    <bpmndi:BPMNDiagram id="BPMNDiagram_1">
        <bpmndi:BPMNPlane id="BPMNPlane_1" bpmnElement="Process_Main">
            <!-- Visual layout goes here -->
        </bpmndi:BPMNPlane>
    </bpmndi:BPMNDiagram>

</bpmn:definitions>

Step 5.2: Add Start Event

<bpmn:startEvent id="StartEvent_1" name="Application Received">
    <bpmn:outgoing>Flow_Start_To_Task1</bpmn:outgoing>
</bpmn:startEvent>

Step 5.3: Add Tasks

<!-- User Task: requires human action -->
<bpmn:userTask id="Task_ReviewDocs" name="Review Documentation">
    <bpmn:incoming>Flow_Start_To_Task1</bpmn:incoming>
    <bpmn:outgoing>Flow_Task1_To_Gateway</bpmn:outgoing>
</bpmn:userTask>

<!-- Service Task: automated system call -->
<bpmn:serviceTask id="Task_PullCredit" name="Pull Credit Score">
    <bpmn:incoming>Flow_Gateway_To_Credit</bpmn:incoming>
    <bpmn:outgoing>Flow_Credit_To_Rules</bpmn:outgoing>
</bpmn:serviceTask>

<!-- Business Rule Task: invokes DMN decision table -->
<bpmn:businessRuleTask id="Task_EvalEligibility" name="Evaluate Eligibility">
    <bpmn:incoming>Flow_Credit_To_Rules</bpmn:incoming>
    <bpmn:outgoing>Flow_Rules_To_Decision</bpmn:outgoing>
</bpmn:businessRuleTask>

Step 5.4: Add Gateways

<!-- Exclusive Gateway: XOR - one path only -->
<bpmn:exclusiveGateway id="Gateway_Eligible" name="Is Eligible?">
    <bpmn:incoming>Flow_Rules_To_Decision</bpmn:incoming>
    <bpmn:outgoing>Flow_Yes_Approve</bpmn:outgoing>
    <bpmn:outgoing>Flow_No_Reject</bpmn:outgoing>
    <bpmn:outgoing>Flow_Maybe_Review</bpmn:outgoing>
</bpmn:exclusiveGateway>

<!-- Parallel Gateway: AND - all paths simultaneously -->
<bpmn:parallelGateway id="Gateway_Split" name="Run All Checks">
    <bpmn:incoming>Flow_To_Parallel</bpmn:incoming>
    <bpmn:outgoing>Flow_Check1</bpmn:outgoing>
    <bpmn:outgoing>Flow_Check2</bpmn:outgoing>
    <bpmn:outgoing>Flow_Check3</bpmn:outgoing>
</bpmn:parallelGateway>

Step 5.5: Add Sequence Flows with Conditions

<!-- Unconditional flow -->
<bpmn:sequenceFlow id="Flow_Start_To_Task1" 
    sourceRef="StartEvent_1" 
    targetRef="Task_ReviewDocs" />

<!-- Conditional flow (for gateway outputs) -->
<bpmn:sequenceFlow id="Flow_Yes_Approve" name="Eligible"
    sourceRef="Gateway_Eligible" 
    targetRef="Task_Approve">
    <bpmn:conditionExpression xsi:type="bpmn:tFormalExpression">
        ${eligibilityResult == 'ELIGIBLE'}
    </bpmn:conditionExpression>
</bpmn:sequenceFlow>

<bpmn:sequenceFlow id="Flow_No_Reject" name="Not Eligible"
    sourceRef="Gateway_Eligible" 
    targetRef="Task_Reject">
    <bpmn:conditionExpression xsi:type="bpmn:tFormalExpression">
        ${eligibilityResult == 'NOT_ELIGIBLE'}
    </bpmn:conditionExpression>
</bpmn:sequenceFlow>

<!-- Default flow (when no other condition matches) -->
<bpmn:sequenceFlow id="Flow_Maybe_Review" name="Manual Review"
    sourceRef="Gateway_Eligible" 
    targetRef="Task_ManualReview" />

Step 5.6: Add End Events

<bpmn:endEvent id="EndEvent_Approved" name="Application Approved">
    <bpmn:incoming>Flow_Approve_To_End</bpmn:incoming>
</bpmn:endEvent>

<bpmn:endEvent id="EndEvent_Rejected" name="Application Rejected">
    <bpmn:incoming>Flow_Reject_To_End</bpmn:incoming>
</bpmn:endEvent>

BPMN Quality Checklist

• Every element has a unique id
• Every element has a descriptive name
• Every gateway has at least two outgoing flows
• Every conditional flow has a condition expression
• One flow from each gateway should be the default (no condition)
• Every path eventually reaches an end event
• No orphan elements (everything is connected)
• Task names follow "Verb + Noun" pattern

DMN (Decision Model and Notation) defines business rules as explicit, testable decision tables. When your BPMN process needs to make a decision based on multiple inputs and rules, you extract that logic into a DMN table.

When to Use DMN vs. Gateway Conditions

Anatomy of a Decision Table

A DMN decision table has:

• Inputs (blue columns): Data used to make the decision
• Outputs (green columns): Results of the decision
• Rules (rows): Each row is a rule—if inputs match, outputs are returned
• Hit Policy: What happens when multiple rules match

Example: Credit Eligibility Decision

Note: "-" means "any value" (don't care)

Hit Policies

Step-by-Step: Creating a DMN Model

Step 6.1: Create the DMN File Structure

models/dmn/eligibility-rules.dmn

<?xml version="1.0" encoding="UTF-8"?>
<definitions 
    xmlns="https://www.omg.org/spec/DMN/20191111/MODEL/"
    xmlns:dmndi="https://www.omg.org/spec/DMN/20191111/DMNDI/"
    xmlns:dc="http://www.omg.org/spec/DMN/20180521/DC/"
    id="Definitions_Eligibility"
    name="Eligibility Rules"
    namespace="http://algomation.io/dmn">

    <!-- Input definitions -->
    <!-- Decision definition -->

</definitions>

Step 6.2: Define Input Data

<inputData id="InputData_CreditScore" name="creditScore">
    <variable name="creditScore" typeRef="number" />
</inputData>

<inputData id="InputData_DTI" name="debtToIncomeRatio">
    <variable name="debtToIncomeRatio" typeRef="number" />
</inputData>

<inputData id="InputData_Income" name="annualIncome">
    <variable name="annualIncome" typeRef="number" />
</inputData>

Step 6.3: Define the Decision with Decision Table

<decision id="Decision_Eligibility" name="Determine Eligibility">
    <variable name="eligibilityResult" typeRef="string" />

    <informationRequirement id="IR_1">
        <requiredInput href="#InputData_CreditScore" />
    </informationRequirement>
    <informationRequirement id="IR_2">
        <requiredInput href="#InputData_DTI" />
    </informationRequirement>
    <informationRequirement id="IR_3">
        <requiredInput href="#InputData_Income" />
    </informationRequirement>

    <decisionTable id="DecisionTable_1" hitPolicy="FIRST">
        <!-- Input columns -->
        <input id="Input_1" label="Credit Score">
            <inputExpression typeRef="number">
                <text>creditScore</text>
            </inputExpression>
        </input>
        <input id="Input_2" label="Debt-to-Income Ratio">
            <inputExpression typeRef="number">
                <text>debtToIncomeRatio</text>
            </inputExpression>
        </input>
        <input id="Input_3" label="Annual Income">
            <inputExpression typeRef="number">
                <text>annualIncome</text>
            </inputExpression>
        </input>

        <!-- Output column -->
        <output id="Output_1" label="Eligibility" name="eligibilityResult" typeRef="string" />

        <!-- Rules -->
        <rule id="Rule_1">
            <inputEntry id="IE_1_1"><text>>= 720</text></inputEntry>
            <inputEntry id="IE_1_2"><text><= 0.35</text></inputEntry>
            <inputEntry id="IE_1_3"><text></text></inputEntry>
            <outputEntry id="OE_1"><text>"ELIGIBLE"</text></outputEntry>
        </rule>

        <rule id="Rule_2">
            <inputEntry id="IE_2_1"><text>[680..720)</text></inputEntry>
            <inputEntry id="IE_2_2"><text><= 0.40</text></inputEntry>
            <inputEntry id="IE_2_3"><text>>= 50000</text></inputEntry>
            <outputEntry id="OE_2"><text>"ELIGIBLE"</text></outputEntry>
        </rule>

        <rule id="Rule_3">
            <inputEntry id="IE_3_1"><text>[680..720)</text></inputEntry>
            <inputEntry id="IE_3_2"><text><= 0.43</text></inputEntry>
            <inputEntry id="IE_3_3"><text></text></inputEntry>
            <outputEntry id="OE_3"><text>"MANUAL_REVIEW"</text></outputEntry>
        </rule>

        <rule id="Rule_4">
            <inputEntry id="IE_4_1"><text>< 680</text></inputEntry>
            <inputEntry id="IE_4_2"><text></text></inputEntry>
            <inputEntry id="IE_4_3"><text></text></inputEntry>
            <outputEntry id="OE_4"><text>"NOT_ELIGIBLE"</text></outputEntry>
        </rule>

        <rule id="Rule_5">
            <inputEntry id="IE_5_1"><text></text></inputEntry>
            <inputEntry id="IE_5_2"><text>> 0.43</text></inputEntry>
            <inputEntry id="IE_5_3"><text></text></inputEntry>
            <outputEntry id="OE_5"><text>"NOT_ELIGIBLE"</text></outputEntry>
        </rule>
    </decisionTable>
</decision>

DMN Expression Syntax (FEEL)

DMN uses FEEL (Friendly Enough Expression Language) for conditions:

DMN Quality Checklist

• All input combinations are covered (no gaps)
• No conflicting rules (or hit policy handles it)
• Hit policy is explicitly set (U, F, A, or C)
• Input variable names match process data
• Output values are actionable in the process
• Each rule has been tested with sample data

Resource mapping defines who or what executes each task in your process. This is essential for AI agent integration—it specifies which tasks the AI handles and which require human or system action.

Executor Types

7.1 Canonical Resource Ontology (Recommended)

To ensure portability and governance, UAPF resource mappings SHOULD use a canonical executor ontology. This avoids ad-hoc role naming and makes packages transferable across organizations and runtimes. This is a logical ontology, not an identity system. Concrete identities are bound at deployment time.

Canonical naming rules:

• IDs MUST be stable and semantic
• IDs MUST NOT contain personal names
• IDs SHOULD be namespaced

role.finance.manager
agent.document.classifier
engine.dmn
system.erp.sap

Execution Modes

Resource Mapping File

resources/resource-mapping.yaml

# Resource Mapping for Employee Onboarding Process
# Defines who/what executes each task
# Canonical IDs are late-bound to concrete identities at deployment time

targets:
  # Human roles
  - id: role.hr.coordinator
    type: human.role
    name: HR Coordinator
    description: Handles general HR tasks and coordination

  - id: role.it.administrator
    type: human.role
    name: IT Administrator
    description: Provisions accounts and equipment

  - id: role.hiring.manager
    type: human.role
    name: Hiring Manager
    description: Department manager who made the hire

  # System integrations
  - id: system.api.hris
    type: system.api
    name: HRIS System
    endpoint: https://hris.internal/api/v2
    auth: oauth2

  - id: system.api.active-directory
    type: system.api
    name: Active Directory
    endpoint: ldaps://ad.internal
    auth: service-account

  # AI agents
  - id: agent.onboarding.assistant
    type: ai.agent
    name: Onboarding Assistant
    protocol: mcp
    capabilities:
      - document-analysis
      - text-generation
      - summarization

  # Engine (for DMN evaluation)
  - id: engine.dmn
    type: engine.rule
    name: DMN Decision Engine

# Task bindings
bindings:
  # HR Coordinator tasks
  - source:
      type: bpmn.task
      ref: Task_SendWelcomeEmail
    targetId: role.hr.coordinator
    mode: manual

  - source:
      type: bpmn.task
      ref: Task_CollectDocuments
    targetId: role.hr.coordinator
    mode: manual

  # IT tasks (automated)
  - source:
      type: bpmn.task
      ref: Task_CreateADAccount
    targetId: system.api.active-directory
    mode: autonomous
    config:
      operation: createUser

  - source:
      type: bpmn.task
      ref: Task_ProvisionEquipment
    targetId: role.it.administrator
    mode: manual

  # AI-assisted tasks
  - source:
      type: bpmn.task
      ref: Task_GenerateOnboardingPlan
    targetId: agent.onboarding.assistant
    mode: assisted
    config:
      systemPrompt: |
        You are an HR assistant helping create personalized onboarding plans.
        Based on the employee's role and department, generate a 30-60-90 day plan.
      outputFormat: markdown

  - source:
      type: bpmn.task
      ref: Task_AnalyzeDocuments
    targetId: agent.onboarding.assistant
    mode: autonomous
    config:
      systemPrompt: |
        Extract key information from uploaded documents:
        - Full legal name
        - Address
        - Emergency contact
        - Tax withholding preferences
      outputFormat: json

  # Decision tasks (DMN)
  - source:
      type: bpmn.task
      ref: Task_DetermineEquipment
    targetId: engine.dmn
    mode: autonomous
    config:
      decisionId: Decision_EquipmentAllocation

  - source:
      type: bpmn.task
      ref: Task_DetermineAccessLevel
    targetId: engine.dmn
    mode: autonomous
    config:
      decisionId: Decision_AccessLevel

  # HRIS integration
  - source:
      type: bpmn.task
      ref: Task_CreateEmployeeRecord
    targetId: system.api.hris
    mode: autonomous
    config:
      operation: employees.create

Resource Mapping Checklist

• Every task in BPMN has a corresponding binding
• Target IDs are unique and descriptive
• Execution mode is appropriate for task type
• API endpoints and auth methods are specified
• AI agent prompts are clear and specific
• DMN decision IDs match actual DMN files

Now you'll assemble all the components into a UAPF package—the deployable unit that contains your entire algorithmated process.

Package Structure

employee-onboarding.uapf/
├── manifest.json                    # Package metadata
├── models/
│   ├── bpmn/
│   │   └── onboarding-main.bpmn     # Main workflow
│   ├── dmn/
│   │   ├── equipment-allocation.dmn # Equipment rules
│   │   └── access-level.dmn         # Access rules
│   └── cmmn/                        # (empty for this process)
├── resources/
│   └── resource-mapping.yaml        # Task bindings
├── tests/
│   └── scenarios.json               # Test cases
└── docs/
    ├── README.md                    # Process documentation
    └── decision-rationale.md        # Why rules are what they are

Manifest.json

The manifest is the entry point that describes the package:

manifest.json

{
  "uapfVersion": "0.1.0",
  "id": "com.yourcompany.hr.employee-onboarding",
  "name": "Employee Onboarding",
  "version": "1.0.0",
  "description": "End-to-end employee onboarding from offer acceptance to Day 1 readiness",

  "models": {
    "bpmn": [
      "models/bpmn/onboarding-main.bpmn"
    ],
    "dmn": [
      "models/dmn/equipment-allocation.dmn",
      "models/dmn/access-level.dmn"
    ],
    "cmmn": []
  },

  "interfaces": {
    "processes": [
      {
        "id": "EmployeeOnboarding",
        "bpmnProcessId": "Process_Onboarding",
        "entryPoint": "StartEvent_OfferAccepted",
        "description": "Main onboarding workflow",
        "inputs": [
          {
            "name": "employeeData",
            "type": "object",
            "required": true,
            "schema": {
              "type": "object",
              "properties": {
                "name": { "type": "string" },
                "email": { "type": "string" },
                "department": { "type": "string" },
                "role": { "type": "string" },
                "startDate": { "type": "string", "format": "date" },
                "manager": { "type": "string" }
              },
              "required": ["name", "email", "department", "role", "startDate"]
            }
          }
        ],
        "outputs": [
          {
            "name": "onboardingComplete",
            "type": "boolean"
          },
          {
            "name": "employeeId",
            "type": "string"
          }
        ]
      }
    ],
    "decisions": [
      {
        "id": "EquipmentAllocation",
        "dmnDecisionId": "Decision_Equipment",
        "description": "Determines equipment package based on role and department",
        "inputs": [
          { "name": "department", "type": "string" },
          { "name": "role", "type": "string" },
          { "name": "isRemote", "type": "boolean" }
        ],
        "outputs": [
          { "name": "equipmentPackage", "type": "string" },
          { "name": "laptopSpec", "type": "string" }
        ]
      },
      {
        "id": "AccessLevelDetermination",
        "dmnDecisionId": "Decision_AccessLevel",
        "description": "Determines system access based on role",
        "inputs": [
          { "name": "department", "type": "string" },
          { "name": "role", "type": "string" },
          { "name": "employmentType", "type": "string" }
        ],
        "outputs": [
          { "name": "accessLevel", "type": "string" },
          { "name": "systemAccess", "type": "array" }
        ]
      }
    ]
  },

  "metadata": {
    "owner": "HR Operations",
    "maintainer": "[email protected]",
    "created": "2026-01-15",
    "lastModified": "2026-01-15",
    "tags": ["hr", "onboarding", "employee-lifecycle"],
    "complianceReferences": [
      "SOX Section 404 - Access Controls",
      "GDPR - Employee Data Processing"
    ]
  },

  "dependencies": {},

  "exposure": {
    "mcp": {
      "enabled": true,
      "exposedEntrypoints": ["EmployeeOnboarding", "EquipmentAllocation", "AccessLevelDetermination"]
    }
  }
}

Test Scenarios File

tests/scenarios.json

{
  "scenarios": [
    {
      "id": "scenario-1",
      "name": "Standard Engineer Onboarding",
      "description": "Typical software engineer hire",
      "processId": "EmployeeOnboarding",
      "input": {
        "employeeData": {
          "name": "Jane Smith",
          "email": "[email protected]",
          "department": "Engineering",
          "role": "Software Engineer",
          "startDate": "2026-02-01",
          "manager": "[email protected]",
          "isRemote": false,
          "employmentType": "full-time"
        }
      },
      "expectedDecisions": {
        "EquipmentAllocation": {
          "equipmentPackage": "ENGINEER_STANDARD",
          "laptopSpec": "MacBook Pro 16\""
        },
        "AccessLevelDetermination": {
          "accessLevel": "STANDARD",
          "systemAccess": ["GitHub", "Jira", "Confluence", "Slack", "AWS-Dev"]
        }
      },
      "expectedOutcome": {
        "onboardingComplete": true
      }
    },
    {
      "id": "scenario-2",
      "name": "Executive Hire - Expedited",
      "description": "C-level executive with elevated access",
      "processId": "EmployeeOnboarding",
      "input": {
        "employeeData": {
          "name": "Robert Johnson",
          "email": "[email protected]",
          "department": "Executive",
          "role": "Chief Technology Officer",
          "startDate": "2026-01-20",
          "manager": "[email protected]",
          "isRemote": false,
          "employmentType": "full-time"
        }
      },
      "expectedDecisions": {
        "EquipmentAllocation": {
          "equipmentPackage": "EXECUTIVE",
          "laptopSpec": "MacBook Pro 16\" Max"
        },
        "AccessLevelDetermination": {
          "accessLevel": "EXECUTIVE",
          "systemAccess": ["ALL_SYSTEMS", "BOARD_MATERIALS", "FINANCIAL_REPORTING"]
        }
      }
    },
    {
      "id": "scenario-3",
      "name": "Contractor - Limited Access",
      "description": "External contractor with restricted access",
      "processId": "EmployeeOnboarding",
      "input": {
        "employeeData": {
          "name": "Alex Contractor",
          "email": "[email protected]",
          "department": "Engineering",
          "role": "Contract Developer",
          "startDate": "2026-02-15",
          "manager": "[email protected]",
          "isRemote": true,
          "employmentType": "contractor"
        }
      },
      "expectedDecisions": {
        "AccessLevelDetermination": {
          "accessLevel": "RESTRICTED",
          "systemAccess": ["GitHub-Limited", "Jira-Project", "Slack-Channel"]
        }
      }
    }
  ]
}

Creating the .uapf Package

A .uapf file is simply a ZIP archive. To create it:

# From the package directory
cd employee-onboarding.uapf/

# Create the ZIP archive
zip -r ../employee-onboarding.uapf .

# Or using the UAPF CLI (if available)
uapf pack --output ../employee-onboarding.uapf

Package Assembly Checklist

• manifest.json is valid JSON
• All files referenced in manifest exist
• BPMN process IDs match manifest entries
• DMN decision IDs match manifest entries
• Resource mapping covers all tasks
• Test scenarios cover main paths
• Documentation is up to date

Let's put everything together with a complete, working example. We'll algorithmate an employee onboarding process from scratch.

9.1 Process Overview

9.2 Happy Path

1. [Offer Accepted] →
2. Create employee record in HRIS →
3. Send welcome email →
4. Collect required documents →
5. [Parallel split]
   a. Determine equipment → Order equipment
   b. Determine access level → Create AD account → Provision systems
   c. Schedule orientation → Send calendar invites
6. [Parallel join]
7. Verify all tasks complete →
8. [Day 1 Ready]

9.3 Complete BPMN Model

models/bpmn/onboarding-main.bpmn

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions 
    xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    id="Definitions_Onboarding"
    targetNamespace="http://algomation.io/onboarding">

  <bpmn:process id="Process_Onboarding" name="Employee Onboarding" isExecutable="true">

    <!-- START -->
    <bpmn:startEvent id="StartEvent_OfferAccepted" name="Offer Accepted">
      <bpmn:outgoing>Flow_Start_Create</bpmn:outgoing>
    </bpmn:startEvent>

    <!-- Initial Tasks -->
    <bpmn:serviceTask id="Task_CreateEmployeeRecord" name="Create Employee Record">
      <bpmn:incoming>Flow_Start_Create</bpmn:incoming>
      <bpmn:outgoing>Flow_Create_Welcome</bpmn:outgoing>
    </bpmn:serviceTask>

    <bpmn:serviceTask id="Task_SendWelcomeEmail" name="Send Welcome Email">
      <bpmn:incoming>Flow_Create_Welcome</bpmn:incoming>
      <bpmn:outgoing>Flow_Welcome_Docs</bpmn:outgoing>
    </bpmn:serviceTask>

    <bpmn:userTask id="Task_CollectDocuments" name="Collect Required Documents">
      <bpmn:incoming>Flow_Welcome_Docs</bpmn:incoming>
      <bpmn:outgoing>Flow_Docs_Split</bpmn:outgoing>
    </bpmn:userTask>

    <!-- PARALLEL SPLIT -->
    <bpmn:parallelGateway id="Gateway_Split" name="Start Parallel Tasks">
      <bpmn:incoming>Flow_Docs_Split</bpmn:incoming>
      <bpmn:outgoing>Flow_Split_Equipment</bpmn:outgoing>
      <bpmn:outgoing>Flow_Split_Access</bpmn:outgoing>
      <bpmn:outgoing>Flow_Split_Orientation</bpmn:outgoing>
    </bpmn:parallelGateway>

    <!-- EQUIPMENT TRACK -->
    <bpmn:businessRuleTask id="Task_DetermineEquipment" name="Determine Equipment">
      <bpmn:incoming>Flow_Split_Equipment</bpmn:incoming>
      <bpmn:outgoing>Flow_Equip_Order</bpmn:outgoing>
    </bpmn:businessRuleTask>

    <bpmn:userTask id="Task_OrderEquipment" name="Order Equipment">
      <bpmn:incoming>Flow_Equip_Order</bpmn:incoming>
      <bpmn:outgoing>Flow_Order_Join</bpmn:outgoing>
    </bpmn:userTask>

    <!-- ACCESS TRACK -->
    <bpmn:businessRuleTask id="Task_DetermineAccessLevel" name="Determine Access Level">
      <bpmn:incoming>Flow_Split_Access</bpmn:incoming>
      <bpmn:outgoing>Flow_Access_AD</bpmn:outgoing>
    </bpmn:businessRuleTask>

    <bpmn:serviceTask id="Task_CreateADAccount" name="Create AD Account">
      <bpmn:incoming>Flow_Access_AD</bpmn:incoming>
      <bpmn:outgoing>Flow_AD_Provision</bpmn:outgoing>
    </bpmn:serviceTask>

    <bpmn:serviceTask id="Task_ProvisionSystems" name="Provision System Access">
      <bpmn:incoming>Flow_AD_Provision</bpmn:incoming>
      <bpmn:outgoing>Flow_Provision_Join</bpmn:outgoing>
    </bpmn:serviceTask>

    <!-- ORIENTATION TRACK -->
    <bpmn:userTask id="Task_ScheduleOrientation" name="Schedule Orientation">
      <bpmn:incoming>Flow_Split_Orientation</bpmn:incoming>
      <bpmn:outgoing>Flow_Orient_Calendar</bpmn:outgoing>
    </bpmn:userTask>

    <bpmn:serviceTask id="Task_SendCalendarInvites" name="Send Calendar Invites">
      <bpmn:incoming>Flow_Orient_Calendar</bpmn:incoming>
      <bpmn:outgoing>Flow_Calendar_Join</bpmn:outgoing>
    </bpmn:serviceTask>

    <!-- PARALLEL JOIN -->
    <bpmn:parallelGateway id="Gateway_Join" name="All Tasks Complete">
      <bpmn:incoming>Flow_Order_Join</bpmn:incoming>
      <bpmn:incoming>Flow_Provision_Join</bpmn:incoming>
      <bpmn:incoming>Flow_Calendar_Join</bpmn:incoming>
      <bpmn:outgoing>Flow_Join_Verify</bpmn:outgoing>
    </bpmn:parallelGateway>

    <!-- Final verification -->
    <bpmn:userTask id="Task_VerifyComplete" name="Verify Onboarding Complete">
      <bpmn:incoming>Flow_Join_Verify</bpmn:incoming>
      <bpmn:outgoing>Flow_Verify_End</bpmn:outgoing>
    </bpmn:userTask>

    <!-- END -->
    <bpmn:endEvent id="EndEvent_Ready" name="Day 1 Ready">
      <bpmn:incoming>Flow_Verify_End</bpmn:incoming>
    </bpmn:endEvent>

    <!-- SEQUENCE FLOWS -->
    <bpmn:sequenceFlow id="Flow_Start_Create" sourceRef="StartEvent_OfferAccepted" targetRef="Task_CreateEmployeeRecord" />
    <bpmn:sequenceFlow id="Flow_Create_Welcome" sourceRef="Task_CreateEmployeeRecord" targetRef="Task_SendWelcomeEmail" />
    <bpmn:sequenceFlow id="Flow_Welcome_Docs" sourceRef="Task_SendWelcomeEmail" targetRef="Task_CollectDocuments" />
    <bpmn:sequenceFlow id="Flow_Docs_Split" sourceRef="Task_CollectDocuments" targetRef="Gateway_Split" />

    <bpmn:sequenceFlow id="Flow_Split_Equipment" sourceRef="Gateway_Split" targetRef="Task_DetermineEquipment" />
    <bpmn:sequenceFlow id="Flow_Equip_Order" sourceRef="Task_DetermineEquipment" targetRef="Task_OrderEquipment" />
    <bpmn:sequenceFlow id="Flow_Order_Join" sourceRef="Task_OrderEquipment" targetRef="Gateway_Join" />

    <bpmn:sequenceFlow id="Flow_Split_Access" sourceRef="Gateway_Split" targetRef="Task_DetermineAccessLevel" />
    <bpmn:sequenceFlow id="Flow_Access_AD" sourceRef="Task_DetermineAccessLevel" targetRef="Task_CreateADAccount" />
    <bpmn:sequenceFlow id="Flow_AD_Provision" sourceRef="Task_CreateADAccount" targetRef="Task_ProvisionSystems" />
    <bpmn:sequenceFlow id="Flow_Provision_Join" sourceRef="Task_ProvisionSystems" targetRef="Gateway_Join" />

    <bpmn:sequenceFlow id="Flow_Split_Orientation" sourceRef="Gateway_Split" targetRef="Task_ScheduleOrientation" />
    <bpmn:sequenceFlow id="Flow_Orient_Calendar" sourceRef="Task_ScheduleOrientation" targetRef="Task_SendCalendarInvites" />
    <bpmn:sequenceFlow id="Flow_Calendar_Join" sourceRef="Task_SendCalendarInvites" targetRef="Gateway_Join" />

    <bpmn:sequenceFlow id="Flow_Join_Verify" sourceRef="Gateway_Join" targetRef="Task_VerifyComplete" />
    <bpmn:sequenceFlow id="Flow_Verify_End" sourceRef="Task_VerifyComplete" targetRef="EndEvent_Ready" />

  </bpmn:process>
</bpmn:definitions>

9.4 Equipment Allocation DMN

models/dmn/equipment-allocation.dmn

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="https://www.omg.org/spec/DMN/20191111/MODEL/"
    id="Definitions_Equipment"
    name="Equipment Allocation Rules"
    namespace="http://algomation.io/dmn">

  <inputData id="Input_Department" name="department">
    <variable name="department" typeRef="string" />
  </inputData>

  <inputData id="Input_Role" name="role">
    <variable name="role" typeRef="string" />
  </inputData>

  <inputData id="Input_Remote" name="isRemote">
    <variable name="isRemote" typeRef="boolean" />
  </inputData>

  <decision id="Decision_Equipment" name="Determine Equipment Package">
    <variable name="equipment" typeRef="string" />

    <informationRequirement id="IR_1">
      <requiredInput href="#Input_Department" />
    </informationRequirement>
    <informationRequirement id="IR_2">
      <requiredInput href="#Input_Role" />
    </informationRequirement>
    <informationRequirement id="IR_3">
      <requiredInput href="#Input_Remote" />
    </informationRequirement>

    <decisionTable id="DT_Equipment" hitPolicy="FIRST">
      <input id="In_Dept" label="Department">
        <inputExpression typeRef="string"><text>department</text></inputExpression>
      </input>
      <input id="In_Role" label="Role">
        <inputExpression typeRef="string"><text>role</text></inputExpression>
      </input>
      <input id="In_Remote" label="Remote">
        <inputExpression typeRef="boolean"><text>isRemote</text></inputExpression>
      </input>

      <output id="Out_Package" label="Equipment Package" name="equipmentPackage" typeRef="string" />
      <output id="Out_Laptop" label="Laptop Spec" name="laptopSpec" typeRef="string" />

      <!-- Executive -->
      <rule id="Rule_Exec">
        <inputEntry><text>"Executive"</text></inputEntry>
        <inputEntry><text></text></inputEntry>
        <inputEntry><text></text></inputEntry>
        <outputEntry><text>"EXECUTIVE"</text></outputEntry>
        <outputEntry><text>"MacBook Pro 16 Max"</text></outputEntry>
      </rule>

      <!-- Engineering -->
      <rule id="Rule_Eng">
        <inputEntry><text>"Engineering"</text></inputEntry>
        <inputEntry><text></text></inputEntry>
        <inputEntry><text></text></inputEntry>
        <outputEntry><text>"ENGINEER_STANDARD"</text></outputEntry>
        <outputEntry><text>"MacBook Pro 16"</text></outputEntry>
      </rule>

      <!-- Design -->
      <rule id="Rule_Design">
        <inputEntry><text>"Design"</text></inputEntry>
        <inputEntry><text></text></inputEntry>
        <inputEntry><text></text></inputEntry>
        <outputEntry><text>"DESIGNER"</text></outputEntry>
        <outputEntry><text>"MacBook Pro 16 + Studio Display"</text></outputEntry>
      </rule>

      <!-- Remote workers get home office setup -->
      <rule id="Rule_Remote">
        <inputEntry><text></text></inputEntry>
        <inputEntry><text></text></inputEntry>
        <inputEntry><text>true</text></inputEntry>
        <outputEntry><text>"REMOTE_STANDARD"</text></outputEntry>
        <outputEntry><text>"MacBook Air M3 + Monitor + Accessories"</text></outputEntry>
      </rule>

      <!-- Default -->
      <rule id="Rule_Default">
        <inputEntry><text></text></inputEntry>
        <inputEntry><text></text></inputEntry>
        <inputEntry><text></text></inputEntry>
        <outputEntry><text>"OFFICE_STANDARD"</text></outputEntry>
        <outputEntry><text>"MacBook Air M3"</text></outputEntry>
      </rule>
    </decisionTable>
  </decision>
</definitions>

9.5 Access Level DMN

models/dmn/access-level.dmn

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="https://www.omg.org/spec/DMN/20191111/MODEL/"
    id="Definitions_Access"
    name="Access Level Rules"
    namespace="http://algomation.io/dmn">

  <inputData id="Input_Department" name="department">
    <variable name="department" typeRef="string" />
  </inputData>

  <inputData id="Input_Role" name="role">
    <variable name="role" typeRef="string" />
  </inputData>

  <inputData id="Input_EmpType" name="employmentType">
    <variable name="employmentType" typeRef="string" />
  </inputData>

  <decision id="Decision_AccessLevel" name="Determine Access Level">
    <variable name="accessResult" typeRef="any" />

    <informationRequirement id="IR_1">
      <requiredInput href="#Input_Department" />
    </informationRequirement>
    <informationRequirement id="IR_2">
      <requiredInput href="#Input_Role" />
    </informationRequirement>
    <informationRequirement id="IR_3">
      <requiredInput href="#Input_EmpType" />
    </informationRequirement>

    <decisionTable id="DT_Access" hitPolicy="FIRST">
      <input id="In_Dept">
        <inputExpression typeRef="string"><text>department</text></inputExpression>
      </input>
      <input id="In_EmpType">
        <inputExpression typeRef="string"><text>employmentType</text></inputExpression>
      </input>

      <output id="Out_Level" name="accessLevel" typeRef="string" />
      <output id="Out_Systems" name="systemAccess" typeRef="string" />

      <!-- Contractors get restricted access -->
      <rule id="Rule_Contractor">
        <inputEntry><text></text></inputEntry>
        <inputEntry><text>"contractor"</text></inputEntry>
        <outputEntry><text>"RESTRICTED"</text></outputEntry>
        <outputEntry><text>"Slack,Jira-Project,GitHub-Limited"</text></outputEntry>
      </rule>

      <!-- Executive access -->
      <rule id="Rule_Exec">
        <inputEntry><text>"Executive"</text></inputEntry>
        <inputEntry><text></text></inputEntry>
        <outputEntry><text>"EXECUTIVE"</text></outputEntry>
        <outputEntry><text>"ALL_SYSTEMS,BOARD_MATERIALS,FINANCIALS"</text></outputEntry>
      </rule>

      <!-- Engineering access -->
      <rule id="Rule_Eng">
        <inputEntry><text>"Engineering"</text></inputEntry>
        <inputEntry><text></text></inputEntry>
        <outputEntry><text>"STANDARD"</text></outputEntry>
        <outputEntry><text>"Slack,Jira,Confluence,GitHub,AWS-Dev"</text></outputEntry>
      </rule>

      <!-- Finance access -->
      <rule id="Rule_Finance">
        <inputEntry><text>"Finance"</text></inputEntry>
        <inputEntry><text></text></inputEntry>
        <outputEntry><text>"FINANCE"</text></outputEntry>
        <outputEntry><text>"Slack,NetSuite,Expensify,Banking"</text></outputEntry>
      </rule>

      <!-- Default -->
      <rule id="Rule_Default">
        <inputEntry><text></text></inputEntry>
        <inputEntry><text></text></inputEntry>
        <outputEntry><text>"STANDARD"</text></outputEntry>
        <outputEntry><text>"Slack,Jira,Confluence,Google-Workspace"</text></outputEntry>
      </rule>
    </decisionTable>
  </decision>
</definitions>

10.1 Engine-Agnostic Test Harness (Required)

Validation is incomplete without a standardized way to assert expected behavior. A UAPF Test Harness defines how a process or decision can be tested independently of the runtime engine. This ensures that BPMN, DMN, and resource bindings behave consistently across engines, MCP servers, or orchestration layers.

• Tests validate behavior, not implementation
• Tests must be executable by any compliant engine

UAPF Test Harness Contract

tests/scenarios.json

{
  "scenarioId": "invoice-auto-approval",
  "target": "InvoiceApproval",
  "inputs": {
    "invoiceAmount": 3200
  },
  "expectedPath": ["AUTO_APPROVAL"],
  "expectedOutputs": {
    "approvalStatus": "APPROVED"
  }
}

Definition of Done: Test Harness

• Every executable process has at least one scenario
• All DMN decisions have boundary-value tests
• Tests do not reference engine-specific APIs
• Expected behavior is explicit and machine-checkable

10.2 Schema Validation

Validate your package against UAPF schemas:

# Using UAPF CLI
uapf validate ./employee-onboarding.uapf

# Or using the online validator
# Upload to: https://algomation.io/uapf-viewer

10.3 Reference Validation

Check that all references are valid:

• All BPMN process IDs in manifest exist in BPMN files
• All DMN decision IDs in manifest exist in DMN files
• All task references in resource-mapping exist in BPMN
• All target IDs in bindings are defined in targets

10.4 Test Scenario Execution

Run test scenarios against the UAPF Engine:

# Start the engine with your package
cd uapf-engine
npm run dev

# In another terminal, run tests
curl -X POST http://localhost:4000/uapf/execute-process \n  -H "Content-Type: application/json" \n  -d '{
    "packageId": "com.yourcompany.hr.employee-onboarding",
    "processId": "EmployeeOnboarding",
    "input": {
      "employeeData": {
        "name": "Jane Smith",
        "email": "[email protected]",
        "department": "Engineering",
        "role": "Software Engineer",
        "startDate": "2026-02-01",
        "manager": "[email protected]",
        "isRemote": false,
        "employmentType": "full-time"
      }
    }
  }'

10.5 Decision Table Testing

# Test individual decisions
curl -X POST http://localhost:4000/uapf/evaluate-decision \n  -H "Content-Type: application/json" \n  -d '{
    "packageId": "com.yourcompany.hr.employee-onboarding",
    "decisionId": "EquipmentAllocation",
    "input": {
      "department": "Engineering",
      "role": "Software Engineer",
      "isRemote": false
    }
  }'

# Expected output:
# {
#   "equipmentPackage": "ENGINEER_STANDARD",
#   "laptopSpec": "MacBook Pro 16"
# }

10.6 Validation Checklist

• Package passes schema validation
• All references are valid
• Happy path scenario executes successfully
• All decision tables return expected outputs
• Exception scenarios are handled correctly
• All end states are reachable

11.1 Push to ProcessGit

# Initialize repository
cd employee-onboarding.uapf
git init
git add .
git commit -m "Initial algorithmation of employee onboarding"

# Push to ProcessGit
git remote add origin https://processgit.org/yourorg/employee-onboarding.git
git push -u origin main

11.2 Configure UAPF Engine

Set environment variables for the engine:

# .env file
PORT=4000
UAPF_MODE=workspace
WORKSPACE_DIR=/path/to/your/packages
UAPF_SCHEMAS_DIR=/path/to/schemas

11.3 MCP Integration for AI Agents

With MCP exposure enabled in manifest.json, your process is available as tools for AI agents like Claude:

// Claude can now invoke:
// - execute_process("EmployeeOnboarding", {...})
// - evaluate_decision("EquipmentAllocation", {...})
// - evaluate_decision("AccessLevelDetermination", {...})

11.4 Production Checklist

• Package is in version control (ProcessGit)
• UAPF Engine is deployed and running
• Health checks are configured
• Logging and monitoring are enabled
• API authentication is configured
• MCP server is registered with AI agents
• Rollback procedure is documented

Algorithmation should produce measurable improvements. Define baseline metrics before deployment and track changes over time.

Algorithmated processes are operational assets. They must be governed with the same rigor as application code.

Versioning Rules

• Every UAPF package MUST use semantic versioning (MAJOR.MINOR.PATCH)
• Rule changes that affect outcomes increment MINOR or MAJOR
• Pure documentation or formatting changes increment PATCH

Change Approval

Audit Expectations

• Every released package must be traceable to an approved change
• Executed decisions must be loggable with input and output
• Historical versions must remain retrievable

With an explicit test harness and canonical resource ontology, algorithmated processes become portable, testable, and auditable artifacts. This ensures that AI agents execute governed logic, not inferred intent.

Summary

You've now learned the complete algorithmation workflow:

1. Select a high-impact process using the scoring framework
2. Discover the process through structured analysis
3. Model the workflow in BPMN
4. Define business rules in DMN decision tables
5. Map executors to tasks (humans, systems, AI agents)
6. Package everything into a UAPF artifact
7. Validate and test thoroughly
8. Deploy to ProcessGit and UAPF Engine

The result is an explicit, versioned, testable representation of your business process—ready for AI agents to execute with precision rather than guesswork.

Next Steps

• Download the Employee Onboarding UAPF package (example)
• Try Algomation Studio for visual modeling
• Explore ProcessGit for version control
• Read the UAPF Specification for advanced features