Docs
Risk marks & scoring specifications
Marks are model scores from observable control-plane evidence. They are versioned methodology (v1), not calibrated empirical failure probabilities until partner outcome backtests exist.
Public disclosure policy: We publish what each mark means, which signal families feed it, and how to read outputs. We do not publish exact component weights, dollar friction constants, index blend weights, or detection thresholds that would enable gaming or clone reproduction of the engine.
3.1 Standardized Interruption Rate (SIR)
Scale: 0.01–1.0 (probability-like for readability; not a guarantee of job failure rate)
Signal families (blended model):
| Family | What buyers should know |
|---|---|
| SLA / verification prior | Reliability and verification tier inform interruption risk when history is thin |
| Downtime history | Repeated offline / disappearance events raise risk (saturating) |
| Listed availability | Lower advertised availability raises risk |
| Capacity / availability trend | Snapshot-to-snapshot deterioration raises risk |
| Verification downgrade | Recent drops in verification status raise risk (decays with time) |
| Fingerprint continuity | Longer healthy presence lowers risk; fragmented presence raises it |
Workload profiles (e.g. LLM fine-tuning vs batch inference) scale SIR sensitivity to match job economics.
Cold start: Without snapshot history, temporal families are weak; priors dominate. Signal coverage (below) makes that visible on every row.
Important: SIR is a ranking and comparison score, not a calibrated probability of interruption until backtested against provision outcomes.
3.2 Pipeline Integrity Score (PIS)
Scale: 0–100 (higher = more control-plane evidence supporting reliable execution for that row)
PIS combines penalties from:
| Driver | Public definition |
|---|---|
| Interruption model (SIR) | Higher modeled interruption risk lowers integrity |
| Control-plane latency | Continuous penalty on broker API responsiveness (smooth curve; no step cliffs) |
| Execution-risk inventory signals | Listings whose verification, availability, ghost score, or history suggest inconsistent execution reliability take an integrity hit |
What “ghost inventory” means here (and does not mean):
- Does mean: The listing’s observable signals (verification tier, availability, continuity, downtime history) are inconsistent with reliable execution availability for the stated workload.
- Does not mean: “This GPU does not exist,” “the host is fake,” or “hardware was never installed.” We do not claim to verify physical presence.
The PIS ≥ 70 gate (operational threshold)
Quote’s default gate excludes rows with PIS < 70 from risk-adjusted rankings.
| Fact | Implication |
|---|---|
| 70 is an operational decision threshold | Chosen for demo and product defaults to separate clearly weak rows from the comparison set |
| Not a statistically derived failure boundary | It is not backed by a published false-positive / false-negative curve |
| Not “safe” vs “unsafe” at ±1 point | PIS 69 is not “objectively unsafe”; PIS 71 is not “objectively safe.” Scores are continuous; the gate is a filter, not a certification |
| Configurable | Partners may set a different threshold; rankings should always be read with signal coverage |
Use PIS to sort and filter listings relative to each other, not as a pass/fail certificate on a single host.
3.3 True Risk-Adjusted Cost (TRAC)
TRAC = base_cost + egress_loss + risk_premium
| Component | Definition |
|---|---|
| base_cost | listed_spot_price × task_hours |
| egress_loss | Network fee × data GB (when fee lineage supplies a rate), scaled by workload profile |
| risk_premium | Modeled charge from SIR and resubmission friction assumptions |
How to read the risk premium (critical)
The risk premium is not “expected economic loss” and not “SIR × friction = dollars you will lose” unless SIR has been calibrated against actual interruption outcomes for your lane and workload.
| What TRAC risk premium is | What it is not |
|---|---|
| A structured comparison against naive listed cost | A forecast of realized spend |
| A way to rank listings when restart / engineer-time economics matter | Proof that a cheaper host would have failed |
| Explicit about assumptions (workload profile, friction model) | A substitute for your own provision logs and SLAs |
Practical use: Compare Listed vs TRAC and Δ across rows in the same lane. Treat TRAC as “what this job costs under our model if interruption risk materializes,” not as a guaranteed bill.
Friction defaults are engine implementation details. Product APIs may later expose buyer-configurable knobs; public docs do not publish fixed wage or burn constants.
3.4 TRAC fee lineage
Egress honesty depends on adapter provenance:
| Source | Meaning | Example |
|---|---|---|
| Observed | Fee taken from listing/API fields | Provider-reported $/GB when present |
| Estimate | Documented platform default when catalog has no $/GB | Conservative estimate for catalogs without egress fields |
| Zero assumption | Field not supplied; egress term is 0. We do not claim transfer is free | Many managed catalogs today |
3.5 Stability & signal coverage
| Mark | Scale | Meaning |
|---|---|---|
| Provider stability | High / Medium / Low | Categorical pre-provision reliability from verification, execution-risk signals, downtime, latency, and SIR |
| Signal coverage | 0–100% | How much evidence backs the scores: listing metadata + tape history + probe + fingerprint identity |
Low coverage means scores lean on priors. Prefer high-coverage rows for production routing decisions.