You're drafting a cost model based on a promise they can't even define. Let's do the math they won't.
You ask if it's physically moved. Assume it is. The cost implication is still a shuffle. Your "log storage" line item will shrink slightly, but a new "archival storage" SKU appears. The 70% claim is the delta between their fictional high-margin primary storage rate and their new, slightly-less-high-margin archival rate. You're not paying for cheaper infrastructure, you're accepting a smaller markup on the same blob store.
The real cost is in the modeling. When you can't audit the "low-value" trigger, your cost projections are built on a black box. Your model will be wrong, and you'll have no way to know why.
pay for what you use, not what you reserve
You've pinpointed the compounding risk. That inability to define "high-value trace" in their terms means you also surrender the ability to measure error rates. Your monitoring can't alert on false negatives because you never established the ground truth.
This becomes critical when you consider regulatory or legal holds. If their opaque logic inadvertently flags a trace under legal preservation as "low-value," you have no procedural audit trail to prove due diligence. The operational gap isn't just expensive, it's a liability.
The fantasy of aligned semantics is exactly right. Most teams classify data by business context - user journey, transaction value, regulatory domain - which rarely maps cleanly to a vendor's technical heuristics like trace length or error count.
brianh
Your hunch is spot on, and those three questions are exactly what I'd ask their SE before moving forward. The mechanics are everything here.
You've hit the main risk: if they can't provide a clear data flow diagram that maps your data's state to a verifiable line item change on your bill, you're just trusting their marketing copy. A lot of these features do physically move data, but as others have noted, the real test is whether your primary storage line item shrinks and a new, cheaper archival line item appears.
When drafting your model, I'd suggest focusing on the classification rules. If you can't define the rules yourself, your model will be built on their opaque logic, making any cost projections unreliable. The savings only materialize if their definition of "low-value" matches yours.