The workflow score

How deep and connected the seller's business processes are in the delivered data: can a buyer follow an order from quote to payment across systems? Built in the package (workflow/), run by the reference runner (jobs/workflow.py) at the end of a scrub. Off by default: it runs only when the claim asks for it (workflow: true or a systems map), which also turns on business-id tokenization for the deal.

Business-object graph

A record is one table row, JSON object, or mail or chat message, tagged with the system it came from. Systems: the claim's map (longest raw path prefix wins), else one per database or platform source, one for mail and chat, and one per top-level item for uploads and buckets. Labels stay on the machine; reports number systems s1, s2, ... by record count.

Business objects are the business-id tokens in a record (internal and public classes from bizids.json), plus conversations (a mail or chat thread). Parties (person stand-ins), SKUs and actors ride along for the event log but never join objects. Objects in one record are related.

Case: a connected group of related business objects (union-find), containing at least one business object (a thread alone isn't a case), followed across every system its records came from. Hubs: an object related to more than 200 others links nothing, and a record carrying more than 200 links is skipped, so one catch-all project or digest mail can't fold a deal into one case.

Trace: a case's timed events sorted by time then activity:

• one per time column a row has whose name says what happened (paid_at → paid; bookkeeping and planned dates such as updated_at or due_date make none; a bare date is recorded; an unrecognized name is other);
• one per terminal status value (status: shipped), timed at the row's latest time, unless a time column already gave that activity;
• one per message (email or chat), plus outcomes a message states in words ("payment received"), which are marked not machine-checkable.

Times parse from ISO dates and datetimes, US m/d/Y, and epoch seconds or milliseconds between 2000 and 2100.

• Hub cut-off: an object related to more than 200 others links nothing. At most 3,000,000 linked records per run; traces cut at 64 steps.
• Activities from time columns: approved, assigned, cancelled, churned, closed, completed, created, delivered, disputed, escalated, failed, invoiced, lost, opened, paid, received, refunded, rejected, reopened, resolved, returned, sent, shipped, signed, started, submitted, won, plus recorded (a bare date) and other.
• Time columns that never make an event (any token): accessed, birth, born, cached, changed, deadline, deleted, dob, due, effective, estimated, eta, etl, expected, expiration, expires, expiry, exported, imported, indexed, last, loaded, login, modified, next, period, planned, removed, renewal, renews, scheduled, seen, sync, synced, trial, until, updated, valid, viewed.
• Terminal statuses: approved, cancelled, churned, closed, completed, delivered, disputed, escalated, failed, lost, paid, refunded, rejected, resolved, returned, shipped, won.
• Outcomes (activity → outcome type): paid → paid, delivered → delivered, resolved → resolved, closed → resolved, completed → resolved, refunded → refunded, cancelled → cancelled, returned → returned, won → won, lost → lost, churned → churned.
• Exceptions: cancelled, disputed, escalated, failed, refunded, rejected, reopened, returned.
• Outcomes read from message text (not machine-checkable): refunded, delivered, paid, resolved, cancelled.
• OCEL relations: up to 20 object-to-object relations per object.
• Breadth nudge order: finance, sales, support, supply_chain, operations, hr.

Business-id canonicalization

bizids.py finds ids in named columns and free text (a class word or a known prefix next to an id-shaped value) and gives each object one token, [<LABEL>_<10 hex>], over its canonical core: a short letter prefix, #, separators and leading zeros removed, so SO-001234, #1234 and Order 1234 are one order. Classes sharing a number share the hex; the label keeps them apart and the graph joins on both. The hex is an HMAC of the core under the deal salt, or a random token from the identity map under random stand-ins.

The format map decides only what free text is recognized, never what a token is: the defaults below, the deal's own formats from the claim, and prefixes learned from the deal's id columns after a few sightings. Learning mid-job can't split an object; ids missed before a prefix was learned show up in linkage kept. Learned prefixes never leave the machine.

bizids.json 1.0.0. Functions: sales, finance, operations, support, supply_chain, hr. A prefix is learned from a deal's id columns after 2 sightings.

Metrics

All from workflow.score.metrics. (n) is the number of cases. Ranges are the nearest-rank median and 90th percentile: for sorted values (v_1 \le \dots \le v_m), (p_q = v_{\lceil q m \rceil}), reported with (m). Shares are reported with their denominator.

Linkage kept

Joins before the scrub against joins after it, on the same files. The raw pass reads the raw files (links only, in memory) using raw (class, core) pairs as objects; the clean pass reads the delivered files using tokens. Basis: cross-system joins (multiSystem) when the raw data has any, else any join (joined).

[ \text{kept} = \min\left(1, \frac{\text{clean}[\text{basis}]}{\text{raw}[\text{basis}]}\right) ]

met is kept at or above the target in bands.json. The raw pass has a 4 GiB budget; files beyond it are skipped and the result says sampled: true. No joins before the scrub: kept is null with the reason.

Sampling, ranges and confidence

The clean pass reads every delivered table, JSON, NDJSON, mail and chat file, up to 3,000,000 linked records (records.truncated past that); single JSON documents over 256 MiB are skipped. Ranges and shares carry their sample sizes; no confidence intervals are computed. A share over a small denominator is withheld (below), not qualified.

Bands

workflow/bands.json 1.0.0: at least 11 cases to score; counts under 11 withheld; linkage-kept target 0.95; an episode needs 3 steps, 2 systems and an outcome.

Every listed threshold is metric >= value; – means the band doesn't test that metric. Confidential-deal buckets:

band is the first band, top to bottom, whose every listed threshold holds (metric >= value, null fails). Under the minimum case count the band is "Not measured" with reason "too few cases"; when none applies, "Not measured" with "no band applies".

OCEL 2.0 export

clean/__workflow__/ocel.json.gz, written as chunks through the residual gate like every delivered byte (a hit holds it), next to metrics.json (the privacy pass's copy below). JSON following the OCEL 2.0 JSON format:

Object ids are the stand-ins the delivered files already use (ORDER_<hex>, [ID_<hex>], user_<hex>@...invalid, or the actor's stand-in); conversations are conversation_<n>. Activities come from the fixed vocabulary only, never from headers or values. Events are emitted in record order, only those with a time. Times are what the scrub left, so under deal_offset they're shifted like the delivered files.

Estimate model

Estimate v2 is not built. Nothing in this package or the reference runner computes a pre-scrub estimate of the workflow score. One control plane has a v1 estimate from what the seller declares in a form, not from data; it has no calibration against measured scores. Calibration status: none. Not live.

Privacy controls

workflow.score.private makes the only copy that leaves the runner (scrub report, buyer summary, bundle):

• counts and samples under 11 are withheld (null); system pairs, outcome types and functions under 11 are dropped;
• systems are numbered with their function, never named; activities and outcomes come from a fixed vocabulary;
• confidential deals get buckets only (edges above): no pairs, no per-system rows, no outcome types, no function names;
• linkage kept over fewer than 11 joins is withheld with "too few joins to report".

The raw pass keeps only object keys in memory for the run; nothing raw is written.

Known limitations

• Some id formats in free text are only partly recognized (coverage row hipaa.R).

• Hubs are dropped wholesale, so a genuinely central object (a big account's master project) links nothing.
• Activity names come from column names; a column named in the seller's own terms (zeta_at) becomes other.
• A status event takes the row's latest time, which may be an update time rather than when the status happened.
• Under dates: year (Safe Harbor) dates become bare years, which don't parse as times: traces lose their timed events and depth metrics are near zero. Inferred from the code, not measured.
• No confidence intervals; no check that the same buyer can reproduce a figure from the OCEL file beyond the shared code path.
• Machine-checkable means the outcome came from a structured field, not that it was verified against anything.