JTBD-LI-09 · Lead Intelligence & Routing
Reproduce a historical routing decision exactly
partially supported. Part of the job works and is proved; the rest is named rather than implied. Read what is excluded before planning around it.
What the catalogue records
runs persist model/policy identity + declared fingerprints, target-set fingerprint, per-target evaluation evidence (in/out, reason, load, capacity, priority) and fingerprints of the mutable lead inputs — but mutable lead-field VALUES are fingerprinted, not copied, and no automated re-execution harness exists
Evidence
This row carries no test path of its own in the structured index. The matrix records the evidence for it in a block shared with neighbouring rows, which jobs.json does not split per row — so read docs/benchmarks/CRM_JTBD_MATRIX.md for it. The status above was set from that evidence, not from its absence.
What this status does not mean
A status here describes this repository at this commit, nothing more. It is not a statement about what a CRM should do, and it is not a roadmap commitment. The whole framework is local-development-only: there is no authentication, tenancy or RBAC, so no status on this page implies you can deploy it. The boundaries are listed in full on the claims ledger.
Other jobs in Lead Intelligence & Routing
- Enrich a Lead from external sources with snapshot + provenance — validated end to end
- Calculate an explainable lead score — validated end to end
- Prioritize Leads by score — partially supported
- Route a Lead automatically under a published policy — validated end to end
- Use sales capacity and availability in routing — partially supported
- Manually reassign with permission and reason — not supported
- Version and publish a scoring/routing policy — validated end to end
- Roll back a policy to an earlier version — partially supported
All 9 jobs in Lead Intelligence & Routing · the whole catalogue