Methodology · version 1.1
We bill 20% of verified savings.
Here is what "verified" means, and what else we check.
A saving is billable only when your own billing data shows it.
This page describes the four mechanisms that exist today, and says plainly
where each one stops.
1 · Savings are verified against your own billing data
The source
For a Databricks
workspace, the hourly cost of the cluster we acted on comes from your
own system.billing.usage, priced at list
price, DBUs only. It is your billing data, read with the access you
grant — not a utilization estimate of ours. There is no verification
method for other platforms yet, so savings on them are not billed.
Before and after
The cost rate over
the 24 hours before the action is compared with the 24 hours after it,
skipping the partial hour in which it ran. Nothing is computed until
those 24 hours have passed and a further 24 have let billing data
arrive. Saving = (rate before − rate after) × 24 hours.
When it is not a saving
If more than a
quarter of the hours in either window have usage without a list price,
the result is insufficient — not estimated. If the cluster
cost nothing beforehand, there was nothing to save and nothing is
attributed. If cost rose after the action, the result says so; it is
not rounded to zero.
What it is not
A before/after
comparison, not a controlled experiment: a workload that changes on
its own between the two windows moves the result. Every result states
this method rather than adjusting for it with a model.
Only savings recorded as verified
are billed: 20%, rounded down to the cent. Each one is billed once and keeps
the amount and time it was billed, and the charge sent to Stripe carries
that record's identifier. If nothing is verified, the fee is zero.
illustration · hibernate · one Databricks cluster
| Before (24h, system.billing.usage, $492.00) |
$20.50 /hr |
| After (next 24h, $72.00) |
$3.00 /hr |
| Verified saving (($20.50 − $3.00) × 24h) |
$420.00 |
| Billed (20%) |
$84.00 |
2 · Every decision is recorded in a hash-chained ledger
Every verdict SafetyGate reaches — approved, escalated or
refused — is written to your ledger, and a change the ledger cannot record
is refused. Each entry's SHA-256 hash covers its own content, its position
and the previous entry's hash, so changing or deleting any past entry breaks
every hash after it; the dashboard's ledger panel re-verifies your chain.
For Databricks, each entry also records the identity that acted — a
service principal's application ID, or the user behind a personal token —
and the workspace it acted in.
What it
is not: tamper-proof. The chain makes a quiet edit detectable; it does not
stop someone with access to our database from rewriting the whole chain.
Anchoring the latest hash outside our database would close that, and is not
done yet.
3 · Every change carries a signed, single-use token
A change reaches your platform only with a token SafetyGate
issued for it: HMAC-SHA256-signed, bound to one action on one resource for
one customer — including its parameters, so a token to scale to 2 workers
cannot scale to 200 — valid for 15 minutes, and accepted once. A
missing, altered, expired or reused token is refused, and every change is
refused unless changes have been explicitly switched on.
4 · Onboarding is read-only
Connecting a workspace only reads: it lists clusters and SQL
warehouses, reads the connecting identity and cluster permissions, and runs
one SELECT … LIMIT 1 per system table to see which
are granted. A service-principal (OAuth) credential is stored only after a
token exchange and a cluster listing succeed with it, and nothing in your
workspace is changed. Changes begin only when you turn
optimization on and grant the permissions it needs — and then only through
the token and ledger above.
If you
disagree with a bill, email hello@digitaltap.ai
within 15 days of the invoice and we will go through the calculation with
you.
rd/assessment.html">View a sample assessment report