hammer-savings-classification Scope: world hammer-coverage-intelligence vintage 2026-10-01 Revision SHA-256: 261a847ed4707d3c53a053a1549e717c3fba818b60fe30dc0c3ee9b0abee9480 --- name: hammer-savings-classification description: Use when a saving has to be classified before it can be argued: whether a mechanism is hard or soft, which of the two savings methodologies a business case falls under, what evidence each is held to, and why a hard figure and a soft figure are never added together. Carries this world's definitions of hard and soft in full, the closed vocabulary of six mechanisms with each one's classification and the reason it follows, the shape of the ROI model each methodology implies, and the population chain that decides who books the saving. This is the source savings_methodology names in every payload it serves, so a reader holding a classification can check it here rather than taking it on trust. Read hammer-cost-of-care-case for the plan-side framing these classifications sit inside, and hammer-vendor-evidence if you are the one submitting the case. --- # hammer-savings-classification `savings_methodology` classifies a declared savings mechanism as hard or soft and names the evidence a case built on it is held to. Every payload it serves cites this file as the source of that mapping. That citation is the reason this file exists. A served classification has to name a source the reader can go and read, and a document they cannot obtain is a citation they cannot check. So the definitions are published here, in the same build that serves the tool, and the payload says so. **`tools/tools.json` is the authority on what the tool takes.** This file is the definition the tool classifies against. Where the two disagree, the tool surface is right and this is stale. ## The choice that comes before any modelling A cost-of-care business case falls under one of two savings methodologies, and which one is picked decides the whole shape of the model that follows. Picking it after the arithmetic has started is how a case ends up with one number and two evidence classes behind it. **Cost savings, the hard case.** Any action producing a tangible benefit that lowers current spending today. Think reduction, and think immediate. It reaches the plan's spending through one of three routes: **reducing demand that was not legitimate in the first place**, **paying a lower unit price for the same service**, or **recovering money already paid in error**. **Gross savings, the soft case.** Any action that moves medical trend or avoids a cost being incurred in the future. Think avoidance, and think long run. It reaches the plan's spending by **redirecting demand that was legitimate** into a cheaper setting, or by improving outcomes over a horizon. The legitimate-versus-not axis is the one people get wrong. Stopping an avoidable emergency visit removes demand that should not have existed and lands on paid claims. Moving a legitimate visit from an emergency room to a telehealth channel does not remove the demand: it relocates it, and the saving is the difference between what the visit cost and what the counterfactual visit would have cost in a setting it never happened in. The first is hard. The second is soft, no matter how confident the redirect rate is. ## Hard and soft **A hard saving is a reduction evidenced in adjudicated paid claims against the prior period's run rate, expressed on a plan membership basis.** The dollars are on claims somebody actually paid. You can point at them. **A soft saving is modelled against a counterfactual that no adjudicated claim ever records, so its evidence is the model and the declared assumptions behind it.** The dollars are the difference between what happened and what a model says would otherwise have happened. Nothing recorded the second one. The split is an ordinary convention in medical-cost work rather than anything this world discovered. What this world adds is that the classification is served with its reason attached, and that the tool refuses to interpret prose: you declare a mechanism from a closed vocabulary of six, and the mapping is fixed. ## The six mechanisms Declare one of these as `mechanism`. A name outside the vocabulary is refused naming the vocabulary, never mapped to the nearest spelling, because the classification is what decides the evidence class. ### `unit_cost_reduction` is HARD The same services are delivered and each unit is paid at a lower rate. Hard because the lower rate shows up on the claims that are actually paid, so the reduction is read off the run rate rather than modelled. **Evidence required:** adjudicated paid claims for the same code mix, before and after, incremental to the prior period's run rate and expressed on a plan membership basis. ### `utilisation_reduction` is HARD Fewer units of service are delivered, at the same rates. Hard because the missing units are missing from the paid claims themselves, so the reduction is observed. What remains modelled is only its attribution. **Evidence required:** adjudicated claim counts against the prior period's run rate, with regression to the mean netted out of any selected cohort. `regression_to_mean_expectation` computes that correction from declared inputs. ### `demand_redirection` is SOFT The same demand is met in a cheaper setting or channel. Soft because half of the arithmetic is a counterfactual, what the visit would have cost in the setting it did not happen in, and no claim records that. **Evidence required:** a modelled counterfactual with every redirect rate declared and carried as cited or assumption. Redirect benchmarks are normally one plan's own internal planning assumptions and enter as `cited`, never as `measured`. Declaring one `measured` is refused, and that refusal is the tool working. ### `avoidance_of_future_cost` is SOFT A cost that would have been incurred later never occurs. Soft because the avoided cost never appears on any claim in any period, so it exists only in a model, and part of what such models call avoided is merely deferred. `deferred_versus_avoided` separates the two and refuses to add them. **Evidence required:** a declared event model separating prevented costs from moved ones, with timings and a discount rate declared, and a design that supports the counterfactual rather than assuming it. ### `overpayment_recovery` is HARD Dollars already paid in error are identified and recovered. Hard because a recovery is a ledger entry against an adjudicated claim, so the dollars are observed rather than modelled. **Evidence required:** the recovery ledger tied to the adjudicated claims it corrects. This world sits on the contracted-pricing leaf, holds no adjudications, and classifies this mechanism without serving any figure for it. ### `adherence_improvement` is SOFT Members take their prescribed therapy more consistently, avoiding downstream events. Soft because the saving runs through two modelled links before any dollar, from adherence to avoided clinical events and from those events to costs, and each link is a counterfactual no paid claim records. **Evidence required:** a cited clinical pathway from adherence to event rates, plus a modelled cost per avoided event, each carrying its own source and basis. ## Hard and soft never sum **This is the refusal the tool checks first**, ahead of the missing-mechanism check, because a caller who asked only for the total has already asked the forbidden question and telling them a field is missing would read as "supply it and the total will be served". A claims-evidenced reduction added to a modelled counterfactual is one number with two different evidence classes behind it, and a reader of the total cannot tell which dollars were observed and which were hoped. So an argument key shaped like a total, a sum, a combination, or a plus is refused under `coverage/bad-input`. Classify each mechanism separately and let each figure carry its own evidence class. The same rule keeps `deferred_versus_avoided` from adding a moved cost to a prevented one. **The refusal is not a limitation you route around by doing the addition yourself.** Adding the two figures by hand produces exactly the number the tool declined to produce, with none of the evidence classes attached. If a total is genuinely wanted, it is two figures reported side by side, each labelled. ## Sizing the population before sizing the saving A savings figure is a rate applied to a population, so the population has to be pinned before the rate means anything. The chain, narrowest at the end: 1. **Line of business.** Commercial or government, and within government, Medicare against Medicaid, which are different populations under different rules. 2. **Group segment.** Individual, small group, large group, or national account. Employer size changes both the contract and the appetite. 3. **State or region**, where the solution actually operates. 4. **Funding type**, and this is the one that decides who books the saving. Under a **fully insured** arrangement the carrier holds the risk and a reduction in medical spend accrues to the carrier. Under **administrative services only** the employer is self-insured and holds the risk, and the carrier is administering claims for a fee. The same clinical result is the carrier's saving in one and the employer's in the other. A case that does not state its funding type has not said whose money it saves. 5. **The clinical population**, by condition. 6. **The share of that population the solution actually reaches**, with the reason for that share stated. `cost_of_care_exposure` sizes a declared population. It does not pick one for you, and a case that skips step 4 is one this world's refusals will find. ## What an ROI model of each shape contains Both shapes are a savings side and a cost side, and the difference is entirely in what makes the savings side legitimate. **The savings side** is a unit cost, a volume, and a rate of change applied to them: cost per encounter, encounters per member per year, and the share of those encounters the solution removes or moves. On a hard case the unit cost and the volume are read from adjudicated claims. On a soft case at least one of the three is a counterfactual, and it is normally the rate. **The cost side** is the part that gets thin in weak submissions. It is not just licence fees. It includes integration work, the initial business cost of standing the thing up, marketing and member outreach, and the recurring technical cost of keeping it running. Outreach in particular is often left out and is often the difference between a case that clears its threshold and one that does not. **Ramp is not optional.** A solution launched partway through a year captures a fraction of a year's savings while carrying a year of cost, so a first-year return can be negative on a case whose multi-year return is strong. Report the first year and the multi-year figure separately rather than only the one that flatters. **A minimum impact threshold is what the whole exercise is for.** A plan has more candidate use cases than slots, so the question is not whether a solution saves anything but whether it clears the bar for a slot. `candidate_screen` partitions declared candidates and never scores them. ## This world will not supply your benchmarks Redirect rates, avoidable-encounter shares, and impact rates are the numbers that decide a soft case, and **this world holds none of them.** They circulate as one plan's internal planning assumptions, and an assumption borrowed from somebody else's planning document is not a measurement of your population. So they are declared by the caller and carried as `assumption`, or cited to a source the reader can obtain and carried as `cited`. Declaring one `measured` is refused by name. That refusal is the single most useful thing this world does to a business case, because a borrowed benchmark presented as measured is exactly the defect an actuarial review exists to catch. Definitions behave the same way. **Avoidable emergency visit** and **readmission** are not self-evident: a readmission needs both a cause rule (all-cause against condition-specific) and a time window (30 day against 90 day) before a rate computed from it means anything, and two cases quoting different rules are not comparable. State the rule with the figure. ## What the payload carries, and what it does not `savings_methodology` **carries no number anywhere.** It says what declaring the mechanism commits the caller to, whether it is hard or soft, why that classification follows, and what evidence would support it. It is **not** a savings figure and **not** evidence that the declared mechanism operates. Whether the mechanism delivers anything is settled by the evidence class named above, which this world does not hold: there are no paid amounts here and no adjudications. The `basis` on the answer is the weakest input, and the caller's own account of how their saving works enters as `assumption`. The definitions it is classified against enter as `cited`, sourced to this file. ## Where this sits - **`hammer-cost-of-care-case`** is the plan-side framing: whether a use case earns a slot, the minimum impact threshold, and the paid-amount wall that decides these sessions. - **`hammer-vendor-evidence`** is the same standard read from the submitting side. - **`deferred_versus_avoided`** separates a moved cost from a prevented one, and is where `avoidance_of_future_cost` cases go next. - **`regression_to_mean_expectation`** is the correction a `utilisation_reduction` case on a selected cohort owes before its attribution stands. - **`cost_of_care_exposure`** sizes the declared population the rate applies to. - **`candidate_screen`** partitions declared candidates against a threshold. 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