hammer-coverage-navigate
Scope: world hammer-coverage-intelligence vintage 2026-10-01
Revision SHA-256: 9c5f5fa7a922d1f65791747a95dce4e6713114516b2485d8f19bc7b0f946c706

---
name: hammer-coverage-navigate
description: Use when routing a coverage question to the tool that answers it, when you hold a GOAL rather than a question and do not yet know what to ask, or when deciding what this corpus does and does not license you to write. Opens with frontier, the tool that takes a goal in your own words plus the claims it rests on and routes each leaf to one of four places, settled here naming the tool, settled elsewhere naming a corpus in the register, yours to declare because your own book is a fact no corpus holds, or refused permanently together with the nearest question this world does answer. Then a routing table from what an operator is actually asking to the tool that serves it, covering payer rates (rate_position), the same rates for several codes under one receipt so a comparison can be checked (rate_comparison), code pairs against the Medicaid NCCI edit file (stack_check), who a payer's own policy says may furnish and interpret a code (interpretation_requirement), how the Medicare fee schedule splits a code into its professional and technical components (fee_components), what a hospital filed for an inpatient admission under 45 CFR 180, kept apart from payer rates because a charge is not a rate (filed_charge), headcounts and modelled prevalence with their measurement class (cohort_figures), published observational associations, MASLD or blood pressure, one record at a time (prognostic_association), randomised trial effects kept in a separate tool so no call can ask for one of each (treatment_effect), and the calculators that read no data at all (screening_yield, deferred_versus_avoided, regression_to_mean_expectation, competing_event_coupling). Explains the source register that knowledge_navigate reads, why an available source is different from an absent one, and why a register entry can never yield a figure. Names the refused questions with their cannot_answer entries. Covers the traps this corpus invites: percent-of-charge and phantom rows behind the quality filter, professional against technical against global, a rate is not coverage, cross-payer averaging without the operator's own payer mix, the two clocks, and the Medicaid-against-Medicare NCCI edition gap. Explains why positive predictive value collapses at low prevalence and why a deferred cost and an avoided cost are never summed. Every answer closes with the claim report defined in hammer-worlds.
---

# hammer-coverage-navigate

## What this corpus is

What payers publish that they pay, code by code, for a closed list of billing
codes and payers, read on one date. Around that: which pairs of those codes the
Medicaid NCCI edition says may not be billed together, what the Medicare
Physician Fee Schedule states about how a code splits, what Medicare Local
Coverage Articles say about who may furnish and interpret one, headcounts and
modelled prevalence per geography, and published effect sizes linking MASLD to
later outcomes. Alongside the data compartments sit health-economics
calculators that read no data at all: `screening_yield`,
`deferred_versus_avoided`, `regression_to_mean_expectation`,
`competing_event_coupling`, `withhold_earnback`, `tournament_position` and
`measure_reliability`
compute straight arithmetic over numbers the caller declares. Beside the data compartments sits a knowledge compartment that holds
no measurements at all, only a register of what the upstream shelf carried when
this world was built.

**`tools/tools.json` is the authority on what exists and what it takes.** Each
description carries the closed vocabularies (codes, payers, outcomes, strata)
and the refusal kinds, and the calling agent reads them before every call. This
file is routing and traps; that is the reference. Do not restate its counts or
its vocabularies here, because a copy of a list ages on its own and the copy a
reader meets first is this one.

`knowledge_navigate` is served by the runtime rather than declared in
`tools.json`, so it will not appear in the tool surface, and in this build it
reads a **source register**: an inventory of every source the upstream shelf
held when this world was assembled, frozen at the vintage rather than read from
the bucket at serve time.

Each entry carries one of three states, and the middle one is the reason the
register exists. `shipped` means the bytes are in `data/` and a named tool reads
them. `absent` means the source is known upstream and was never fetched, with
the reason, which is a licence wall or a data use agreement in every case here.
**`available` means the source exists upstream at a named vintage and this world
does not carry it**, and before the register there was no way to say that
sentence. A question the world had no compartment for and a question nobody had
packed the data for came back looking identical, so a live session wrote "no
world was involved and none could be" about figures that were sitting on the
shelf under a name it could have asked for.

Read `available` precisely: fetched and staged upstream, not validated, not
necessarily converted to a table, and not read by anything here. An entry's
`table_state` says which, because "nobody has converted this file" and "this
world chose not to pack it" are different facts and only the first is a task.

**A register entry states that data exists and is never a value from it.** There
is no field on an entry a figure could be written into, deliberately, so asking
one for a number is refused rather than answered thinly. `gavel_row_count` is
the shape of a table upstream, not a measurement out of one. Where an entry
tells you the data you want is `available`, the next step is to build a
compartment from it or query the shelf directly, and neither of those has
happened inside the answer you are holding.

**Every anchor answers.** `select` reads the register as a table and `node`
returns one record. `steps` walks the graph this compartment ships, over the
relation vocabulary that graph's own edges declare rather than one the binary
was compiled with, so a walk runs from a source, to the data compartment built
out of it, to the tool that reads that compartment. `query` searches the
semantic index, whose vectors come from the hosted embedding model `world.toml`
pins; there is no API key involved anywhere, on a developer machine or on the
deployed service.

**A `query` answer is ordered by more than cosine, and it says which signal
moved what.** It carries a `reranking` block naming the model that could have
reordered it, present even when nothing was reranked, because a cosine ordering
and a relevance ordering are indistinguishable from record ids alone. At this
index's size the reranker is off, under a row threshold `world.toml` declares,
and the block says so rather than staying silent. Beside it a `fusion` block
reports the blended ordering that actually decided the result, over the cosine,
the ranker's relevance and structural evidence read off the graph, under
weights `world.toml` carries so an operator can disagree with them. That blend
is `assumption` basis, not `measured`, because the weights are somebody's
choice and a figure carries the weakest basis among its inputs.

An earlier build shipped the register with neither the graph nor the semantic
index behind it, and the two anchors that need them said so. That is not the
build you are talking to. The world hands you this file over `resources/read`
out of the deployed image, so a capability sentence here that has gone stale is
the running service steering you away from something that works: where this
file and the tool disagree, the tool is right and this file is a defect.

## Three framings over one corpus

The same figures serve a plan-side Cost of Care analyst, a vendor building the
case that analyst will read, and a provider-side service line manager, and
each needs a different framing rather than different data. A question phrased
in PMPM, line of business, funding type or minimum impact threshold routes to
`hammer-cost-of-care-case`, which carries the medical-cost lever tree, the
paid-amount wall and the population chain. A question about what to put in
front of a payer's business-case review, or what a product would save a payer,
routes to `hammer-vendor-evidence`. Where either of those turns on what kind of
saving is being claimed, whether a mechanism is hard or soft and what evidence
that commits the case to, `hammer-savings-classification` carries the
definitions in full and is the source `savings_methodology` cites in every
payload it serves. A question about a provider's own
contracts, filed charges or admission pricing routes to
`hammer-provider-contracting`. A question from a provider-side quality or clinical director, who
arrives with a portfolio slot and a room to defend rather than with a candidate, routes to
`hammer-provider-quality`, which carries the screen that decides whether a programme is
measurable at all before anything else is run, the redesign move each kind of death names, and
the refusal that what an avoided admission is worth turns on a contract this world has not read.
When the question comes with a commercial goal behind it and the
work is to build evidence that survives the buyer's own analyst, `hammer-building-the-evidence`
carries the order of operations, the statistical toolkit mapped to the estimator that serves
each move, and the confounds that have killed real findings here. And when the figures are in
hand but the person asked for a document rather than an answer,
`hammer-writing-the-deliverable` carries the section order, the two appendices, and the rule
that a refusal is a section rather than a hole. This file stays the
tool-level routing under
all three.

## Before the routing table: when you do not yet know what to ask

Everything below this section assumes you already know your question. **If what you have is a goal
rather than a question, start at `frontier` instead.**

The difference is not a matter of degree. A question names a figure and a tool serves it or
refuses. A goal is a thing you want to be true, usually unfalsifiable as written, and putting one
to the checkers gets you a set of answers that are each correct and add up to a dead end: you learn
that you may not write the sentence, and not what you could write instead.

`frontier` takes the goal in your own words, which it never parses, plus the claims it rests on,
each named by its kind from a closed vocabulary. It routes every leaf to one of four places and
settles none of them:

- **Settled here.** A tool serves it. The row names the tool and the call shape, and the rest of
  this file is where you go next.
- **Settled elsewhere, and the route is known.** A corpus in the source register bears on it and
  nothing here reads it. The row names the source and its state. Read the next section on the
  register before you believe what `available` means.
- **Yours to declare.** Your own book, contract, payer mix, costs. No corpus will ever hold these,
  and knowing a figure is yours to supply is what unblocks you, where being told the world cannot
  answer does not.
- **Refused permanently, with the nearest question this world does answer.** The wall and the door
  beside it, in one row.

**Decomposing the goal is yours.** It will not invent your leaves, and it refuses a kind outside
its vocabulary rather than mapping it to the nearest one. It carries no figure at any depth,
because a map that carried one would be a finding wearing a map's clothes.

The reason to run it first is ordering. A goal's fatal leaf is often not the one you would have
checked first, and every other tool here answers the leaf you hand it rather than the one that
decides the goal.

## Start here: what the operator is actually asking, and where it lives

| what the operator is actually asking | where it is |
|---|---|
| what do payers actually pay for 91200 (or any what-does-X-pay question) | `rate_position` |
| is this code paid better than that one / how do these codes' rates sit against each other | `rate_comparison`. It sets each code's payer rates side by side under ONE receipt and computes nothing between them: no ratio, no difference, no comparability flag. That is what makes the comparison checkable, because a claim is decided against one receipt and two separate `rate_position` answers give you two. Write the comparison as a claim and put it through `claim_check` against this answer's receipt. |
| can we bill these two codes together | `stack_check` |
| can a primary care doctor bill this / does this need a radiologist / who has to read the study | `interpretation_requirement`. Medicare Local Coverage Articles only, and no commercial payer policy at all, so read an empty answer carefully: some contractors publish the IDTF Credentialing Matrix and some do not. This is not a coverage question either: a code whose interpretation is unrestricted may still be refused. |
| what does an inpatient admission cost / what did a hospital file for a DRG | `filed_charge`. What a HOSPITAL published under 45 CFR 180, not what a payer pays, and the only place in this corpus that prices an admission at all. `code_type` is required because several DRG groupers sit in one column and a bare number means a different admission under each, and `severity` is required on APR-DRG because that grouper splits a base four ways and the four are four different prices. A filed charge is never comparable with a `rate_position` rate: they are different kinds of money, and each has its own tool so that no call can ask for one of each. |
| which part of this code is the reading and which is the equipment / does this code split | `fee_components`. The Medicare fee schedule's PC/TC indicator and the relative values for the global row, modifier 26 and modifier TC. Relative values, never dollars. |
| how many people are there / what is the prevalence here / how many member months | `cohort_figures`. Every figure arrives with its measurement class and its case definition attached, because an administrative count and a modelled rate are different quantities that share a slot. |
| what does the literature say about fatty liver and some later outcome | `prognostic_association`, with `exposure` as `masld_nafld` and a `stratum`. One published effect size with its interval, its study population and its PMID. Every figure is cited and none is measured here. |
| what does a blood pressure measurement predict | `prognostic_association`, with `exposure` as `clinic_bp` or `nighttime_ambulatory_bp`. Same shape, same rule: one record, cited, never measured here. |
| what did a trial of lowering pressure, or of a rehabilitation programme, actually do | `treatment_effect`, by `arm`. A SEPARATE TOOL from the one above, and that is the refusal rather than an inconvenience: a pressure predicting an outcome and the effect of lowering it are measured against different comparators, so no call can name one of each and no arithmetic over the two is a quantity anybody measured. Ask twice and read them side by side. |
| I called `comorbidity_edges` and it refused | It moved. The corpus is intact under `prognostic_association` with `exposure` as `masld_nafld`; the name is kept so a caller is told where the data went rather than getting an error that reads like it is gone. It refuses rather than aliasing because an alias would answer, and leave you believing you called a tool that still exists. |
| published effect sizes linking a blood pressure or its treatment to a later cardiovascular outcome | `hypertension_evidence`. One record per answer, and prognostic and treatment are never composed: a pressure that predicted an outcome is selected by `measurement`, a randomised effect by `arm`, and naming both is refused because the two are measured against different comparators. Cited, never measured here. |
| what would this test find, or how good is its predictive value at this prevalence | `screening_yield`. Declare sensitivity, specificity, prevalence with its measurement class, and a population; it computes straight Bayes and shows how positive predictive value moves at the stated prevalence. |
| is this actually a saving or just a deferred cost / does this savings model hold up | `deferred_versus_avoided`. Declare the cost events, each timed under the status quo and under the intervention and flagged prevented or moved; it totals the two separately and refuses to sum them. |
| our readmission rate fell / our rate improved, are we improving | `competing_event_coupling`. Declare each period's cohort, deaths and readmissions and it serves the readmission rate over the survivors, the denominator death actually leaves, alongside the crude rate per admission. A patient who dies cannot be readmitted, so mortality moving carries the crude rate with it in the direction that flatters. What comes back is a BOUND on how much of the movement is consistent with the mortality shift, both endpoints, never a decomposition and never a cause. |
| we penalised the worst performers and they improved, did the programme work | `regression_to_mean_expectation`. Declare the cohort mean, the selected cohort's mean and the measure's reliability; it serves what Galton's arithmetic predicts the selected cohort measures next period with nothing done to it. Compare your observed movement against that, not against nothing. It will not attribute the remainder, and an argument naming an intervention or a programme is refused rather than ignored. |
| what did passing or missing that measure cost us / what is the withhold worth | `withhold_earnback`. Declare the capitation, the share of it held back and the menu of measures with their earn-back shares and declared results; it serves what came back and what did not as two totals with the measures behind each. There is no field anywhere on the payload that is the two put together, and that absence is the point: forfeited money is revenue that never arrived rather than a cost that was incurred, and a single figure across the two reads as the second. Naming a state instead of declaring a menu is refused, because a withhold menu is a contract fact. Asking how likely a measure is to pass is refused, because that is a forecast about your own performance. |
| are we going to lose a star / how far are we from the cut / what does the rating turn on | `tournament_position`. Declare your score, the cut points you are reasoning against and the field you are counting; it serves the distance to each cut and, beside it, the shift in the whole field that crosses each cut with your score unchanged. That second figure is the one operators do not have, and it is what makes the mechanism legible: a cut set from the year's distribution moves with the distribution, so you can improve and still fall out of a band. This world holds no actual cut points; the CMS star ratings source is registered available and raw_only, fetched and staged and never converted, which is a different fact from missing. Next year's cut point is refused as a forecast of every other plan's behaviour, and what a band is worth is refused as a fact about a plan's own book. |
| is this rate big enough to compare / is that provider really worse / can we rank on this | `measure_reliability`. Declare the numerator, the denominator and the between-provider variance of the group you are comparing. It serves how much of the measured rate is the provider and how much is the sample it was measured on, and the smallest denominator that would reach each of several stated reliability levels. The variance is yours to declare because it is a property of the group you chose, not of any one provider. It serves no verdict: whether a reliability is high enough to act on is a decision about consequences this world cannot see, and a key asking for one is refused rather than answered and ignored. Reach for this first whenever a comparison is about to become a penalty, and beside `regression_to_mean_expectation`, whose refusal names this tool. |
| is there any data anywhere about X / does this world have anything on Y | `knowledge_navigate`, `select` against the `documents` table. It answers what the upstream shelf held at this world's vintage and which state each source is in. **Ask it before concluding that a question has no data behind it**, because `available` and absent look the same from inside a refusal, and the answer to "why did nothing come back" is often that nobody packed it rather than that nobody has it. |
| what are our odds a payer covers this / what is the denial rate | Refused. `world.toml` `cannot_answer` entry 1 (no denial rate or payment probability, by any method, including arithmetic on counts this world does serve) and entry 2 (a published rate says what a payer pays when it pays, not whether it will pay, so "payer X covers code Y" is not a sentence this corpus can settle). |
| what should we charge / which code should we lead with | The world serves the figures a strategy call would be built on; the strategy call itself is the operator's, not this world's. This is a boundary, not a refusal: `rate_position` will hand you every payer's published rate for a code, and what you do with that spread is a decision this corpus does not make and was never asked to. |

The rule that decides which tool: `rate_position` and `rate_comparison` answer
what a payer publishes that it pays, one code or several. `filed_charge` answers
what a hospital published that it charges, for an admission rather than a
procedure, and the two never meet: different filer, different code vocabulary,
different kind of money. `stack_check` answers
what the Medicaid NCCI edit file says about billing two codes on the same claim.
`interpretation_requirement` answers who a Medicare contractor's policy says may
furnish and read a code. `fee_components` answers how the fee schedule splits
one. `cohort_figures` answers how many people, and `prognostic_association` and
`hypertension_evidence` answer what somebody else's meta-analysis published,
the first about fatty liver and the second about blood pressure. `screening_yield` and
`deferred_versus_avoided` answer nothing about this corpus at all; they are
calculators over whatever the caller declares, and their answers carry
`basis: "assumption"` for exactly that reason. `regression_to_mean_expectation`
and `competing_event_coupling` are calculators of the same kind and route the
same way: they answer what a quality figure would have done anyway, the first
when the cohort was selected for being extreme and the second when the
denominator is a survivor count that mortality moves. `withhold_earnback` and
`tournament_position` are the same kind again and route by which side of the
contract the question is on: a withheld pool released against a menu goes to the
first, a band boundary made out of what everybody else did goes to the second.
Neither ever produces a single figure, and the two things they refuse to produce
are the two things the question usually wants: a net position, and what a rating
is worth in money.

None of them answers whether a payer will pay, what to charge, or that a
modelled saving will actually occur, and no combination of their figures
manufactures those answers either.

## The traps this corpus invites

**Percent-of-charge and phantom rows, and a surviving row that is still wrong.**
The extract is filtered upstream, before `rate_position` ever reads it, to
`quality_flags & 3 = 0` and `negotiated_rate > 0` specifically to exclude
percent-of-charge and phantom-suspect rows, because those rows are not prices.
That filter is a screen against two named flags, not a guarantee that every
surviving row is a plausible price, and cigna's 0689T cell is the real,
committed case of a row that clears it and is still wrong: `rate_position
{code:"0689T", payer:"cigna"}` serves it as-is, a median near zero with a
stddev that dwarfs it, while the code's other payer cells in the same extract
run from roughly eighty to two hundred dollars. Nothing downstream removes
that cell; the quality filter only ever screened the two flags it names, and it
already ran before this cell reached the tool.

That heuristic is now on the payload, and reading it is still yours. Every
served cell carries `stddev_over_median`, its own stddev divided by its own
median, and `largest_n_over_n`, the largest row count any at-or-above-floor
cell carries for the same code in this extract divided by this cell's own row
count. The payer and count that second division used are named beside it, as
`largest_n_for_code` on a `rate_position` answer and as `largest_n` beside each
code on a `rate_comparison` answer, because a cell called thin without being
told thin against what is a judgement handed over rather than evidence stated.
`thinness_note` on both answers says what the figures are.

Both are arithmetic over figures the payload already carried, so a claim about
either is checkable through `claim_check` against the same receipt as the rate
itself. That is the whole reason they are figures and not prose.

What the world still does not do is decide. No threshold is served, no flag is
served, and no cell is withheld or refused on account of either figure: a
spread that dwarfs its own middle, or evidence orders of magnitude thinner than
the largest cell for the same code, is the signal to treat the figure as a data
artifact rather than as a price that payer actually pays, and making that call
is yours. Cigna's 0689T cell is the worked example: it carries the largest
`stddev_over_median` in this extract and is served in full, because the rate is
real and the row count is real and what was missing was only this context
beside them. It is not a rate to report as "cigna barely pays for this."

**`rate_comparison` serves both figures and compares nothing, deliberately.**
It has no ratio between the codes to read and no comparability flag, and the
absence is the design. The thinness figures on each cell are not that: one is
arithmetic inside a single cell and the other inside a single code, so neither
crosses the codes set side by side.

A served ratio between the codes would be this world asserting that two rates
are commensurable, and it is not in a position to assert that: an abdominal
ultrasound and a non-imaging elastography are different procedures on different
fee schedules, so their rates are two facts rather than one measurement. Where
the codes sit on different fee schedules the answer says so in prose, under
`anchor_class_note`, and a figure formed by dividing a code priced in relative
value units by a code priced in dollars is arithmetic across different units
whatever that note says. A comparison you write is yours; put it through
`claim_check` against the receipt and report the verdict.

**The anchor and the ratio are evidence of anchoring, never a contract term.**
Where a code carries a fee-schedule anchor, `rate_position` adds `anchor` and
`anchor_note` to the answer, and `ratio_to_anchor` to each cell where the
anchor is a dollar rate. Payers landing on round percentages of the same
schedule across unrelated codes is strong evidence that a rate is a multiplier
on the schedule rather than an independent draw, and that is the finding this
tool was renamed to serve (`hammer-research/FINDING-2026-08-21-rates-are-multipliers.md`).
It is still not a contract. Whether a payer's actual contract states a
percentage of the schedule is a fact about a document this world has not
read, and reporting a computed ratio as "the contract rate is X percent of
Medicare" states a document, not a measurement. The anchor classes read
differently: a `clfs_priced` code carries a real dollar anchor and a ratio; an
`mpfs_national` code carries relative value units, not dollars, and no ratio,
because turning RVUs into dollars needs a conversion factor and a locality
adjustment this world does not hold; an `mpfs_contractor_priced` code (0689T,
0690T) carries no national anchor at all, so a revenue model stacking either
of those codes is stacking a code with no national price to stack against; and
a code absent from both schedules (0014M) carries no anchor object, with a
note that its absence is consistent with retirement, so a rate observed for it
is a rate for a code Medicare no longer prices.

**Professional, technical and global fee components.** A negotiated rate for a
code is a rate for that code's billed component, and a code can be billed
professional, technical, or global. A payer's rate for the professional
component of a code is not the whole payment for the encounter, and comparing a
professional-only rate at one payer against a global rate at another produces a
spread that is not a spread of the same thing. **`fee_components` is the tool
for which component a code has**: it serves the PC/TC indicator and the relative
values for the global row, modifier 26 and modifier TC separately, and never
sums them, because the global row already contains both components and adding
one to it counts the same work twice. What it will not do is turn a relative
value into a dollar figure, and that refusal is not a gap in the tool: the
annual conversion factor and the locality-specific geographic adjustment are not
in this world, so there is nothing here to multiply by.

**A rate is not coverage, and a missing row is not non-coverage.** This is
`cannot_answer` entry 2 for the first half and entry 7 for the second. Payers
omit, fragment and misfile machine-readable disclosures market-wide: one
payer's disclosure spans roughly 11 million separate files and another
misuses the schema it files under. So the supportable sentence when
`rate_position` returns nothing for a payer and code is "no rate was recorded in
this month's disclosure for this cell," never "this payer does not cover this
code." `rate_comparison` draws the same line one step further out: a
`coverage/no-shared-payer` refusal says no payer recorded every named code in
this month's disclosure, and says which codes each payer was missing. It never
says a code is not covered.

**Cross-payer averaging.** `rate_position` with no `payer` argument hands back
every payer cell the extract carries for a code. Averaging those cells into one
number requires weights, and the weights that make the average mean anything are
the operator's own payer mix, which this world does not hold and was never
asked to hold (`cannot_answer` entry 3). An unweighted average across the
payers in this extract is a number about this extract's payer composition, not
about any market, and reporting it as a market rate is exactly the substitution
entry 3 exists to block.

**A withheld cell and an absent one are different facts, everywhere.** The
reporting floor drops a cell with fewer than `n=10` rows behind it, and every
tool that could hide that drop instead names it. `rate_comparison` drops the
whole payer out rather than averaging what is left, and its
`payers_missing_a_code` list says, per payer, which codes were missing and
whether each cell was absent or withheld. `cohort_figures` goes further and
raises a refusal when every cell asked for was withheld, because an empty result
there would read as a zero, and a publisher declining to publish a number is not
a number that happens to be small. Carry that distinction into the sentence you
write; nothing downstream restores it.

**Never-searched is not searched-and-absent.** Several tools refuse on this
distinction and it is easy to flatten. `interpretation_requirement` raises
`coverage/code-not-searched` for a code outside the vocabulary it was built
over: this world never looked, so it cannot report an absence.
`prognostic_association` splits the same way, and adds that an absence is never a
null effect, a ratio of one, or an absence of association. `cohort_figures`
splits three ways, separating a figure its register blocks by rule from one
whose source holds no table anybody has converted yet, because collapsing those
would hide a task behind a rule.

**The two clocks.** `vintage` in `world.toml` is the date the rate extract was
read, and it is not a knowledge cutoff: rates refresh monthly and upstream
machine-readable files are deleted by the hosting payer at roughly 90 days, so
that vintage is the only durable record that this month's disclosed prices ever
existed anywhere. Read the date from the manifest or from the answer rather than
from this file, which is prose and ages. The NCCI edit file carries its own
`quarter` separately, fetched on its own schedule, and a `stack_check` answer is
dated against that quarter, never against the rate extract's vintage. LCDs,
which no tool here reads directly, change weekly. A claim that mixes the rate
vintage and the NCCI quarter as if they were one clock is dating itself wrong,
and a claim carried forward past either without rechecking is `cannot_answer`
entry 6.

**Medicaid against Medicare NCCI editions.** `stack_check` reads the Medicaid
NCCI edition, because the Medicare NCCI PTP baseline sits behind an AMA CPT
license acceptance form this world's fetch does not hold. The two editions are
not guaranteed to agree. `cannot_answer` entry 8 states this and also states
the companion trap: a pair with no edit row on file comes back `UNKNOWN`, never
permission. Category III codes routinely carry no row at all, and 0689T against
91200 is exactly that case in the shipped file. `UNKNOWN` is an accurate
statement about what the edit file does not cover, not a green light.

## What `screening_yield` and `deferred_versus_avoided` are for

**`screening_yield` exists because the step a savings model skips is the one
that bites.** A funnel that opens with a prevalence and a test's sensitivity and
specificity and jumps straight to cases found has already lost the fact that
positive predictive value collapses at low prevalence: a test with excellent
sensitivity and specificity still returns mostly false positives when the
condition being screened for is rare. This tool ships no default for
sensitivity, specificity, prevalence or population, so every input travels with
the answer, and it refuses a prevalence with no declared measurement class,
because those are different quantities that diverge in both directions and a
figure with no stated class is not one this world will compute a yield from.
Route here for any what-would-this-test-find or what-is-its-predictive-value
question; do not try to reconstruct the arithmetic by hand from a rate this
corpus served elsewhere, because a rate says nothing about a test's sensitivity
or a condition's prevalence. Where the prevalence you want is a published one,
`cohort_figures` may hold it, and it will hand you the measurement class this
tool then requires.

**`deferred_versus_avoided` is the mechanical form of a criticism an operator
made of her own work: a cost that is only moved in time is not a cost that was
saved.** Declare each cost event's amount, its timing under the status quo and
under the intervention, and whether it is prevented (never occurs under the
intervention, a real saving) or moved (still occurs, just later or earlier).
The tool totals the two classes on separate lines and never emits a field that
is their sum, because a total that adds a timing shift to a prevented event
reports a saving that does not exist. Route here whenever someone asks whether
a savings figure is real or whether it is deferred cost dressed up as
avoided cost; if a discount rate is supplied the answer shows a present value
per line, and if one is not supplied the answer says plainly that its
undiscounted totals overstate a deferred cost's timing-shift value rather than
picking a rate silently.

## What the world withholds and how to ask for it

`rate_position` refuses any cell with fewer than `n=10` negotiated-rate rows
behind it, and the refusal (`coverage/below-reporting-floor`) returns **no
rows at all**, in this build, because the extract holds aggregates only:
median, p25, p75, stddev and count, no row-level data. There is nothing to
hand back below the floor because nothing row-level was ever ingested. Do not
ask for a smaller cut, a raw list, or "just the count anyway"; none of that is
in this compartment. Row-level answers, if they arrive, are a phase 3 build.

Specialty is the other one. No tool here filters by specialty, provider type or
NPI, and `rate_comparison` names that explicitly when a call carries such a key
rather than ignoring it. `interpretation_requirement` is the nearest thing and
answers a different question: what a Medicare contractor's policy requires of
whoever furnishes and reads a code, which is not the same as which specialty may
bill it, and which says nothing about commercial payers at all.

## From a result to a claim

Tools return `n`, a `vintage` or `quarter`, and `basis` where relevant. Carry
them into the claim: a figure without its `n` is a figure whose reliability the
reader cannot judge, a figure without its vintage or quarter is a figure that
silently ages the moment either data source refreshes, and a figure without its
basis hides whether it was measured here, cited from elsewhere, or assumed by
the caller. A figure carries the weakest basis of its inputs.

**A claim spanning several figures needs one receipt that covers all of them.**
This is why `rate_comparison` exists and it generalises past it: `claim_check`
decides a claim against a single receipt, so a claim naming a figure from one
answer and a figure from another has no receipt covering it and cannot come back
`entailed`. Measured 2026-08-29 against build `2026-08-27+4`: a path belonging
to a different answer comes back `undefined`, on the remedy that this world
declares no figure of that name, so the refusal arrives as a figure that is not
there rather than as a verdict about the comparison you meant to make. Where one
tool serves both sides, call it. Where none does, the
comparison is your own arithmetic and belongs under `asserted without a check`
in the claim report, naming both receipts.

**And copying the other figure in as a plain number does not make it checked.**
This is the trap the sentence above sets, and it was walked into: a reviewer
holding a prognostic hazard ratio from one receipt and a treatment hazard ratio
from another wrote `{"op": "*", "left": "effect.point", "right": 1.43}` against
the second receipt and was told `entailed`. The checker cannot see where a
literal came from, so what looked like a checked claim was the caller's own
arithmetic wearing a verdict — and it was the exact composition this world
refuses at the tool boundary, where naming a `measurement` and an `arm` together
is `coverage/not-composable`. Measured again 2026-08-29 against build
`2026-08-27+4`, on a rate answer where nothing is declared uncombinable: a
declared median multiplied by a literal lifted from a different answer was still
told `entailed`. The provenance of a literal is not a thing the checker holds.

The effect sizes now say so themselves. Both evidence corpora declare
`effect.point` and its interval bounds uncombinable, so a claim that puts one
inside arithmetic comes back `not_composable` whatever the other operand is.
`effect.point >= 1.4` is still `entailed`: the refusal is against COMBINING the
figure, not against comparing it. There is no better number to go and find, so
ask for each figure separately and read them side by side.

### Which checker, and the equality that will bite you

`claim_check` decides by arithmetic and never reads your sentence.
`judgement_check` reads the English and decides whether the answer supports it.
Neither falls back to the other. Choose by what you are actually checking, never
by which one passed.

**Quoting a figure exactly is the case that separates them.** A decimal in a
payload is read as rounded, because equality against it would assert a precision
the answer never had — so `== 1.43` against a payload carrying 1.43 comes back
`not_entailed`, and it will look like the tool is broken to anyone watching. It
is not, and this was measured 2026-08-29 against build `2026-08-27+4` on a payer
median carried as 13.47. The verdict carries the two bounds that WOULD have
passed, under `entailed_instead`.

**Do not write that pair on the rounded value.** In the same call, `>= 13.47`
came back `not_entailed` and so did `<= 13.47`: the bounds `entailed_instead`
offers sit inside the printed precision rather than on it, and the answer's own
note says to claim clear of it. **Claim half a unit out in the last written
place**, which is what `hammer-writing-the-deliverable` and
`hammer-provider-contracting` both already tell you. `>= 13.465` with
`<= 13.475` came back `entailed` on that same figure, measured 2026-08-29
against build `2026-08-27+4` like the pair above it.

If what you want is to put the published number into a sentence — "the hazard
ratio is 1.43" — that is `judgement_check`'s question, and it answers
`supported`, measured 2026-08-29 against build `2026-08-27+4` on the same median
`claim_check` had just refused an equality against. A vendor claim, a committee sentence or anything else you hold as
PROSE rather than as a dotted path goes there first: it is the interface for a
reviewer who has a claim to adjudicate and no path into a payload.

## When your input is a range rather than a number

Every tool above takes point values. A caller who does not have a point value has
been retyping their uncertainty away: picking the middle of a range, running the
call, and quoting the answer as though the middle were the fact.

Five runtime tools take the declaration instead.

**`simulate`** runs any tool on this world over distributions you declare rather
than points. `screening_yield` is the one to try first, because its five
arguments are exactly the five a screening business case argues about: declare
`prevalence` as a triangular, `sensitivity` as a uniform, leave `population`
fixed, and you get percentiles and a bootstrap interval on every figure instead
of one number. The answer's `basis` is `assumption` and stays `assumption` even
where the underlying estimator answers `measured`, because arithmetic over your
own declarations does not become an observation.

**`sensitivity`** ranks which of your declared inputs actually moves the answer,
so you know what to go and measure. Run it twice, once with `response` set to
`"answered"` and once to a figure path: an input that decides WHETHER you get an
answer at all can look inert in a figure's decomposition, and the two rankings
disagreeing is the finding. An input you declared as a `point` carries no index
at all and says `pinned_reason` instead, because held-fixed and
varied-but-inert are different facts that would both print as zero.

**`interval_check`** decides whether a number you already believe sits inside
what the simulation produced. Six verdicts, no tolerance parameter, and every one
of them carries the sentence that it is about YOUR model rather than about the
world.

**`decision_navigate`** answers "what would have to change". You declare the
moves available to you, each with a cost in your own units, and it finds the
cheapest set that flips a refusal into an answer, or the other way. It reports
the optimum as a PRICE your own proposal is measured against, never as advice,
and it names the inputs you declared no move for: this world has plenty of those
and they are usually the real answer.

**`network_infer`** is where a distribution comes from when you do not want to
invent one. Declare a small Bayesian network, condition on what you know, and the
posterior is directly a `simulate` input. A cell can be a `from` reference that
reads a figure out of this world's own tools, and it inherits that answer's basis
and source, which is the difference between a sourced prior and a retyped one.

Two things to carry. A cohort is its recipe, so these tools take the same
arguments `simulate` took rather than a saved id; pass `cohort` as well and it is
recomputed and checked rather than trusted. And an edge in a network licenses a
conditional probability table and says nothing about causation: the arguments
that ask for a causal reading are refused by name.

## Every answer built on this world closes with the claim report

The claim report format is defined once, in the `hammer-worlds` skill. Point at
it; this file does not restate it.


HTTP bindings for this session:
Explicit source-reference bindings:
SKILL.md: https://space.hammer.ai/skills/global/building-sourced-excel-models.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
analysis.md: https://space.hammer.ai/skills/global/analysis.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
coverage-website.md: https://space.hammer.ai/skills/global/coverage-website.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba

rate_position: https://space.hammer.ai/analysis/rate_position/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
rate_comparison: https://space.hammer.ai/analysis/rate_comparison/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
stack_check: https://space.hammer.ai/analysis/stack_check/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
screening_yield: https://space.hammer.ai/analysis/screening_yield/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
deferred_versus_avoided: https://space.hammer.ai/analysis/deferred_versus_avoided/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
interpretation_requirement: https://space.hammer.ai/analysis/interpretation_requirement/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
cohort_figures: https://space.hammer.ai/analysis/cohort_figures/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
comorbidity_edges: https://space.hammer.ai/analysis/comorbidity_edges/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
fee_components: https://space.hammer.ai/analysis/fee_components/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
filed_charge: https://space.hammer.ai/analysis/filed_charge/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hypertension_evidence: https://space.hammer.ai/analysis/hypertension_evidence/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
prognostic_association: https://space.hammer.ai/analysis/prognostic_association/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
treatment_effect: https://space.hammer.ai/analysis/treatment_effect/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
regression_to_mean_expectation: https://space.hammer.ai/analysis/regression_to_mean_expectation/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
competing_event_coupling: https://space.hammer.ai/analysis/competing_event_coupling/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
withhold_earnback: https://space.hammer.ai/analysis/withhold_earnback/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
tournament_position: https://space.hammer.ai/analysis/tournament_position/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
measure_reliability: https://space.hammer.ai/analysis/measure_reliability/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
declared_inputs: https://space.hammer.ai/analysis/declared_inputs/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
cost_of_care_exposure: https://space.hammer.ai/analysis/cost_of_care_exposure/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
savings_methodology: https://space.hammer.ai/analysis/savings_methodology/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hospital_variance: https://space.hammer.ai/analysis/hospital_variance/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
filer_inventory: https://space.hammer.ai/analysis/filer_inventory/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
candidate_screen: https://space.hammer.ai/analysis/candidate_screen/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
frontier: https://space.hammer.ai/analysis/frontier/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
judgement_check: https://space.hammer.ai/analysis/judgement_check/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
claim_check: https://space.hammer.ai/analysis/claim_check/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
deliver: https://space.hammer.ai/analysis/deliver/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
session_trace: https://space.hammer.ai/analysis/session_trace/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
progress_check: https://space.hammer.ai/analysis/progress_check/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
model_advisory: https://space.hammer.ai/analysis/model_advisory/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
knowledge_navigate: https://space.hammer.ai/analysis/knowledge_navigate/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
simulate: https://space.hammer.ai/analysis/simulate/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
sensitivity: https://space.hammer.ai/analysis/sensitivity/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
interval_check: https://space.hammer.ai/analysis/interval_check/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
decision_navigate: https://space.hammer.ai/analysis/decision_navigate/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
network_infer: https://space.hammer.ai/analysis/network_infer/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hello_world: https://space.hammer.ai/analysis/hello_world/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
say_world: https://space.hammer.ai/analysis/say_world/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba

Read the companion references here (these replace local file references in the source guide):
Build a sourced analysis: https://space.hammer.ai/analysis.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
OData exploration and analytic cuts: https://space.hammer.ai/odata.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
Worked analysis reference: https://space.hammer.ai/skills/global/analysis.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
Building sourced Excel models: https://space.hammer.ai/skills/global/building-sourced-excel-models.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
Coverage website reference: https://space.hammer.ai/skills/global/coverage-website.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
Spine cohort and post-acute analysis: https://space.hammer.ai/skills/spine-analysis.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hammer-building-the-evidence: https://space.hammer.ai/skills/world/hammer-building-the-evidence.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hammer-cost-of-care-case: https://space.hammer.ai/skills/world/hammer-cost-of-care-case.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hammer-coverage-navigate: https://space.hammer.ai/skills/world/hammer-coverage-navigate.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hammer-provider-contracting: https://space.hammer.ai/skills/world/hammer-provider-contracting.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hammer-provider-quality: https://space.hammer.ai/skills/world/hammer-provider-quality.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hammer-savings-classification: https://space.hammer.ai/skills/world/hammer-savings-classification.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hammer-vendor-evidence: https://space.hammer.ai/skills/world/hammer-vendor-evidence.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hammer-writing-the-deliverable: https://space.hammer.ai/skills/world/hammer-writing-the-deliverable.skill.txt?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
Data: https://space.hammer.ai/data/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
Transcript: https://space.hammer.ai/session/?ledger=49ec6090f32b112cd7fc2d39a72e0974&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba