hammer-writing-the-deliverable Scope: world hammer-coverage-intelligence vintage 2026-10-01 Revision SHA-256: ce05eb301a3b3dc519f20e01cb4021cb1ec0aa9e3ae7516b3c6db5315c88356f --- name: hammer-writing-the-deliverable description: Use when the answer is not the deliverable and somebody needs the document: a commercial-terms report, a payer submission, a board memo, a benchmark pack. Carries how to declare the items the document needs before the first data call and read progress_check's verdict on the ledger against them, how to claim a computed figure, the section order and where each section's figures come from, the two appendices that make a document checkable, how a refusal becomes a section, how the claim report and deliver become the audit trail, and a worked example. Read after the persona skill that routes the question. --- # hammer-writing-the-deliverable **The figures are not the deliverable.** An analyst who asked what a hospital's contracts look like does not want a payload; they want a document they can send, defend, and be asked questions about a week later. This file is how that document gets built. Measured, 2026-08-27: a live session answered exactly that question and ended in an eight-section Word document with eleven tables and two appendices. Everything below is the shape that session arrived at, generalised. ## The rule that makes this worth doing **A refusal is a section, not a hole.** This is the whole difference between a document that reads as capable and one that reads as excuses. The world refuses to relate a hospital's filed charge to a payer's published rate. In a payload that is a wall. In a document it is **the section that says what you would not quote and why**, and it is the section that makes an informed reader trust the rest. That same session ran the forbidden reconciliation anyway, outside the tools, got a clean-looking ratio, and found on one more check that the ratio tracked billing class rather than negotiation. That paragraph is worth more to the reader than the ratio would have been. So: **never omit a question the reader will have.** Answer it, or write the section that says what could not be settled, what it would take to settle it, and what you therefore did not write. Both are deliverables. Silence is not. ## Declaring the deliverable before you start **Name every item the document needs before the first data call, and name each one as the kind of thing it is.** The section order below says where each item lands; this is how you know, mid-session, which of them you hold. The two ways a deliverable goes wrong are a figure remembered as fetched that never was, and a refusal read once and then worked around. Neither is visible from inside the prose, and both are visible in the ledger the moment you say what you came for. Six kinds of item, and every entry in a deliverable is one of them: | kind | what it is | what makes it stand | |---|---|---| | `figure` | one served number with its unit, read off one payload | its receipt, the payload's `n` and its vintage | | `table` | served cells keyed by a dimension: payer, code, facility, field | every cell present, each with its own `n`; a cell the world did not serve is missing, not rounded | | `derived` | arithmetic over cells of ONE served payload | a `claim_check` verdict of `entailed` against that payload's receipt; arithmetic across two receipts is a `finding`, because `claim_check` checks one receipt | | `declared` | an input the requester supplied: a share, a fee, a population, a cut point | it travels in the call's arguments, so the ledger holds it as what you told the world and not as something the world said; its entry carries the receipt of that call | | `refusal` | what the world would not serve | the rule the world returned, named, and the receipt that refused | | `finding` | a sentence with a derivation behind it: a ranking, a comparison, a pricing rule read off filed cells | the receipts it reads from; it is yours rather than the world's, and it never stands in for a figure | **Which tool serves which item, in this world.** The routing skills carry the reasons; this is the map. - A payer's published rate for a code: `rate_position` for one code, one payer or the whole field; `rate_comparison` for several codes at one payer, with dispersion beside each median. - RVUs for a code: `fee_components`. - What a hospital filed for an admission: `filed_charge`, with the grouper argument. - Who files at all: `filer_inventory`, which serves names and no figure, so it is never an item of its own; it tells you which filer to put in the `filed_charge` call. - How many people, and what share of them: `cohort_figures`, with the field and the geography. - Exposure over inputs you declare: `cost_of_care_exposure`, the inputs in the call's arguments and every one of them a `declared` item in the deliverable. - Screening arithmetic over declared sensitivity, specificity and prevalence: `screening_yield`. - The timing of avoided events, deferred against avoided: `deferred_versus_avoided`. - Whether a before and after is the intervention or the mean coming back: `regression_to_mean_expectation`. - A rate against a field: `tournament_position`, over the field `rate_position` served and cut points you declare, because that tool reads nothing off the corpus and refuses to supply them. **`progress_check` reads exactly that list.** Hand it the items as strings, one per item, each `name | tool, tool | needle, needle`: the item's name, then the tools that would serve it, then the strings its arguments must carry: the code, the payer slug you passed, the field name. The third field is optional and whitespace around the separators is ignored. It reads this session's ledger, states no figure, issues no receipt, and comes back with one word: | verdict | what the ledger holds | what to do | |---|---|---| | `deliver` | every declared item established | build the claim list, check it, write, call `deliver` | | `deliver_partial` | none missing, at least one refused | write, and the refused items go into the refusal section with the rules the reply names | | `continue` | items missing, and few calls have gone by since one last landed | fetch the missing items, by the names the summary line gives you | | `change_route` | items missing, and `drift_threshold` or more calls have gone by since anything declared was established | stop calling; re-plan with `frontier`, naming the missing items, before the next data call | | `cannot_settle` | every declared item refused | the deliverable is the refusal section and what would settle each item; there is no headline figure to write | ```json {"declared": [ "uhc_rtm_rates | rate_comparison, rate_position | 98977, unitedhealthcare", "rtm_rvus | fee_components | 98977", "aetna_rtm_rates | rate_comparison, rate_position | 98977, aetna" ]} ``` Two things about the match, both of which decide how you write the third field. It is case-folded equality against whole values among the call's arguments, wherever they sit: a code inside a `codes` list, a payer under `payer`, a field inside a nested handle. Never a fragment and never a key, so a code establishes against a call that passed exactly that code and against nothing shorter or longer, and a payer establishes under the slug you passed and not under its display name. A number matches as the value it names, so write it without trailing zeros: the ledger holds the value and not your spelling of it. And an item declared with no third field comes back `degraded` when it is established: the tool answered, and nothing checked whether it answered about the code, payer or population you had in mind. Declare the strings and call again before you rest a figure on it. The same rule has a corner: `refused` means the ONLY receipts from the item's tools are refusals, so a refusal raised by an argument the tool does not read, declared against a tool that also answered another of your items, reads as established and degraded rather than refused, and that refusal is read off the refused receipt itself, not off this verdict. The verdict is arithmetic over the ledger and your list, nothing more. A list you got wrong produces a wrong verdict, and that is yours to fix. `since` names a receipt so only what landed after it counts; a receipt id this session never issued is an error, not a wider window. Call it after every few data calls and once more before `deliver`. ### Claiming a figure you computed A `derived` item is a figure you wrote down that the world never served as a cell. Claim it in the difference form, as two claims against the one receipt it was computed from: the derivation minus the figure as you wrote it is at most `h`, and at least minus `h`, where `h` is half a unit of the precision you wrote. ```json {"receipt": "rN", "claims": [ {"op": "<=", "scope": "marginal", "left": {"op": "-", "left": {"op": "+", "left": "by_payer.unitedhealthcare.98977.median", "right": "by_payer.unitedhealthcare.98980.median"}, "right": ""}, "right": ""}, {"op": ">=", "scope": "marginal", "left": {"op": "-", "left": {"op": "+", "left": "by_payer.unitedhealthcare.98977.median", "right": "by_payer.unitedhealthcare.98980.median"}, "right": ""}, "right": ""} ]} ``` **Why this form and not `<= r` beside `>= r`.** Every float the world quotes is read as an interval one ulp wide either side, and `<=` is entailed only when the whole of the left side sits at or below the whole of the right. So a sum of two quoted medians can never be entailed both at or below and at or above one decimal at once, and equality against a decimal is `not_entailed` by rule. The difference form asks the question you are actually making: that the derivation rounds to what you wrote. Both halves are entailed whenever it does. **The literal in a claim is the declared input and the served figure is what the claim is about, never the other way round.** You supply `r` and `h`; the world supplies the medians under their paths. The reply echoes your `r` literally, which is what lets a reader of the claim report see the figure you wrote and the receipt it was checked against on one line. Writing the served median into the claim as a literal and asking whether the path equals it turns the check inside out, and it fails for the reason above. ### The machine-readable deliverable, beside the prose The prose is for the reader. Beside it, hand a machine one fenced `json` block, once, at the end, so a scorer or a later session can read what you delivered without parsing your sentences. One entry per declared item, each named exactly as the goal named it, which is also how you declared it to `progress_check`; a name of your own matches nothing. Every turn ends with a block, a refusal included: a follow-up's block carries what that turn adds. ```json {"deliverable": {"items": [ {"name": "uhc_rtm_patient_month", "kind": "derived", "value": , "unit": "USD per patient month", "n": , "vintage": "", "source": "", "receipts": ["rN"], "declared": false, "refusal_rule": null}, {"name": "conversion_factor", "kind": "refusal", "value": null, "receipts": ["rM"], "declared": false, "refusal_rule": ""} ]}} ``` `value`, the values under `cells` and `n` are JSON numbers, never strings: a quoted figure scores as absent. `kind` is one of the six above. `source` is the class the figure came from, one token, exactly: `payer_disclosure` for `rate_position` and `rate_comparison`; `fee_schedule` for `fee_components`; `hospital_filing` for `filed_charge`; `cohort_register` for `cohort_figures`; `declared_inputs` for a value the caller declared and for arithmetic the world did over declared inputs, which is `cost_of_care_exposure`, `screening_yield`, `deferred_versus_avoided`, `regression_to_mean_expectation` and `tournament_position`; `trial_corpus` for `treatment_effect` and `prognostic_association`. A refusal entry needs no source; where one is named for a refusal about the provider layer this world does not hold, the NPI or enrolment side, the token is `provider_puf`. A `table` carries `cells` in place of `value`: one JSON object mapping each row's key (the code, the payer, the charge kind, the field the table runs over) to that row's figure, each a number and nothing else; a list of row objects is not a table. A `declared` item carries `"declared": true`, the value you passed as a number, and under `receipts` the receipt of the call whose arguments carried that value. A `refusal` carries the refused receipt and the world's rule, and no value. Every figure in the block is a figure the ledger holds, under the receipts the entry names; a figure with no receipt in this block is a figure from nowhere, and it is read as one. If you rewrite the block, the last one you wrote is the one that is read. ## The section order Eight sections, in this order, because each one earns the next. **1. The headline, in one paragraph.** The answer to the question as asked, with the figure that carries it and the field it came from. Not a summary of the document: the finding. > NYU prices admissions as a case rate. Over 2,018 distinct DRG codes: 2,013 case rate, 5 per > diem, zero fee schedule. **2. What you were asked and what you read.** The question in the requester's words, the corpus, its vintage, and the tool that served it. Two or three sentences. This is what lets a reader know, in November, whether the March document still applies. **3. The direct answer, with its table.** The figures, per cell, each carrying what the payload carried: `n`, the basis, the thinness figures. **Do not tidy a served value.** A counterparty string the hospital filed as `AETNA [1003]` is written that way in the document, because the document is evidence and evidence is not normalised. **4. The dimension the reader will ask about next.** Facility, payer, code type, edition. The session that produced this shape had it as "both NPIs you asked for", and the interesting half was that the two corpora were not seeing the same provider. **5. What the figures are, exactly.** The caveats that change what a number means, in the reader's own vocabulary rather than ours: what `n` counts, what a published rate is and is not, which month, what was filtered before any median was taken. **6. What this is not, and what you would not quote.** The refusal section. See the rule above. Every refusal the world served during the work belongs here in plain language, with the "what would settle it" clause that every refusal in this world carries. **7. The adjacent question you can answer, if there is one.** Patients, volumes, length of stay, whatever second corpus bears. Clearly separated, because a second corpus is a second answer and never composes with the first into a third claim. **8. What is still open.** Named, with what it would take. A document that lists its own open questions is one somebody can commission the next piece of work from. ## The two appendices, which are not optional **Appendix A, sources.** Numbered. Per source: what it is, its vintage or file date, the tool that read it, and the licence or access basis where one applies. A figure whose source a reader cannot reach is a figure they have to take on faith, and this world exists to stop that. **Appendix B, methodology.** Numbered B1, B2, and so on, one per decision that changes a number: what was deduplicated and on what key, what was filtered and why, which tree an `n` came from, which grouper edition, how a median was taken. Every choice a competent reader would make differently is a choice you have to state. **The test for both: could a stranger reproduce a number in the body from the appendix alone?** If not, the appendix is decoration. ## The audit trail, and how it maps Every figure in the body traces to a receipt. Build the claim list BEFORE writing prose, check it, then write only what came back `entailed`. That order is not fussiness: assembling claims afterwards from finished prose is how a claim goes missing. Then call `deliver` with the text. It names every receipt you took and never checked, which is the one thing no checker can see by itself, and its reply is what tells you whether the document is finished. Three things that will bite, all measured: - **A decimal is read as rounded**, so `== 20.57` never passes. Claim the interval you are writing, as two claims at half a unit in the last written place. - **A selector you passed in may not be certifiable back to you, and the verdict is a thing to read rather than assume.** This bullet used to say flatly that a sentence naming the provider you asked about comes back `restates_input`. Measured 2026-08-29 against build `2026-08-27+4`, a sentence naming the payer that was passed as an argument came back `supported`. `hammer-provider-contracting` carries the same correction and the reason for it. Submit the attribution, read the verdict you actually get, and put an uncertified one under `asserted without a check`, in words. - **Text fields are not claim-checkable.** A payload-derived world declares numeric figures and flags, so `basis`, a methodology string, a counterparty name go to `judgement_check` or are quoted as the world's own words. Measured 2026-08-28. ## The claim report goes in the document Not as an appendix nobody reads: as the last page, in the shape `hammer-worlds` defines. World id, checker, session, receipts, then the entailed claims, then the refused ones with their remedies, then `asserted without a check`. **A reader who holds it can tell which sentences the world stands behind and which are yours.** That distinction is the product. ## Formats **Word**, when the reader is an operator and the document goes into a deck or a shared drive. `python-docx` for tables, headings and appendices. **An Artifact**, when the reader is a team and the document wants to be a link that stays current. Publishes private; the sender chooses when to share. **Markdown**, when it is going into a repository or an issue. The format is the last decision and the least important one. The section order and the two appendices are the document. ## A worked example, end to end The question: *what do NYU Langone's commercial contracts look like, and are they DRG based for spine?* 1. Route it with `hammer-provider-contracting`: contract structure is `filed_charge`, and the grouper argument is required. 2. Read the structure field first, not the price. Every payer-identified cell on the spine admissions came back `case rate`. **That is section 1**, and it came from a declared field rather than an inference. 3. The refusals arrive during the work, not after: codes from the edition this filer does not use come back `coverage/unknown-filer` naming the filer that does carry them. **That is section 6**, and the `edition_note` supplies its sentence: a filer's absence is not evidence it does not perform the admission. 4. The counterparty table, verbatim, with both row counts per cell. **Section 3.** 5. The facility dimension and what it does and does not let you split. **Section 4.** 6. What `n` counts and what a filed charge is. **Section 5.** 7. The patient side from its own corpus, clearly separated, never composed with the price side. **Section 7.** 8. Appendices A and B, then the claim report, then `deliver`. The document that comes out of that is not a transcript of the session. It is the thing the person asked for. 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