Skip to content
MirrorFirm

What evaluation hooks and scoring functions could an allocation task pack expose?

A task pack can expose task records, separate labels and named scorers, while an environment adds reset and state export, so buyers can reproduce scores and replay failures.

A task pack for allocation can expose scoring as a function you call, so your customers get the same result you did.

A task record could contain:

- `task_id` and `task_type` (for example single match, split across invoices, hold for review) - `input_refs`: identifiers of the payment, remittance and candidate obligations visible to the system - `policy_ids`: policies the system may cite - `expected`: held in a separate labels file, as lines of `obligation_id` and `amount_applied`, or a hold with a reason code - `scorer`: the name of the scoring function

Useful scoring hooks:

- **Exact allocation:** the set of obligation and amount pairs matches. - **Amount tolerance:** differences within a stated policy tolerance are accepted. - **Hold correctness:** the system holds when it should and not otherwise. - **Policy citation:** the cited policy matches the one that applied. - **Harm check:** any allocation that clears the wrong party's obligation is flagged separately from a near miss.

For simulated environments, ask for `reset(seed)` to restore payments, obligations and balances to the starting state, plus `get_state()` for comparing end state to the expected one. Tool actions might include `search_open_items`, `view_remittance`, `apply_payment` and `escalate`. Record each call in a trace file so failures can be replayed.

Confirm the hook names and return formats during a pilot, then pin them to the release version.

Ask for named scorers, a reset call and trace logs, so customers can reproduce your scores and replay any failure.

Audience:
Licensed resellers
Content type:
Integration
Buyer question:
How to evaluate it

Content release: r-a220eb6e099b243b

More on Payment allocation