# v32 scoring method note This package adds an expanded-coverage layer for four separate axes: 1. **Workflow compressibility** 2. **Decision criticality** 3. **Reasoning-demand potential** 4. **Company control** These scores are **modeled prioritization outputs**, not observed outcomes. ## Why a new layer was needed The earlier benchmark was strongest on exposure and deployability. It was weaker on: - how much value a decision can create or destroy - how much recurring model usage a workflow could generate - whether the key outcome is controlled by the company or by an external party The v32 layer separates those ideas instead of collapsing them into one score. ## Definitions ### Workflow compressibility How plausibly current AI can compress the prep stack around a role or workflow. Built from: - task exposure (primary input in v32) - adoption feasibility - analyst adjustment (14 rows) and direct analyst assignment (100 rows) > **v32 implementation note:** In v32, compressibility is derived primarily from `task_exposure_v1` (290 of 404 rows), with analyst adjustment on 14 rows and direct analyst assignment on 100 rows where `task_exposure_v1` was not available. The aspirational four-component formula (adding `workflow_standardization` and `template_density`) is a v33 target. See implementation disclosure below. ### Decision criticality How much value can be created or destroyed by the judgment. Built from four modeled subcomponents: - upside optionality - downside severity - authority level - irreversibility ### Reasoning-demand potential How much recurring model usage the workflow could generate once instrumented. Built from: - task exposure - adoption feasibility - refresh frequency - evidence volume - branching factor - persistent monitoring need - company control ### Company control A zoning layer intended to stop overclaiming. Zones: - **Company-controlled** — the loop is substantially inside the organization’s control - **Semi-controlled** — the company can compress preparation but not fully control the external outcome - **Externally governed** — the key outcome depends heavily on a regulator, lender, auditor, insurer, or other counterparty ## Important caution The company-control layer is intentionally from the perspective of the focal asset owner / operator / sponsor. A regulator-side reviewer may personally control their own work, but from the operator’s perspective that loop is still externally governed. ## How subcomponents were estimated The subcomponents were built from: - existing numeric benchmark fields - workflow-type heuristics - sector / role keyword adjustments This is transparent but not faux-precise. It should be treated as a decision-support layer for prioritization. **Implementation disclosure:** The composite compressibility formula (task exposure × 0.40 + adoption feasibility × 0.30 + workflow standardization × 0.15 + template density × 0.15) is **not operative in v32**. It is a target for v33. In v32, compressibility is derived from `task_exposure_v1` alone for 290 of 404 rows (where `compressibility_score` = `task_exposure_v1` exactly), with analyst adjustment on 14 rows and direct analyst assignment on 100 rows where `task_exposure_v1` was not available. The columns `workflow_standardization` and `template_density` are not present in the v32 CSV. This means the v32 compressibility score is effectively a single-factor measure, not a four-factor composite. See the methodology FAQ for details. ## How to use these scores Use them to sort into four buckets: - high compressibility / low criticality → automate for cost - high compressibility / high criticality → compress the stack, keep human signoff - low compressibility / high criticality → augment carefully - low compressibility / low criticality → low priority Then layer **reasoning-demand potential** and **company control** on top to find the best initial beachheads. ## Data coverage in v32 CSV All 404 positions (373 roles, 24 workflows, 7 artifacts — tagged via the `row_type` column) carry a **workflow compressibility score** (the primary heatmap score). 304 of 404 positions carry the augmented axes: **decision criticality**, **reasoning-demand potential**, and **company control score/zone**. The remaining 100 positions were added after the augmented scoring pass and have empty augmented columns. **Company control column note:** The v32 CSV contains one company-control column: `company_control_zone`. The shipped CSV uses a prep-work-oriented definition (who controls the filing/workflow — e.g., rate cases are "Company-controlled" because the utility controls its own filings and prep work, even though the PUC controls the final ruling). An earlier scoring pass considered an outcome-oriented definition that would reclassify some rows (e.g., rate cases as "Semi-controlled" because the PUC controls the ruling). That alternative pass is not included in the v32 CSV; reconciliation is a v33 deliverable. Where doc-level prose and the CSV disagree on a specific row's zone, the CSV value is canonical. 30 anchor positions carry three additional axes from the interactive exhibit: **automation exposure**, **value creation**, and **asymmetric risk**. Employment estimates: 60 positions use BLS/industry-sourced figures; 344 are algorithmically estimated from layer base values with explicit tier bands (0.75×/1.0×/1.25×, assigned by stable hash of role name; flagged in the `employment_source` column). Compensation: `layer_median_comp_proxy` is a single BLS-derived median per layer, not role-specific. ## What this still does not do This model still does **not** claim to measure: - realized enterprise value - realized token usage - real labor reductions - real approval-speed changes - real spread compression - regulator or lender behavior Those remain either future measured work or scenario logic.