hammer-provider-contracting
Scope: world hammer-coverage-intelligence vintage 2026-10-01
Revision SHA-256: 9a7b096d96744ca066cfa1bb9629ca126fd5b727c7788078edaf9df0e75e0b63

---
name: hammer-provider-contracting
description: Use when somebody asks what a named provider's contracts look like, whether an admission is priced as a DRG case rate or some other way, what a hospital filed for a procedure or an admission, or how a provider's filing compares with what payers publish. This is the working order for that question, one level above the tool surface: which question to settle first and why the obvious order is wrong, the arguments the tools require and the reason each exists, the refusals a real session hits and what each one is telling you, the crossing this world forbids together with the measured case where a careful analyst ran it and got a clean-looking answer that dissolved, how to read a row count in a corpus that replicates, and the checker traps that cost a live session a whole batch of claims. Closes with a worked example, start to finish, on the question that produced all of it. Read hammer-coverage-navigate for routing and this for the route.
---

# hammer-provider-contracting

A question like *"what do this hospital's commercial contracts look like, and are
they DRG based for spine?"* is answerable here, and a live session answered it.
That session also spent calls on things this file would have told it. This is
that file.

**`tools/tools.json` is the authority on what exists and what each tool takes.**
This is the order to do things in and the traps between them. Where the two
disagree, the tool surface is right and this is stale.

## Start from the inventory, not from a guess

The session behind this file worked out what NYU Langone files by guessing a
code, being refused, and reading the `edition_note` in the refusal. That loop
works and it is the expensive way round: it costs a call per guess, and it
teaches you nothing about the codes you did not think to guess. Two of its
refusals landed on spine fusion codes that filer's numbering edition does not
define, which is a fact about the numbering that more guessing would never have
produced.

`filer_inventory` puts that at the front. One filer in, one answer out.

1. **Call `filer_inventory` with the filer.** Back comes the groupers that filer
   files, the codes this build can answer under each, the counterparty strings
   exactly as the hospital wrote them, how it says its figures were arrived at,
   and the facilities inside it.
2. **Read the groupers before you read the codes.** A grouper the filer files
   that this build answers nothing under is listed apart, with the rows behind it
   and the reason. *"This filer files no such admission"*, *"this world does not
   read that grouper"* and *"this world reads it and nothing in this filing came
   through the parse"* are different answers to one question, and the list is
   what tells you which one you are holding.
3. **Pick a code from the list**, with its grouper, and with the severity
   subclass where that grouper carries one. The inventory says which groupers
   require a subclass and names the ones it holds, so the call you make next is a
   call that answers rather than a refusal you have to read.
4. **Then call `filed_charge`.** That is where money lives. The inventory carries
   no dollar figure at any depth, deliberately: a listing that also priced things
   would be a second, thinner pricing surface, without the methodology, the two
   row counts, the reporting floor and the refusals that decide what a figure
   means.

A code the inventory names answers for that filer. That is a property the build
tests rather than a promise this file makes, and it is the whole reason for
putting the inventory first: the loop ends in an answer instead of in a refusal
you have to interpret.

**A list is not a census.** The codes are the codes this extract can answer, the
counterparty strings are that filer's own free text and resolve to nobody, and
every count counts cells in a document rather than admissions, patients or
payments. An absence from any list here is a fact about this document, and the
`edition_note` and the refusals below say what it is not.

## The order, and why the obvious one is wrong

The instinct is to go for prices first, because a price is a number and a
structure is a category. Do it the other way.

**1. Settle the structure before the level.** A contract that pays one amount
for a whole admission is a different object from one that pays per day or as a
share of billed charges, and every price you quote afterwards means something
different depending on which it is. The field that states this rides on each
filed figure and says how the filer said the figure was arrived at. Read the
answer's own note on what those values mean rather than assuming from the name:
a dollar filed as a percentage of billed charges is a number the hospital
computed from its own gross charge, not a price observed anywhere.

**2. Settle the code vocabulary before you conclude anything from an absence.**
Several DRG groupers live in this corpus and a number means a different
admission under each. Worse, the grouper family gets renumbered: two filers can
sit on different editions, so a code present at one and missing at another may
be a code that filer's edition does not define. The tools carry an
`edition_note` saying so, and it names the contrast filer. **An absence here
settles nothing** and the note says that in its own words.

**3. Only then ask what the figures are**, and read them with the row-count
rules below.

**4. Ask what actually happened to patients last**, if the question needs it,
and know that it is a different corpus with a different money kind. A length of
stay and a discharge destination are not prices at all.

## The arguments that are required, and why each one exists

Every required argument on these tools is a refusal wearing a friendlier face.
Supplying it is how you avoid getting one of several answers chosen on your
behalf.

**The grouper is required on an admission lookup.** A bare number is ambiguous
across the grouper families this corpus carries. The sharpest case is one filer
that files the same number as a spinal fusion under one grouper and as a stroke
under another, in the same file.

**The severity subclass is required for APR-DRG and refused for MS-DRG.** That
grouper numbers a base condition and splits it by severity of illness. All the
subclasses of one base share a single description, so the text cannot tell them
apart, and their medians differ by more than a factor of four. A figure for a
base without a subclass would be one of several answers, picked for you. MS-DRG
draws no such split, which is why passing severity there is refused rather than
ignored.

**A payer slug is refused on the hospital tools.** See below.

## The refusals you will actually hit

Each of these is a result. Report it, and read its remedy clause, which usually
names the next thing to go get.

**`coverage/unknown-filer`** on a code you expected. Read it with the
`edition_note`. It names which filers did file that code, and it says that a
filer's absence is not evidence the filer does not perform or price the
admission.

**`coverage/severity-required`.** You asked about an APR-DRG base without a
subclass. The message carries the measured spread so you can see what the
missing argument was worth.

**`coverage/hospital-payer-is-not-a-payer-slug`.** You passed a payer slug to a
hospital tool. The hospital corpus records the counterparty as the hospital's
own free text, and this world does not resolve it. The same company appears
under several spellings, some entries name a third-party administrator renting a
network rather than an insurer, and at least one names a government programme.
**Resolving that text to a party is an inference this world has not licensed.**
If your analysis needs the mapping, it has to come from somewhere else and be
declared as an assumption owned by whoever declares it.

**`coverage/incomparable-kinds`.** You tried to relate a hospital's filed charge
to a payer's published rate. Read the next section before you work around it.

## The crossing this world forbids, and the case that proves the point

A hospital's filed charge and a payer's published rate are different kinds of
money, served by separate tools on purpose, and no single call can ask for one
of each. The refusal exists because both are dollars for care and sit within an
order of magnitude, so a sentence subtracting them reads perfectly well.

**This is not theoretical, and the case is worth carrying.** Measured
2026-08-28, working outside these tools: an analyst reconciled hospital-filed
against payer-filed figures on matched code and payer pairs at one NPI. The
ratios flipped hard and consistently by payer, one payer's figures landing at
0.27 to 0.64 of the hospital's and two others at 5.3 to 10.2 times it. That
looked like a finding about negotiating posture.

It was a confound. Checking billing class: 622 of 645 rows for the payer below
the line were institutional, and 562 of 662 for one payer above it were
professional. **The flip tracked billing class, not negotiation.** And the
hospital side could not be split to match, because that filer's wide-CSV filing
carries no billing class column at all.

Two further confounds sat in the same comparison: 532 rows for one payer carried
a negotiated type of `derived`, which is an estimated allowed amount rather than
a negotiated rate, and one unlisted molecular procedure code produced a ratio in
the thousands because a placeholder was being divided by a real charge.

**A cross-corpus ratio that tracks a variable the two corpora record differently
is not a finding, and here one corpus does not record it at all.** The refusal
was doing work.

## Reading a row count in a corpus that replicates

Every hospital cell carries two counts and they are not interchangeable.

- **`n`** is rows left after deduplicating on the full natural key.
- **`n_rows_before_dedupe`** is what that cell started from.

They differ because the corpus replicates: a large share of rows are exact
duplicates on that key, and most rows belong to a cell arriving under more than
one source file. Where the two diverge, the same filing arrived repeatedly,
which is a property of how the file was assembled and **not a finding about the
price**. Neither figure counts admissions, patients or payments.

On the payer side the equivalent hazard is which tree a cell came from, and each
cell says so in its own `n_basis`. A cell from the layered tree has an `n`
inflated by however many times that payer was re-pulled. **Never compare an `n`
from one tree against an `n` from the other**; the answer's own note carries the
measured inflation factors.

Two thinness figures ride beside each payer cell and neither is a verdict. No
threshold is applied and no cell is withheld on account of either. That reading
is yours, on evidence the answer states.

## Turning results into claims, and the traps that cost a live session

Build the claim list **before** writing prose, check it, then write only what
came back entailed. Assembling the list afterwards from finished prose is how a
claim goes missing.

Prefer `claim_check`. It decides by arithmetic over declared figures, so its
verdict is the same in every language and no wording buys a pass. Reach for
`judgement_check` only when the claim cannot be written as an expression over
numeric figures: a claim about a text field, a named party, or something
existing.

Four things measured on a live session, in the order they bit:

**A text field is not a figure.** Submitting a claim about a methodology value
to `claim_check` returns `undefined` with a remedy about misspelling or the
wrong vintage. The real cause is that a payload-derived world declares its
numeric figures and its flags and nothing else. Text goes to `judgement_check`.
Re-measured 2026-08-29 against build `2026-08-27+4`, where a claim about `basis`
still returns `undefined` and the answer's own `not_declared` block names every
text field it holds beside the reason none of them can be claimed here.

**`about` once needed a leaf, and on this build a container resolves.** Naming a
container used to return `unsupported` with the container listed as missing,
which reads as *"that field does not exist"* when the truth was *"name a leaf
inside it"*, and that cost one session a whole batch. **This file stated that as
settled and it has since stopped being true.** Measured 2026-08-29 against build
`2026-08-27+4`, `about: "cells"` on a rate answer came back `supported`: the
tool now declares that a figure anywhere under a container which governs how it
must be read is bound-checked as though you had named it. What still returns
`unsupported`, measured in the same call, is a path nothing in the payload sits
under, and that verdict names the missing path. So read `unsupported` as a field
that does not exist rather than as one named too coarsely. Naming the leaf is
still the cheapest and most exact check available, and it is what the tool's own
description recommends.

**An argument you passed may not be certifiable back to you, and check rather
than assume which.** Measured on one build, a sentence naming the filer came
back `restates_input`, on the reasoning that the filer is a selector rather than
a discovery. Measured again on `2026-08-27+4`, the same shape came back
`supported`. **This file previously stated the refusal as settled fact and was
wrong about its own world**, which is the failure it exists to prevent, so it
now says: submit the attribution, read the verdict you actually get, and place
it accordingly. The underlying caution stands whichever way the verdict lands.
A provider attribution that comes back uncertified belongs under `asserted
without a check`, in words, rather than in the entailed list.

**Round the interval, not the point.** A float is read as quoted, so equality
against one is not settled. Claim the interval you are writing, as two claims at
half a unit in the last written place.

## A worked example, start to finish

The question: *"what do NYU Langone's commercial contracts look like, and are
they DRG based for spine procedures?"*

**Route it.** Contract structure for an admission is the hospital filing tool.
The spine procedures themselves, if the question turns to what payers pay for
the operation rather than the admission, are the payer rate tool, and the two
answers never combine.

**Pick the codes out of the inventory.** Ask `filer_inventory` what this filer
carries before naming a code. Spine fusion admissions sit in a numbering that was
restructured, so both editions are in play, and the inventory is what says which
one this filer is on. Guessing works too, and the next step is what it costs.

**Call, and expect refusals.** Codes from the edition this filer does not use
come back `coverage/unknown-filer`, each naming the filer that does carry them.
That is the answer to *"do they file this"*, not evidence about what they
perform. Codes from the edition they do use return filings.

**Read the structure field first.** On the codes that returned, every
counterparty cell on that filer's spine admissions carried a case rate. That is
the answer to the question as asked, and it came from a declared field rather
than from inference.

**Then the figures**, with the two counts read together, and the counterparty
names reproduced exactly as filed rather than tidied.

**Then say what you could not settle**, which here included whether the missing
codes are an edition artefact (the file does not name the grouper edition, so
nothing in it can settle that), whether any of this is what the provider is
actually paid (no adjudications in this corpus at all), and how the provider
compares with peers (no statistic is computed across filers at any row count,
because one filer is a large share of the corpus and a figure across them would
be a figure about that one filer wearing a wider name).

**Close with the claim report**, in the shape `hammer-worlds` defines, and put
the provider attribution under `asserted without a check` for the reason above.

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

Its shape is defined in `hammer-worlds` and it is not optional. An answer that
arrives without one is incomplete, and whoever receives it should read it that
way.


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

rate_position: https://space.hammer.ai/analysis/rate_position/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
rate_comparison: https://space.hammer.ai/analysis/rate_comparison/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
stack_check: https://space.hammer.ai/analysis/stack_check/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
screening_yield: https://space.hammer.ai/analysis/screening_yield/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
deferred_versus_avoided: https://space.hammer.ai/analysis/deferred_versus_avoided/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
interpretation_requirement: https://space.hammer.ai/analysis/interpretation_requirement/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
cohort_figures: https://space.hammer.ai/analysis/cohort_figures/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
comorbidity_edges: https://space.hammer.ai/analysis/comorbidity_edges/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
fee_components: https://space.hammer.ai/analysis/fee_components/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
filed_charge: https://space.hammer.ai/analysis/filed_charge/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hypertension_evidence: https://space.hammer.ai/analysis/hypertension_evidence/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
prognostic_association: https://space.hammer.ai/analysis/prognostic_association/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
treatment_effect: https://space.hammer.ai/analysis/treatment_effect/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
regression_to_mean_expectation: https://space.hammer.ai/analysis/regression_to_mean_expectation/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
competing_event_coupling: https://space.hammer.ai/analysis/competing_event_coupling/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
withhold_earnback: https://space.hammer.ai/analysis/withhold_earnback/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
tournament_position: https://space.hammer.ai/analysis/tournament_position/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
measure_reliability: https://space.hammer.ai/analysis/measure_reliability/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
declared_inputs: https://space.hammer.ai/analysis/declared_inputs/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
cost_of_care_exposure: https://space.hammer.ai/analysis/cost_of_care_exposure/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
savings_methodology: https://space.hammer.ai/analysis/savings_methodology/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hospital_variance: https://space.hammer.ai/analysis/hospital_variance/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
filer_inventory: https://space.hammer.ai/analysis/filer_inventory/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
candidate_screen: https://space.hammer.ai/analysis/candidate_screen/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
frontier: https://space.hammer.ai/analysis/frontier/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
judgement_check: https://space.hammer.ai/analysis/judgement_check/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
claim_check: https://space.hammer.ai/analysis/claim_check/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
deliver: https://space.hammer.ai/analysis/deliver/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
session_trace: https://space.hammer.ai/analysis/session_trace/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
progress_check: https://space.hammer.ai/analysis/progress_check/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
model_advisory: https://space.hammer.ai/analysis/model_advisory/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
knowledge_navigate: https://space.hammer.ai/analysis/knowledge_navigate/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
simulate: https://space.hammer.ai/analysis/simulate/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
sensitivity: https://space.hammer.ai/analysis/sensitivity/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
interval_check: https://space.hammer.ai/analysis/interval_check/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
decision_navigate: https://space.hammer.ai/analysis/decision_navigate/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
network_infer: https://space.hammer.ai/analysis/network_infer/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hello_world: https://space.hammer.ai/analysis/hello_world/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
say_world: https://space.hammer.ai/analysis/say_world/?ledger=eccbd49b235df851c1880b208d9d33fb&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=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
OData exploration and analytic cuts: https://space.hammer.ai/odata.skill.txt?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
Worked analysis reference: https://space.hammer.ai/skills/global/analysis.skill.txt?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
Building sourced Excel models: https://space.hammer.ai/skills/global/building-sourced-excel-models.skill.txt?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
Coverage website reference: https://space.hammer.ai/skills/global/coverage-website.skill.txt?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
Spine cohort and post-acute analysis: https://space.hammer.ai/skills/spine-analysis.skill.txt?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hammer-building-the-evidence: https://space.hammer.ai/skills/world/hammer-building-the-evidence.skill.txt?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hammer-cost-of-care-case: https://space.hammer.ai/skills/world/hammer-cost-of-care-case.skill.txt?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hammer-coverage-navigate: https://space.hammer.ai/skills/world/hammer-coverage-navigate.skill.txt?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hammer-provider-contracting: https://space.hammer.ai/skills/world/hammer-provider-contracting.skill.txt?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hammer-provider-quality: https://space.hammer.ai/skills/world/hammer-provider-quality.skill.txt?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hammer-savings-classification: https://space.hammer.ai/skills/world/hammer-savings-classification.skill.txt?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hammer-vendor-evidence: https://space.hammer.ai/skills/world/hammer-vendor-evidence.skill.txt?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
hammer-writing-the-deliverable: https://space.hammer.ai/skills/world/hammer-writing-the-deliverable.skill.txt?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
Data: https://space.hammer.ai/data/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba
Transcript: https://space.hammer.ai/session/?ledger=eccbd49b235df851c1880b208d9d33fb&snapshot=7a53af6a9beb58928d4a64dc92db09c9db65433f9909f1a10d16e302adaf86ba