Documentation
Everything ARC Workflow Scanner checks, how it scores, and what it does with your data. If a finding surprised you, the rule behind it is on this page.
How the score is calculated
This is a Workflow Health Score, not a benchmark. It reflects only what was described in the submitted text, scored against a published rubric. A high score means few problems were detectable in the description — not that the process is efficient. A low score means the description contains specific, quoted evidence of friction.
Each dimension starts at 100. Findings deduct a fixed penalty by severity: critical −30, high −18, medium −9, low −4, info −0. Dimension scores are combined as a weighted average. Bands: 80+ strong, 60–79 adequate, 40–59 at risk, below 40 critical.
| Dimension | Weight | What it measures |
|---|---|---|
| Flow Efficiency | 3 | Starts at 100. Deducts documented penalties for each detected wait state, queue, and blocked handoff. A workflow with no detected waiting scores 100 on this dimension — which means we found no waiting, not that none exists. |
| Handoff Integrity | 2 | Starts at 100. Deducts for each ownership gap, unclear responsibility, and cross-team bounce detected in the described sequence. |
| Rework & Duplication | 2 | Starts at 100. Deducts for duplicate data entry, re-keying between systems, and rework loops. |
| Control Proportionality | 1 | Starts at 100. Deducts for approvals that gate low-risk work and for approval chains with no stated decision criteria. |
| System Coherence | 2 | Starts at 100. Deducts for each system boundary crossed manually and for fragmentation where one process spans disconnected tools. |
What the score is not
- A measurement of your actual cycle time, cost, or throughput
- A benchmark against your industry
- A guarantee that the recommended changes will produce savings
- A substitute for observing the work being done
Rule catalog (v0.2.0)
22 deterministic rules. No network, no model, no randomness — the same input always produces the same findings. Rule ids are permanent; a rule whose meaning changes gets a new id.
handoff
- WF-HANDOFF-001simplifyHandoff with no named owner
Name the receiving role explicitly and state the expected response time. An owner and an SLA turn an invisible queue into a measurable one.
- WF-HANDOFF-002simplifyWork bounces back to a previous team
Move the missing information or decision authority to the first touch. Ask what the second team knows that the first one needed.
- WF-HANDOFF-003simplifyAnonymous actor — 'someone' without a named role
Replace 'someone' with a named role. If two roles could do it, pick one as owner and the other as backup — dual ownership is no ownership.
- WF-HANDOFF-004simplifyHero dependency — the process stops when one person is away
Document the decision the person actually makes, then train a backup against that document. The person should be able to take leave without the process stopping.
rework
- WF-REWORK-001automateData is re-keyed between systems
Integrate the two systems, or if that is not viable, make one the system of record and generate the other. This is a deterministic automation opportunity — it does not need AI.
- WF-REWORK-002automateErrors restart the process from the beginning
Add validation at the point of entry so errors are caught where they are made, and allow resumption from the failed step rather than the first one.
- WF-REWORK-003simplifyA spreadsheet is functioning as the system of record
Move the state out of the spreadsheet and into a system with assignment and history, even a simple one. Keep the spreadsheet as a report if you must, not as the queue.
- WF-REWORK-004automatePaper, print, scan, or fax in the path
Replace the paper hop with a digital capture at the source. If a wet signature is a legal requirement, isolate that step; do not let it dictate the rest of the flow.
friction
- WF-FRICTION-001simplifyWork waits in a queue with no stated duration
Measure the wait before trying to remove it. A queue you can see is a queue you can argue about with data.
- WF-FRICTION-002simplifyEmail is used as a workflow system
Move the handoff into a system with a state, even a simple one. The goal is not a new tool; it is that the status of work is a fact rather than a question.
- WF-FRICTION-003simplifyStatus is obtained by chasing people
Make status a field the system already has, not a question a person has to answer. If you cannot point to the item without asking, the process is not observable.
- WF-FRICTION-004simplifyWork is held for a batch rather than processed when it arrives
Process items when they arrive unless you can name the constraint that forces the batch. 'We have always done it on Fridays' is not a constraint.
- WF-FRICTION-005simplifyA meeting is used as a workflow control
Take the decision out of the meeting. Publish the rule, auto-apply it to the default case, and use the meeting for the exceptions that actually need discussion.
- WF-FRICTION-006simplifyNo one can see where work currently sits
Give every item a current owner and a current state that anyone can read. Until that exists, every other improvement will be argued from anecdote.
control
- WF-CONTROL-001simplifyApproval with no stated decision criteria
Write the decision rule down. If the rule can be written down, most of the volume can be auto-approved and the human can handle exceptions — this is a simplification before it is an automation.
- WF-CONTROL-002simplifyThree or more sequential approvals in one flow
Count the distinct decisions, not the number of people who currently sign. Collapse sequential approvals that apply the same criterion, and keep a person only where a new judgment is added.
- WF-CONTROL-003simplifyEvery item requires approval, with no stated exception path
Put a threshold on the approval. Route the routine volume around the person and keep them on the cases where the decision is actually a decision.
systems
- WF-SYSTEMS-001automateSystems that do not exchange data
Cost the integration against the fully loaded cost of the manual bridge including its error rate. This comparison is usually decisive and is rarely made.
- WF-SYSTEMS-002simplifyThe same process spans four or more named systems
Name a system of record for this process and make the others read from it. Adding an nth tool will not fix a flow that already has too many.
- WF-SYSTEMS-003simplifyThe process lives in tribal knowledge rather than a system
Write the current path down with the people who do the work, then run against the document, not against memory. Do not automate a process you cannot yet describe.
ai-candidate
- WF-AI-001augment-with-aiJudgment step that may warrant AI augmentation
Before automating with AI, confirm the step is high-volume, that errors are recoverable, and that a human reviews low-confidence cases. If the step is low-volume, fix the process instead.
human
- WF-HUMAN-001keep-humanStep that should remain human
Keep a human here. Automate the preparation around the decision — gather the context, draft the options — but leave the decision itself with a person.
API
Everything the web UI does is available over HTTP. No key, no account. Please keep it to a few requests a minute — the rate limiter will tell you if you do not.
POST /api/assess
Content-Type: application/json
{
"text": "your description here (40–40,000 characters)",
"context": { "industry": "logistics" },
"useModel": false
}
→ 200 AssessmentResult (findings, evidence, score, recommendations, blueprint, limitations)
→ 400 { "error": "..." } input failed validation
→ 429 { "error": "..." } rate limited
GET /api/rules the catalog above, as JSON
GET /api/health { status, version, rulePackVersion, ruleCount }Data policy
The text you submit is processed in the request and discarded when the response is sent. It is not written to a database, not used for training, and not sent to a model provider unless you explicitly opt in to the optional narrative pass. Errors are logged with the content redacted.
Email is collected only if you ask for a copy of a report. Assessment never requires it. The full policy is in docs/05-data-policy.md.
Everything else
The complete build package — product brief, PRD, architecture, threat model, evaluation plan, runbook — is in the repository. The roadmap is public and the issue tracker is open.