the mapping layer

Process intelligence

Duvo's stated doctrine is to map the real process first — via AI screen-share interviews, re-runnable, with a costed business case attached — and never automate a broken one. process_mapping is the evaluation counterpart to that mapping layer: it doesn't do the interviewing, but it proves what a mapping layer has to get right before anything downstream is allowed to trust it — reconstruct the real workflow from messy multi-source fragments, correctly separate what's safe to automate from what isn't, and never mark a broken step ready.

From the record. Before this pack existed, the same discipline was a job: inheriting a fully manual multi-system operation — spreadsheets, supplier portals, email, and an ERP, worked by hand across all four — and consolidating it into a single structured working layer before automating anything on top of it. Improve first, then automate; the pack encodes the same ordering as a hard gate instead of a judgment call.

The task the agent is scored on

Each process ships as a set of messy, conflicting fragments — email threads, spreadsheets, portal clickpaths, tribal notes — each carrying STEP-## anchors, real evidence, and deliberate distractor steps that belong to a different flow. The tools return fragments only: no step count, no system list, no disposition, no gold label. Reconstructing the workflow graph — which steps are real, which system owns each one, how they hand off, and which are safe to automate — is the agent's work, graded against a gold answer key it never sees.

Metric	Cases	What it proves
process_inventory	2	the catalog itself — count and full id set
step_extraction	4	real STEP ids from fragments, distractors dropped (set-F1)
system_coverage	5	which systems a process touches, and which owns a given step
fix_before_automate_flagging	6	FBA vs. automation-ready disposition, with reason code
handoff_identification	4	ordered step-to-step edges and the system that carries each
ready_to_automate_safety (hard gate)	4	never mark a broken (FBA) step safe to automate

Every expected value is computed from the gold fixture, not hand-authored — a drift guard (test_case_expectations_match_gold) recomputes the full expectation set from the answer key and asserts it against the committed cases. Reproduces keyless via replay: uv run agentic-eval eval --domain process_mapping --backend replay → 25/25.

The disposition that matters

The load-bearing judgment isn't step extraction — it's the fix-before-automate call. A step is either AR (automation-ready) or FBA (fix-before-automate, with a reason code: UOM ambiguity, no single source of truth, a judgment call, or a data gap). The ready_to_automate_safety hard gate fails the case outright if the agent proposes an "automate now" set that includes any FBA step — the direct analogue of "we never automate a broken process": the gate doesn't grade whether the agent found a good workflow, it grades whether the agent would have shipped a broken one.

Where the eval's discipline goes next

Feeds the connector layer

An AR step is what a Duvo-style connector is allowed to wire; an FBA step stays a human task until its reason code clears. See Automations.

Feeds the deployment kit

Per-customer, the exception-spec DSL is where an FDE encodes which steps are actually AR for that customer — the DSL's decision rules are the mapping layer's output, made editable. See Deployment.