Design Status: Released v0.1.0

Workflow Decomposer

Break a fuzzy business process into steps a system can actually automate, and mark the ones it cannot.

Runs in your browser. Nothing you enter is sent to a server, and nothing is stored unless you save it to this device.

One line describing what this process is supposed to produce.

What the process starts with, stated once for the whole process.

Limits or rules that bound the whole process, not any single step.

Actors

No owners stated yet.

Derived from the owner stated on every step below. Add or edit an owner to change this list.

Awaiting input

No steps yet

Add a step, or load a sample process to see the classifier and the priority order work on something real.

Classification

Every step, classified from the properties above. Each result states the single property that decided it.

Idle

Stale Inputs changed after this result was produced. Run it again to see numbers that match what is on screen.

Completeness

Every step needs an owner and completion evidence. A step whose doneness cannot be evidenced cannot be automated or delegated reliably.

Idle

Stale Inputs changed after this result was produced. Run it again to see numbers that match what is on screen.

Structural issues

Cycles, orphan steps, and dependencies that point at a step which no longer exists. A step may depend on more than one other step, so this is checked as a real graph, not a chain.

Idle

Stale Inputs changed after this result was produced. Run it again to see numbers that match what is on screen.

Handoffs

Every edge where work crosses from a system to a person or back. Real workflows break at these crossings.

Idle

Stale Inputs changed after this result was produced. Run it again to see numbers that match what is on screen.

Silent failure risks

Steps that feed later steps but whose own result nothing checks.

Idle

Stale Inputs changed after this result was produced. Run it again to see numbers that match what is on screen.

Approval points

Steps where a person decides something before the process can rely on it: the human side of a handoff, a checkpoint, or a fully human step.

Idle

Stale Inputs changed after this result was produced. Run it again to see numbers that match what is on screen.

Implementation order

Which automatable steps to build first, ranked by frequency times mistake cost, minus a risk penalty.

Idle

Stale Inputs changed after this result was produced. Run it again to see numbers that match what is on screen.

    Scoring weights

    Every value below is stated, not hidden.

    Rare frequency weight
    1 from fixed heuristic fixed
    Monthly frequency weight
    3 from fixed heuristic fixed
    Weekly frequency weight
    8 from fixed heuristic fixed
    Daily frequency weight
    20 from fixed heuristic fixed
    Low mistake cost weight
    1 from fixed heuristic fixed
    Medium mistake cost weight
    4 from fixed heuristic fixed
    High mistake cost weight
    10 from fixed heuristic fixed
    Risk penalty unit
    3 from fixed heuristic fixed
    Export
    Agent Designer handoff
    Note Why does the same step sometimes stay human and sometimes not?

    Four rules run in order, and the first one that fits decides the step. If nothing checks a step's result and no person looks at it either, the step needs redesign before anyone can perform it. If it cannot be undone and cannot be verified, it stays human, no matter how often it runs. If it carries legal or financial exposure with no undo path and a costly mistake, it stays human. If it needs a judgment call on input with no fixed shape, it stays human. Everything left over gets automated, sometimes with a checkpoint when a softer version of one of those concerns is still present.

    A checkpoint step still counts as system performed when this tool looks for handoffs, since a person only signs off rather than doing the work. The crossings worth worrying about are the ones between a system and a fully human step.

    Note Why does the implementation order ignore how important a step feels

    Frequency times the cost of a mistake is the actual signal, not how much the step matters in conversation. A step that runs rarely and carries legal or financial exposure gets a penalty subtracted from its score, even when it is automatable, because rushing to build the riskiest, least common case first is a poor use of the first thing you ship.

    Note What does the Agent Designer handoff actually do

    It downloads a JSON file naming every step classified automate now or automate with a checkpoint as a candidate, with its owner, its completion evidence, plain language limits drawn from its own properties, and the escalation paths where a candidate's work reaches a person. That is the whole handoff.

    Nothing here calls Agent Designer directly, and nothing in Agent Designer calls this file either. You carry the download over yourself. That is what an explicit export means, as opposed to hidden coupling between the two tools.