86 / COVERAGE / TASK VOLUME · TASK TYPES · PROCESS STEPS · WEIGHTED COVERAGE
86 / METRIC / EVALS · ANALYTICS · MANAGEMENT

COVERAGE.

Coverage — метрика глубины внедрения AI в реальную работу. Она показывает, какую долю eligible объёма задач, типов задач или этапов процесса AI действительно обрабатывает, а не просто сколько людей хотя бы раз открыли AI-продукт.

Главный принцип: Adoption отвечает «сколько людей пользуются?», Coverage — «сколько реальной работы проходит через AI?». Поэтому широкая пользовательская аудитория может сосуществовать с низким Coverage, и наоборот.
00. ARCHITECTURAL STATUS

WORK-PENETRATION METRIC

№86 = METRIC / DEFAULT N/A / SEPARATE COMPONENT N/A / Evals / Analytics / Management. Coverage измеряет глубину внедрения AI в eligible task volume, task types и process steps.
TYPEMETRICWork penetration / process depth.
DEFAULTN/AObserved, not enabled.
USE WHENAI TOUCHES REAL WORKScale, rollout, automation, use-case portfolio.
SEPARATE COMPONENTN/AAnalytics pipeline may be separate.
LIVES INEVALS / ANALYTICS / MANAGEMENTProduct + operations analytics.
VALUEDEPTH OF AI USEMeasure work, not only users.
01A. BOUNDARIES

WHAT COVERAGE DOES — AND DOES NOT — MEASURE

BOUNDARY WITH NEIGHBORS

№85 Adoption = share of eligible users using AI. Coverage = share of eligible work touched/handled by AI. №91 Autonomy = share of autonomy-eligible tasks completed without mandatory human. №88 Acceptance = usefulness of AI outputs. №87 Time Savings = human labor delta.

PREREQUISITES

Need task taxonomy, stable task identity, eligible-work rules, “AI handled” definition, process-step mapping and period/cohort dimensions. Without a work denominator, Coverage becomes a vanity count.

CONTROL / DATA / OFFLINE

CONTROL: eligibility and handling definitions, weighting rules. DATA: task/case/process events, use-case labels, AI involvement, completion outcomes. RUNTIME: emit task-level events. OFFLINE: aggregate volume/type/process coverage and diagnose gaps.

FAILURE CONTRACT

Failure = counting every model call as a covered task, using all company work as denominator, confusing AI touch with successful completion, weighting tasks opaquely, or increasing coverage by routing unsuitable work into AI.

DOES NOT OWN

Coverage says how much work AI touches. It does not prove that AI helped, succeeded, saved time, reduced cost or should be autonomous. Those require downstream metrics and quality guardrails.

01. FOUR COVERAGE VIEWS

VOLUME · TASK TYPE · PROCESS STEP · WEIGHTED VALUE

01 / VOLUME

Task Volume Coverage

Доля eligible task instances, где AI реально участвует.

AI-handled task instances / eligible task instances
02 / TYPE

Task-Type Coverage

Сколько из поддерживаемых категорий задач уже имеют рабочий AI-path.

AI-enabled task types / eligible task types
03 / PROCESS

Process-Step Coverage

Какая часть процесса поддерживается AI на уровне конкретных функций/этапов.

AI-supported process steps / eligible process steps
04 / WEIGHTED

Value-Weighted Coverage

Coverage с весами по time/value/importance.

Σ(weight × AI_handled) / Σ(weight × eligible)
Одна цифра Coverage почти всегда недостаточна. Volume отвечает “сколько работы”, Type — “сколько сценариев”, Process — “насколько глубоко”, Weighted — “какую долю ценности”.
02. PRIMARY FORMULA

TASK VOLUME COVERAGE

Task Volume Coverage =

AI-handled eligible tasks
-------------------------
all eligible tasks
× 100%

Example:

eligible tasks in week = 10,000
AI-handled tasks = 4,200

Coverage = 42%
Ключевой вопрос — что означает AI-handled: хотя бы коснулся? выполнил substantive work? produced accepted output? Это нужно определить отдельно.
03. “AI HANDLED” LEVELS

TOUCH ≠ SUBSTANTIVE ASSISTANCE ≠ COMPLETION

L0

No AI

Task completed without AI involvement.

L1

AI touched

AI provides minor suggestion, lookup or classification.

L2

AI substantive

AI performs material part of the work/output.

L3

AI completes

AI completes task, though human may review/approve.

Для основной Coverage лучше заранее выбрать один threshold, например L2+, а остальные уровни хранить как diagnostic slices.
04. TASK VOLUME vs TASK TYPE

DEPTH AND BREADTH ARE DIFFERENT

ScenarioVolume CoverageType CoverageInterpretation
AI handles one huge repetitive workflowHighLowDeep in one use case, narrow portfolio.
AI supports many rare workflowsLowHighBroad feature surface, low real work penetration.
High / HighHighHighBroad and deep deployment.
Low / LowLowLowEarly-stage or low-fit rollout.
05. ELIGIBLE WORK

THE DENOMINATOR MUST EXCLUDE WORK AI SHOULD NOT HANDLE

eligible_task if:

  task_type in supported_task_types
  AND policy_allows_AI = true
  AND required data is available
  AND task is within product scope
  AND not test / duplicate / synthetic
  AND not permanently manual-only
  AND task occurred during active rollout
Если high-risk task по политике всегда должен выполняться человеком, это не обязательно означает “AI-ineligible”. Он может быть eligible for assistance, но ineligible for autonomy. Coverage и Autonomy используют разные eligibility rules.
06. ASSISTANCE-ELIGIBLE vs AUTONOMY-ELIGIBLE

KEEP TWO POPULATIONS

AI-ELIGIBLE

Can AI assist?

Tasks where AI may lawfully/technically provide support.

AUTONOMY-ELIGIBLE

Can AI finish without mandatory human?

Usually smaller population constrained by risk/policy.

Coverage denominator:
  AI-eligible work

Autonomy Rate denominator:
  autonomy-eligible work

Do not use one denominator
for both metrics.
07. TASK TAXONOMY

COVERAGE NEEDS A STABLE WORK MAP

task_type:
  summarize_document
  research_question
  write_social_post
  classify_ticket
  analyze_contract
  generate_code_patch
  approve_refund
  browser_action

dimensions:
  business_process
  complexity
  risk_class
  frequency
  baseline_human_minutes
  AI_eligible
  autonomy_eligible
Task taxonomy is the backbone of Coverage. If task labels change every month, trend lines become meaningless without versioning/mapping.
08. PROCESS-STEP COVERAGE

WHERE IN THE WORKFLOW DOES AI ACT?

PROCESS:
  receive request
    ↓
  classify
    ↓
  research
    ↓
  draft
    ↓
  verify
    ↓
  approve
    ↓
  publish

AI support:
  classify   ✓
  research   ✓
  draft      ✓
  verify     partial
  approve    ✕
  publish    ✕

Simple process-step coverage:
  3.5 / 7 = 50%

But:
  not all steps have equal workload/value.
Process-step Coverage useful for architecture/automation planning; volume-based Coverage better for actual realized workload penetration.
09. WEIGHTED COVERAGE

ONE TASK MAY REPRESENT 30× MORE HUMAN WORK THAN ANOTHER

Weighted Coverage =

Σ(task_weight × AI_handled)
---------------------------
Σ(task_weight × eligible)

Possible weight:
  baseline human active minutes
  cost
  business value
  strategic importance

Example:

100 easy tasks × 1 min = 100
10 hard tasks × 30 min = 300

If AI handles all easy tasks only:

Raw coverage:
  100 / 110 = 90.9%

Time-weighted coverage:
  100 / 400 = 25%
Always show raw + weighted together. Weighted Coverage is more informative but easier to manipulate through weight design.
10. BASELINE-TIME WEIGHT

THE MOST PRACTICAL WEIGHT FOR KNOWLEDGE WORK

BASELINE

Estimate human active minutes per task class before AI.

WEIGHT

Use baseline median minutes as task value/effort proxy.

COVERAGE

Measure how much of total human-work potential AI touches.

This is especially useful when task counts are dominated by tiny repetitive actions but the valuable work sits in fewer complex cases.
11. REQUIRED SLICES

GLOBAL COVERAGE CAN HIDE GAPS

USE CASE

Task type

Find strong/weak AI scenarios.

RISK CLASS

Safety boundary

Coverage may be high in low-risk and intentionally lower in high-risk work.

TEAM / COHORT

Rollout

Adoption + process fit vary by organization.

COMPLEXITY

Easy vs hard

High overall Coverage may be driven only by easy tasks.

12. COMPLEXITY-ADJUSTED COVERAGE

ARE WE ONLY AUTOMATING THE EASY TAIL?

Coverage by complexity:

LOW:
  85%

MEDIUM:
  54%

HIGH:
  11%

Global:
  63%

Interpretation:
  broad metric looks healthy,
  but AI still barely covers
  high-complexity work.

Need:
  task complexity taxonomy
  + stable criteria.
13. TOUCH COVERAGE vs SUCCESSFUL COVERAGE

AI ATTEMPTED WORK MAY NOT MEAN AI DELIVERED VALUE

TOUCH COVERAGE

AI involved

Any substantive AI involvement.

AI-touched eligible tasks / eligible tasks
SUCCESSFUL COVERAGE

AI path succeeded

AI-handled tasks that reached successful product outcome.

successful AI-handled tasks / eligible tasks
ACCEPTED COVERAGE

Useful AI output

AI-handled tasks with accepted/verified outcome.

accepted AI-handled tasks / eligible tasks
Touch Coverage is product penetration. Successful/Accepted Coverage is much closer to realized value.
14. ATTEMPT RATE

HOW OFTEN AI IS TRIED WHEN ELIGIBLE

AI Attempt Rate =

eligible tasks where AI path was attempted
------------------------------------------
eligible tasks

Then:

AI Success Conditional on Attempt =

successful AI attempts
----------------------
AI-attempted eligible tasks

And:

Successful Coverage =

Attempt Rate
×
Success Conditional on Attempt
This decomposition distinguishes product/behavior gap (“nobody tries AI”) from capability gap (“AI is tried but fails”).
15. COVERAGE FUNNEL

ELIGIBLE → ATTEMPTED → AI-HANDLED → SUCCESSFUL → ACCEPTED

10,000 eligible tasks
   ↓ 70%
7,000 AI attempted
   ↓ 85%
5,950 substantive AI-handled
   ↓ 90%
5,355 successful
   ↓ 88%
4,712 accepted / verified

Metrics:

Attempt Coverage      = 70.0%
Handled Coverage      = 59.5%
Successful Coverage   = 53.6%
Accepted Coverage     = 47.1%
The funnel prevents teams from calling 70% “coverage” when only 47% of eligible work actually reaches accepted AI-supported outcome.
16. COVERAGE & ADOPTION

BREADTH OF USERS vs DEPTH OF WORK

Coverage HighCoverage Low
Adoption HighBroad + deep. AI is embedded into real workflow.Many users try AI, but only for a small fraction of their eligible work.
Adoption LowSpecialists/automation handle large task volume; user breadth is low.Early-stage or poor fit.
17. COVERAGE & ACCEPTANCE

DEPLOYMENT DEPTH vs USEFULNESS

Acceptance HighAcceptance Low
Coverage HighStrong candidate for scale. Check economics/autonomy next.AI touches too much work before quality is ready.
Coverage LowQuality is good; integration/adoption/opportunity remains.Low fit; improve capability before expansion.
18. COVERAGE & TIME SAVINGS

POTENTIAL ORGANIZATIONAL IMPACT

Potential saved human hours =
  eligible task volume
  × accepted coverage
  × average net human minutes saved
  / 60

Example:

50,000 eligible tasks/month
× 40% accepted coverage
× 5 net minutes saved
= 1,666.7 hours/month
Coverage scales per-task value. Time Savings still must be measured separately rather than assumed.
19. COVERAGE & AUTONOMY

AI MAY COVER A LOT OF WORK WITHOUT BEING AUTONOMOUS

COVERAGE

AI participates

Human may still review every task.

AUTONOMY

AI finishes without mandatory human

Only among autonomy-eligible work.

Example:

AI substantive coverage = 80%
Autonomy rate = 25%

This can be healthy:
  AI drafts/researches widely,
  but only low-risk cases
  are allowed to auto-complete.
20. COVERAGE & COST

HIGH COVERAGE CAN AMPLIFY BAD UNIT ECONOMICS

Coverage increases:
  20% → 70%

Cost per successful operation:
  $0.10 → $0.42

Eligible volume:
  1,000,000 tasks/month

AI direct cost:
  at 20% ≈ $20,000
  at 70% ≈ $294,000

If time/value uplift
does not scale accordingly,
high Coverage destroys ROI.
Never set Coverage as isolated north-star target. Pair with №90 Cost per Operation and №87 Time Savings.
21. COVERAGE GAP ANALYSIS

WHERE IS ELIGIBLE WORK STILL UNTOUCHED?

For each task_type:

eligible volume
AI attempt volume
AI handled volume
successful volume
accepted volume
average baseline minutes
risk class
main gap reason

Gap reasons:
  unavailable capability
  poor quality
  missing integration
  policy
  missing data
  user behavior
  cost
  latency
  unsupported language
  human preference
Coverage gap is a roadmap input. But “uncovered” does not automatically mean “should automate”.
22. OPPORTUNITY COVERAGE

HOW MUCH HIGH-VALUE WORK IS STILL AVAILABLE?

Opportunity Coverage Gap =

eligible high-value work
not currently AI-handled
-------------------------
all eligible high-value work

Useful ranking score:

opportunity_score =
  uncovered_volume
  × baseline_human_minutes
  × expected_AI_success
  × business_priority
  ÷ expected_cost
This is not a canonical Coverage formula but a practical roadmap heuristic for choosing the next AI use case.
23. COVERAGE BY PROCESS

PORTFOLIO VIEW

ProcessEligible volumeAI handledCoverageAccepted coverage
Customer support120k96k80%71%
Research15k8k53%47%
Marketing content4k3.6k90%78%
Contract review8k1.2k15%12%
This is far more actionable than one company-wide Coverage number.
24. MATURITY

FROM FEATURE PRESENCE TO ACCEPTED WORK

L0

No support

Task has no AI path.

L1

Available

AI feature exists but usage is optional/rare.

L2

Attempted

Meaningful fraction of eligible tasks enter AI path.

L3

Handled

AI performs substantive work at scale.

L4

Accepted

Large share of eligible work reaches useful/verified AI-supported outcome.

25. TARGET SETTING

100% COVERAGE IS USUALLY NOT THE GOAL

LOW RISK / REPETITIVE

High target

Coverage can approach majority of eligible volume if quality/economics support it.

HUMAN-CENTRIC

Moderate target

AI may support research/drafting while core judgment stays human.

HIGH RISK

Selective target

Coverage can be high for assistance, low for action/autonomy.

LOW VALUE

Maybe zero

Some eligible tasks are not worth AI cost/integration complexity.

Optimal Coverage is economic and risk-adjusted, not maximal.
26. COVERAGE ALERTS

WATCH MIX AND QUALITY, NOT ONLY TOTAL

ΔCOV

Coverage Change

Unexpected drop after release/integration failure.

ATT

Attempt Rate

Eligible work entering AI path.

SUC

Successful Coverage

AI path reaches successful completion.

ACC

Accepted Coverage

Useful/verified outcomes across eligible work.

CMP

Complexity Gap

High vs low complexity coverage difference.

RISK

Risk Mix

Coverage shifts into risk classes unexpectedly.

TOP

Use-case Concentration

One large workflow dominating global coverage.

WGHT

Weighted vs Raw Gap

Whether AI handles lots of low-value work only.

27. METRIC DEFINITION CARD

CANONICAL TASK VOLUME COVERAGE

Metric:
  Task Volume Coverage

Purpose:
  measure share of real eligible work
  receiving substantive AI assistance.

Numerator:
  eligible task instances
  with AI handling level >= L2

Denominator:
  all AI-eligible task instances

Exclusions:
  test/synthetic
  duplicate/replayed
  unsupported/manual-only
  outside rollout scope

Window:
  weekly / rolling 28d

Mandatory slices:
  task_type
  process
  risk_class
  complexity
  team/cohort
  product version

Companion metrics:
  Attempt Coverage
  Successful Coverage
  Accepted Coverage
  Adoption
  Acceptance
  Time Savings
  Cost per Operation

Owner:
  AI Product Analytics

Version:
  coverage_v1
28. EVENT MODEL

TASK-CENTERED COVERAGE EVENTS

{
  "event_id":"EVT-...",
  "event_type":"task_completed",
  "task_id":"TASK-...",
  "tenant_id":"...",
  "use_case":"research_question",
  "process":"marketing_research",
  "complexity":"medium",
  "risk_class":"low",
  "eligibility":{
    "ai_eligible":true,
    "autonomy_eligible":true,
    "eligibility_version":"v3"
  },
  "ai":{
    "attempted":true,
    "handling_level":"L2",
    "successful":true
  },
  "outcome":{
    "accepted":true
  },
  "versions":{
    "product":"2026.09.1",
    "workflow":"research-v4"
  }
}
Model-call events may be joined diagnostically, but Coverage should aggregate from task/process events, not inference logs.
29. MINIMUM DATA MODEL

ONE ROW PER REAL TASK

coverage_task(
  task_id
  tenant_id
  occurred_at
  task_type
  process
  complexity
  risk_class
  ai_eligible
  autonomy_eligible
  eligibility_version
  ai_attempted
  ai_handling_level
  ai_successful
  accepted
  baseline_human_minutes
  business_value_weight
  product_version
)
If one business task spawns 12 subagents and 40 tool/model calls, it should still usually count as one task in Coverage.
30. SQL-STYLE CALCULATION

RAW + SUCCESSFUL COVERAGE

SELECT
  COUNT(*) FILTER (
    WHERE ai_eligible
      AND ai_handling_level IN ('L2','L3')
  )::float
  / NULLIF(
      COUNT(*) FILTER (WHERE ai_eligible),
      0
    ) AS coverage,

  COUNT(*) FILTER (
    WHERE ai_eligible
      AND ai_successful
  )::float
  / NULLIF(
      COUNT(*) FILTER (WHERE ai_eligible),
      0
    ) AS successful_coverage

FROM coverage_task
WHERE occurred_at >= :start
  AND occurred_at < :end;
Authoritative computation belongs in SQL/code. LLM may explain gaps, not calculate official KPI from prose.
31. DATA QUALITY

COVERAGE FAILS IF ELIGIBLE WORK IS INVISIBLE

TASK CAPTURE

Denominator completeness

All eligible work must be observable, including work completed without AI.

CLASSIFICATION

Task taxonomy quality

Use-case/risk/complexity labels accurate enough for slicing.

AI INVOLVEMENT

Handling level

Consistent definition across product surfaces.

IDENTITY

No duplicates

Retries/subtasks do not inflate task count.

32. THE INVISIBLE DENOMINATOR PROBLEM

YOU CANNOT MEASURE COVERAGE IF YOU ONLY LOG AI TASKS

Suppose logs contain:
  5,000 AI tasks

But business system
does not emit non-AI tasks.

Then you know:
  AI task volume = 5,000

You do NOT know:
  Coverage.

Could be:
  5,000 / 5,500 = 91%

or:
  5,000 / 100,000 = 5%

Need denominator source:
  ticket system
  CRM
  document workflow
  ERP
  project tracker
  process database
Coverage often requires joining AI telemetry with the system-of-record that knows all work, including non-AI work.
33. PROCESS CONFORMANCE

MEASURE WHERE AI PATH ACTUALLY OCCURS

EXPECTED

Designed AI touchpoints

From BPMN/IDEF0/product spec.

ACTUAL

Observed task events

Which steps actually use AI in production.

GAP

Coverage mismatch

Designed automation exists but users/processes bypass it—or vice versa.

34. GOODHART'S LAW

MAXIMIZING COVERAGE CAN MAKE THE SYSTEM WORSE

ROUTE EVERYTHING TO AI
Coverage rises while quality/cost collapse.
QUALITY + COST GUARDRAILS
EASY TASK BIAS
Raw coverage looks high because trivial tasks dominate.
COMPLEXITY / WEIGHTED VIEWS
TOUCH = HANDLED
Minor AI lookup counted as full work coverage.
HANDLING LEVEL
ATTEMPT = SUCCESS
Failed AI paths inflate metric.
SUCCESSFUL / ACCEPTED COVERAGE
ALL WORK DENOMINATOR
Manual-only or out-of-scope tasks distort rate.
ELIGIBLE WORK
OPAQUE WEIGHTS
Strategic weighting becomes metric manipulation.
RAW + WEIGHTED + VERSIONED
ONE GLOBAL NUMBER
Low-performing processes/risk classes disappear.
MANDATORY SLICES
MODEL CALLS
Agent retries/fanout inflate workload penetration.
ONE REAL TASK = ONE UNIT
35. COVERAGE MATURITY QUESTIONS

FROM “DO WE HAVE AI?” TO “WHAT SHARE OF VALUE?”

QuestionMetric
Does this task type have an AI path?Task-Type Coverage
How many real task instances use AI?Task Volume Coverage
Where in workflow is AI used?Process-Step Coverage
How much baseline human effort is covered?Time-Weighted Coverage
How much eligible work reaches successful AI outcome?Successful Coverage
How much reaches accepted/verified outcome?Accepted Coverage
36. COVERAGE ROADMAP

EXPAND WHERE VALUE IS PROVEN

For each use case:

1. Eligibility volume
2. Current Coverage
3. Acceptance
4. Time Savings
5. Cost / success
6. Risk / autonomy boundary
7. Coverage gap
8. Integration effort
9. Expected uplift
10. Next experiment

Priority:
  high-value uncovered work
  with proven quality
  and sustainable economics

Not:
  highest uncovered volume
  regardless of fit.
37. PRACTICAL COVERAGE CARD

ONE USE-CASE VIEW

Use case:
  research_question

Eligible volume:
  8,400 tasks / month

Attempted:
  5,900
  → Attempt Coverage 70.2%

Substantive AI-handled:
  5,200
  → Coverage 61.9%

Successful:
  4,760
  → Successful Coverage 56.7%

Accepted:
  4,150
  → Accepted Coverage 49.4%

Acceptance conditional on AI success:
  87.2%

Baseline human minutes:
  18 min

Net time saved:
  9 min / accepted AI task

Potential realized time saved:
  622.5 hours / month

Risk:
  low/medium

Cost per success:
  $0.42
This one card already links penetration, quality and economics far better than “Coverage = 62%”.
38. MVP

MINIMUM TRUSTWORTHY COVERAGE SYSTEM

DATA

1. task_id
2. task_type
3. occurred_at
4. AI-eligible flag
5. AI attempted
6. AI handling level
7. AI successful
8. accepted / verified
9. risk class
10. complexity
11. product version

MVP METRICS

1. eligible task volume
2. Attempt Coverage
3. Task Volume Coverage
4. Successful Coverage
5. Accepted Coverage
6. Coverage by use case
7. Coverage by complexity
8. raw vs baseline-time-weighted coverage

GUARDRAILS

1. Acceptance Rate
2. Time Savings
3. Cost per Successful Operation
4. severe error / policy metrics
39. CHECKLIST

BEFORE PUBLISHING “COVERAGE = X%”

QuestionStatus
What is the real work unit?Required
Can we observe all eligible work, including non-AI work?Required
What exactly makes a task AI-eligible?Required
What exactly counts as AI-handled?Required
Are retries/subagents collapsed into one business task?Required
Is successful/accepted coverage shown beside raw coverage?Recommended
Are use case/risk/complexity slices available?Required for management decisions
Are weights transparent and versioned?Required if weighted coverage used
Is Coverage paired with quality/economics guardrails?Required for scale decisions
40. AI PROMPT TEMPLATE

COVERAGE ANALYTICS ASSISTANT

You are designing Coverage analytics for an AI system.

1. Define the real unit of work:
   task, case, document, ticket, transaction or process step.
2. Define AI-eligible work explicitly.
3. Ensure the denominator includes non-AI work from a system of record.
4. Distinguish:
   AI attempted,
   AI touched,
   AI substantive handling,
   AI completed,
   AI successful,
   AI accepted/verified.
5. Define the primary Coverage threshold.
6. Compute:
   Attempt Coverage,
   Task Volume Coverage,
   Successful Coverage,
   Accepted Coverage.
7. Add:
   Task-Type Coverage,
   Process-Step Coverage,
   Weighted Coverage where useful.
8. Segment by:
   use case,
   risk class,
   complexity,
   team/cohort,
   product/workflow version.
9. Keep AI-eligibility separate from autonomy-eligibility.
10. Do not count model calls, retries or subagents as separate business tasks.
11. Show raw and weighted metrics together.
12. Pair Coverage with:
    Acceptance Rate,
    Time Savings,
    Cost per Operation,
    risk/quality guardrails.
13. Compute official metrics in SQL/code.
14. Use LLM only to explain gaps or help classify taxonomy,
    never as the authoritative metric calculator.
41. PRACTICAL DECISION

WHAT TO BUILD

QuestionAnswer
Separate component?N/A. Coverage is a governed metric; analytics/event systems implement it.
Minimum 80% value?Task identity + eligible work denominator + AI handling level + raw/successful/accepted coverage + use-case and complexity slices.
When overkill?Prototype without a real repeatable task/process denominator.
Trigger?“How much of our work is AI actually touching?”, “Are we broad or deep?”, “Where is the uncovered opportunity?”.
How to measure uplift?Coverage expansion only counts as positive when acceptance, time savings, cost/success and risk guardrails remain healthy.
Can rules/code replace LLM?Yes. Eligibility and calculation should be deterministic. LLM may help classify task taxonomy/gap reasons if validated.
42. FINAL MAP

FROM ELIGIBLE WORK TO ACCEPTED AI-SUPPORTED WORK

ALL REAL WORK
  ↓
IN SCOPE?
POLICY ALLOWS AI?
SUPPORTED TASK TYPE?
  ↓
AI-ELIGIBLE WORK
  ↓
AI PATH ATTEMPTED?
  ↓
ATTEMPT COVERAGE
  ↓
AI PERFORMS SUBSTANTIVE WORK?
  ↓
TASK VOLUME COVERAGE
  ↓
AI PATH SUCCESSFUL?
  ↓
SUCCESSFUL COVERAGE
  ↓
OUTPUT ACCEPTED / VERIFIED?
  ↓
ACCEPTED COVERAGE

══════════════════════════════════

ALSO MEASURE:

TASK-TYPE COVERAGE
  how many scenarios?

PROCESS-STEP COVERAGE
  where in workflow?

WEIGHTED COVERAGE
  how much effort/value?

COMPLEXITY COVERAGE
  only easy tasks or hard too?

RISK-CLASS COVERAGE
  is expansion safe?

══════════════════════════════════

COVERAGE + ADOPTION

ADOPTION:
  how many eligible users?

COVERAGE:
  how much eligible work?

══════════════════════════════════

DO NOT COUNT:

MODEL CALLS
as TASKS

AI TOUCH
as SUCCESS

ATTEMPT
as ACCEPTED OUTCOME

ALL COMPANY WORK
as ELIGIBLE

AUTONOMY-ELIGIBLE
as SAME DENOMINATOR

══════════════════════════════════

THE CENTRAL QUESTION IS NOT:

“HOW MANY AI FEATURES
DO WE HAVE?”

IT IS:

“WHAT SHARE
OF THE REAL WORK
THAT AI COULD REASONABLY HELP WITH
IS ACTUALLY BEING HANDLED
BY AI —

AND HOW MUCH OF THAT
REACHES A SUCCESSFUL,
ACCEPTED,
ECONOMICALLY USEFUL
OUTCOME?”

ECC RETROFIT / PRACTICAL HARNESS INTEGRATION

A. Related ECC ideas. Context-as-cache, scoped memory, lifecycle hooks, selective capabilities, feature flags, deterministic enforcement, provider-neutral adapters and eval-gated learning are applied only where relevant to №86 Coverage.

B–E. Existing boundary and placement. The existing conceptual boundary, class METRIC, default N/A and owner Evals / Analytics / Management remain authoritative. Runtime/control/data/offline placement is unchanged; durable state stays outside model context.

F–H. Hooks and contracts. Use bounded PRE_MODEL/POST_MODEL, PRE_TOOL/POST_TOOL, CHECKPOINT and TASK_COMPLETED events as applicable. Illustrative fields and canonical contracts are defined in NEW_CONTRACTS_SPEC.md; no universal schema is implied.

I–J. Security and evaluation. Host-side schema, permission, secret, budget, idempotency and audit checks take precedence over LLM output. Optional mechanisms require a feature flag and WITH/WITHOUT ablation; measure quality, acceptance, correction, latency, cost, escalations and severe errors.

K–L. Task profiles and cross-references. A TaskProfile selects the relevant skill, tool/context slice, memory scope and enforcement profile independently from FAST/STANDARD/DEEP. See cross-reference map, hook spec and ablation plan. Provider adapters remain outside the core.