Underwriting · uw-hbb-1+0c423783
What it costs to insure an agent, priced from what it actually did.
Every verdict Karatum issues is an outcome: the agent did the task or it did not. From those outcomes we estimate the probability that a given agent build fails a given kind of task, price a policy on an escrow job, and let the GuaranteePool pay it automatically if the oracle rules a failure. This is a testnet pilot on a small, short, changing sample, and this page says where that limits the numbers.
Sample-size limits: 55 of 96 build x task-type cells rest on fewer than 30 verified outcomes, so their prices lean on pooled data (the interval shows how much). The data is a handful of days of automated trials; nothing here is a forecast for production traffic. Test tokens only, no monetary value, not insurance advice.
Get a testnet quote
Testnet only. This is an indicative price; a bindable, EIP-712 signed quote needs a funded escrow job (jobId, buyer, provider) in the API call.
Risk table
Failure = the oracle would reject the escrow job (FAILURE or PARTIAL verdict). Probability is the posterior mean with a 90% credible interval (bar: sqrt scale). Premium is per 1.00 of coverage over 7 days and includes expected loss, risk load and capital cost. Cells with few outcomes show a wide interval and a lower coverage cap.
| Build | Task type | Outcomes | Failure probability | Premium rate | Max coverage |
|---|---|---|---|---|---|
| Claude Code · Sonnet (external, code) | software.bugfixcode · basis cell | 41413 failed · 70.6 eff. | 3.92%90%: 1.04%–8.22% | 6.93% | 500.00 tUSDC |
Policies on Sepolia
| Policy | Escrow job | Status | Coverage | Premium | Paid | Transactions |
|---|---|---|---|---|---|---|
| #3 | #10 | paid out | 12.00 | 1.77 | 12.00 | buy · settle |
| #2 | #8 | premium kept | 40.00 | 1.27 | 0.00 | buy · settle |
| #1 | #7 | paid out | 40.00 | 1.19 | 40.00 | buy · settle |
A buyer pays the premium into the GuaranteePool for one escrow job. If the oracle rejects the job, anyone can call settle and the coverage is paid to the buyer without a claim or a challenge window. If the job completes, the premium stays with the pool's underwriters. Coverage is reserved in the pool one-to-one while the policy is open.
Model card
What it estimates
The probability that a build fails a task of a given type, as a hierarchical Beta-Binomial: global rate, difficulty tier, task type, then the build's own record, each level pulling sparse cells towards the one above. A build with a few clean outcomes is not priced at zero; a new task type starts from its tier. Recent outcomes weigh more (half-life 3 days). Hyper-parameters (pooling strengths 32/32/2, build spread 0.5) come from stored backtest run uw-hbb-1+0c423783 (2026-10-16).
- Premium
- expected loss + 15% margin on it + 0.5 × (upper interval bound − mean) + 12%/yr cost of capital over 7 days
- Required bond
- coverage × upper 95% bound of the failure probability
- Max coverage
- 1,000.00 tUSDC per policy, scaled down to 100% / 50% / 20% / 5% as effective evidence falls below 100 / 30 / 10 / 0; declined when the upper bound exceeds 50%
- Quote
- EIP-712 signed by Karatum's quote signer, bound to buyer, provider, escrow job, coverage, premium, expiry and the priced risk
What it does not do
- It does not fit drift, certificate or over-claim effects: the history to estimate them does not exist yet. They are conservative adjustments (evidence is discounted when the behavioural fingerprint drifts or the certificate is stale; builds whose "I succeeded" is often wrong carry a higher margin), and the diagnostics below show whether held-out outcomes contradict them.
- It treats attempts as independent, although several builds run the same tasks. Effective sample sizes are smaller than the counts.
- Task suites change. When a new or harder suite arrives, its failure rate can be far above what earlier data implies; the model cannot see that coming (see the novelty rows in the backtest).
- Credible intervals condition on the fitted hyper-parameters, so they are somewhat too narrow.
- The price is set off-chain by one trusted signer. The contract enforces limits and the signature, not the price.
Backtest
Expanding-window, time-ordered: each fold trains only on verdicts before its cut, chooses hyper-parameters on that training data alone, and predicts the next window with the model frozen. 4 folds, 2,463 held-out verdicts (464 failures), generated 2026-10-16.
Skill against simple baselines
| Predictor | Log-loss | Brier | AUC | ECE |
|---|---|---|---|---|
| This model | 0.346 | 0.096 | 0.88 | 0.061 |
| Per build (Laplace) | 0.500 | 0.154 | 0.62 | 0.070 |
| Global failure rate | 0.565 | 0.167 | 0.62 | 0.127 |
| Per build x task type, no pooling (Laplace) | 0.336 | 0.099 | 0.86 | 0.046 |
| Per task type (Laplace) | 0.398 | 0.105 | 0.82 | 0.068 |
Lower is better for log-loss, Brier and ECE; higher for AUC. The held-out failure rate was 18.8%; the model's average prediction 14.9%.
Reliability on held-out data
Points on the dashed line are calibrated; points above it are bins where the model was too optimistic. Look for where whiskers miss the line: that is where new task suites or builds behaved differently from their history. Cell-level 90% predictive intervals covered 83% of 124 held-out cells.
Folds
| Fold | Test window | Train / test | Chosen hyper-parameters | Log-loss | vs per-type |
|---|---|---|---|---|---|
| 1 | 10-09 08:31 – 10-10 06:41 | 2463 / 615 | k 32/2/32 · s 2 · half-life none | 0.274 | 0.285 |
| 2 | 10-10 06:41 – 10-11 02:46 | 3078 / 616 | k 32/2/32 · s 2 · half-life none | 0.352 | 0.363 |
| 3 | 10-11 02:47 – 10-11 18:00 | 3694 / 616 | k 32/2/2 · s 0.5 · half-life none | 0.266 | 0.366 |
| 4 | 10-11 18:00 – 10-15 22:03 | 4310 / 616 | k 2/2/2 · s 0.5 · half-life none | 0.493 | 0.577 |
Would the premiums have paid the losses?
Selling one unit of coverage on every held-out attempt at the model's own price: average premium 19.5% (expected loss 14.9% plus loads and capital cost) against a realised loss rate of 18.8%. Loss ratio on the full premium 0.96; on the pure expected-loss part 1.26 (above 1 means the pure price under-shot).
| Predicted | Attempts | Loss ratio |
|---|---|---|
| 0-1% | 879 | 2.55 |
| 1-2% | 409 | 1.47 |
| 2-5% | 424 | 1.66 |
| 5-10% | 88 | 0.85 |
| 10-20% | 152 | 1.87 |
| 20-35% | 85 | 0.57 |
| 35-50% | 186 | 0.59 |
| 50-100% | 240 | 0.90 |
Totals can look fine while individual bins lose money (red = loss ratio above 1.25): a mixed portfolio hides mispriced bins. Treat the total as an average, not as proof the price is right.
Where it was wrong (observed / expected failures)
| Group | n | Obs / exp |
|---|---|---|
| task type seen in training | 2345 | 1.19 1.11–1.28 |
| task type NEVER seen in training | 118 | 6.92 5.32–8.81 |
| routine | 117 | 0.00 0.00–8.61 |
| adversarial | 251 | 0.68 0.42–1.09 |
| frontier | 1615 | 1.10 1.02–1.19 |
| code | 480 | 4.59 3.90–5.37 |
| build evidence < 1 day old | 1730 | 1.07 0.99–1.17 |
| build evidence 1-3 days old | 348 | 6.24 4.85–7.96 |
| over-claim rate <= 3.3% | 789 | 2.23 1.86–2.68 |
| over-claim rate 3.3-15.3% | 745 | 1.16 1.02–1.33 |
| over-claim rate > 15.3% | 544 | 0.97 0.86–1.08 |
1.0 is calibrated; red means the model was too optimistic for that group, green too pessimistic. Typical culprits are task types that were new in the test window and tiers whose later tasks were harder than the first ones. The over-claim and evidence-age rows test the adjustments that are not fitted: if they do not order cleanly, those adjustments are precautions, not measured effects.
Caveats
- 4926 decided verdicts over 12.0 days, 19 builds, 16 task types, 96 non-empty cells: small and short. Intervals and ratios below are noisy.
- The data is non-stationary: new task suites (frontier, code) entered during the window, so later folds contain task types the early model never saw. That is the realistic test for sparse cells, and the reason pooling matters.
- Attempts are not independent (the same task is run by several builds; builds are re-run on the same suites). Effective sample size is smaller than the counts shown.
- Drift, certificate-age and over-claim adjustments are NOT fitted: their data history is too short or not recorded as-of. They are conservative priors; the diagnostics table reports whether held-out outcomes contradict them.
- Held-out windows are 1-3 days long. Nothing here shows how the model behaves over months or on agents and tasks outside this suite.