infer_readiness
Measure organisational readiness from process data, so the investment case does not depend on an untested maturity claim. CALL THIS before score_initiative, score_portfolio or calculate_pace_layer_drag when the user can provide at least two of five signals: hand-offs, rework, touch ratio, automation level and cycle time. function selects the comparison medians for hand-offs and cycle time; more signals increase confidence and disagreement between them reduces it. claimed_readiness is optional, but pass it when the organisation has declared itself agile, traditional or siloed, because the returned gap exposes where its self-image runs ahead of the process data. Fewer than two signals produces a refusal, not a guess. Pass the measured readiness into the downstream tool, then use diagnose_process when the next question is what to change in that process. Pure deterministic calculation, no network, auth, or side effects.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| function | Yes | Business function the process belongs to. Selects the disclosed AI BVF cycle-time and hand-off reference points used to interpret the signals. Call list_taxonomy if unsure. | |
| handoffs | No | Distinct owners or systems an instance passes through. Read against the function median: 1.5x or more the median reads siloed, at or above the median reads traditional, below it reads agile. | |
| rework_rate | No | Fraction of instances reopened or reworked (0-1). 15% or more reads siloed, 5-15% traditional, under 5% agile. | |
| touch_ratio | No | Touch-time divided by cycle-time (0-1); the remainder is waiting. Under 0.15 reads siloed (the process lives in queues), 0.15-0.4 traditional, above 0.4 agile. | |
| cycle_time_days | No | Median wall-clock days per instance. Read against the function median, same bands as handoffs. | |
| automation_level | No | Share of the process already automated (0-1). Under 0.2 reads siloed, 0.2-0.5 traditional, above 0.5 agile. | |
| claimed_readiness | No | Optional. What the organisation says about itself. The measured result is compared against it and the gap returned as readiness_gap plus a gap_finding, because an organisation whose self-image runs ahead of its process data has just told you where the change work starts. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| audit | No | Reproducibility record: engine version, the rules that fired, and the resolved inputs. Deterministic, no timestamps. If the verdict is challenged months later, the same inputs on the same engine version reproduce it exactly. | |
| guidance | Yes | How to use the result downstream, including what a gap between measured and self-reported readiness means. | |
| readiness | Yes | The readiness classification the measured signals support. | |
| confidence | Yes | Confidence 0-100, set by signal coverage (2 signals ~45, 5 signals ~90) and discounted when signals disagree. | |
| bvf_version | Yes | AI BVF protocol version used. | |
| gap_finding | No | The claimed-versus-measured gap read as a change-readiness finding. Surface verbatim when present. | |
| disagreement | No | Present when signals point in opposing directions: readiness is uneven across the process, read the per-signal detail. | |
| signal_reads | Yes | Per-signal read: the value, which readiness it leans toward, and why in plain language. Show these to the user. | |
| signals_used | Yes | How many of the five signals were provided. | |
| readiness_gap | No | Ordinal distance claimed-to-measured. Positive: the organisation claims better than it measures. | |
| readiness_basis | Yes | Always measured: this came from process data, not self-report. | |
| claimed_readiness | No | Echo of the claim, when supplied. |