predict
Record a falsifiable prediction so it can be resolved later and fed into calibration.
Past predictions become the foundation of assess and calibration: an instinct earns trust by being measured.
Signature
predict({
prediction: string,
domain: string,
confidence?: number,
basis?: string
}) → { id: number, domain: string, confidence: number }
| Param | Type | Required | Description |
|---|---|---|---|
prediction | string | yes | What you expect to happen. State it falsifiably. |
domain | string | yes | Short label that groups predictions for calibration. |
confidence | number 0..1 | no | How sure you are. Default 0.5. |
basis | string | no | Why you think this. Useful when you later review surprises. |
Example
curl -X POST https://mneva.dev/v1/predict \
-H "x-mneva-key: $MNEVA_KEY" \
-H "content-type: application/json" \
-d '{
"prediction": "the migration will need a hotfix",
"domain": "schema",
"confidence": 0.4,
"basis": "the v2 backfill is doing two passes — easy to miss a NULL"
}'
Response:
{ "id": 2, "domain": "schema", "confidence": 0.4 }
When the migration runs, resolve the prediction with resolve.
Picking a domain
Domain is the calibration key. calibration returns per-domain accuracy and confidence gap; assess matches on domain to find adjacent predictions for the track record block.
Good domains are nouny and re-usable:
deployschemauser-flowauthrate-limitsmigrationpricing
Avoid one-off domain names — deploy-2026-05-22 would never accumulate enough resolved predictions to be useful. Same domain, repeated, lets calibration build a track record over time.
A given prediction can only have one domain. If a prediction crosses two areas, pick the one most likely to repeat.
See also
resolve— close itpredictions_open— list unresolvedcalibration— per-domain track record