Skip to content

v0.9.0

Latest

Choose a tag to compare

@Kraidle Kraidle released this 06 Oct 06:52
· 1 commit to main since this release

Release notes: gate contract 1.1.0, effective 2026-10-06

Published on 2026-10-06, the day the service switched. The specification of version 1.1.0 is at https://github.com/KraidleAI/monark-kata-spec/blob/main/contract-1.1.0/CONTRACT.md. Its /openapi.json has sha256 61c9df97a254a863a68fdc2c493799803397bfa190b85db3ca97673d2a8ccbf0.

1. Timeline

  1. Before 2026-10-06, the service spoke 1.0.0 only.
  2. From 2026-10-06, it speaks 1.1.0 only. There is no period in which both versions are accepted.
  3. A prediction with schema_version "1.0.0" is refused with HTTP 400, code schema_version_unsupported. The message names the version the gate speaks (1.1.0) and where the specification is published. The message text is not part of the contract: read the code.

2. What changes for callers

  1. Version. schema_version is "1.1.0" in the prediction, the coverage verdict and the gate decision.

  2. Calibration digest. The verdict field calib_digest is removed and replaced by scores_sha256. The old field hashed the sorted binary64 scores. The new one is the sha256 of the canonical JSON writing of the scores, in the order the class's table file declares, or in your order for a calibration you send. The name changed because the definition changed.

  3. calibrate. The output field set_digest is removed and replaced by scores_sha256, computed by the same function as the verdict's, over your scores in the order sent. Reordered scores give another digest. The audit loop closes when scores_sha256, alpha and qhat of calibrate equal those of the verdict for the same scores, or when both answer under_calib.

  4. Exact rank. The split quantile rank is p = ⌈(n + 1)(1 − a)⌉, computed in exact integers. For a calibration you send and for calibrate, a is the decimal that the shortest round-trip writing of your alpha denotes, with no limit on decimals. For some (n, alpha) pairs the served qhat moves by one rank: for n 24 and alpha 0.44 the rank is 14, where 1.0.0 served 15. The ranks of stable-run-velocity-24h (n 613, alpha 0.1: 553) and liquidation-eligible-coverage (n 170, alpha 0.01: 170) do not change. No new refusal comes from this.

  5. Verdict fields. The verdict has 17 required fields. New: qhat_unit (label, scale or score), scale, cell_key, policy_row_sha256, policy_table_sha256. method may be risk-control.

  6. No region. When no region is served, region and qhat are null. In 1.0.0 an empty set stood for no region.

  7. Reasons. New reasons: calib_silence, calib_vetoed, calib_retired, out_of_support, region_degenerate. A zero-width additive band now answers region: null with region_degenerate, where 1.0.0 answered under_calib.

  8. Additive band edges. On stable-run-velocity-24h and on interval calibrations you send, the band edges are taken from the score test (specification, section 8). The served text of stable-run-velocity-24h no longer carries the sentence on edges rounded to the nearest double.

  9. Liquidation class. cell_key shows the stratum key the server looked up. Your predictor_id is not used for that lookup; this was already so in 1.0.0. On strata s1 to s3, which have no calibration, the served text is the class text and no longer the calibrated sentence of stratum s0.

  10. Decision. The decision gains request_sha256, the sha256 of the canonical writing of your request envelope.

  11. Error bodies. Every HTTP 400 body is {error, operation, message, code}, with issues on invalid_input. invalid_input and invalid_json bodies gain message and code (input_invalid, json_invalid). Codes come from the closed catalogue of the specification, section 13. /openapi.json describes code and the HTTP 500 body with code output_invalid.

  12. I-JSON requests. A request must be I-JSON (RFC 7493). A string with a lone surrogate (for example in intent or tool) or a number outside binary64 (for example 1e400 in yhat or intent) is refused with HTTP 400 param_invalid. In 1.0.0 these requests answered 200, except a lone surrogate in tool, which answered HTTP 500 output_invalid. Repeated object keys are still accepted (the last value is kept); do not send them. Refusals that existed already keep their code. calibrate with a score outside binary64 answers calibrate_input_invalid.

  13. Reserved class names. The pattern reserved against class names you supply widens from ^(btc|eth|bnb|sol)-(dir|range|mae-down|mae-up)-(1h|4h)$ to ^[a-z0-9]{2,10}-(dir|range|mae-down|mae-up)-(15m|1h|4h|24h)$. A name in that pattern, compared without ASCII case, is refused with byo_reserved_kata (btc-dir-15m keeps byo_overrides_committed), and a name equal to one of them once ASCII confusables are folded with byo_lookalike_confusable. For example, my-range-1h, xrp-dir-24h and eurusd-dir-1h were accepted with a calibration before 2026-10-06 and are refused from 2026-10-06. Choose another class name.

  14. Kata classes. The 32 classes {btc,eth,bnb,sol}-{dir,range,mae-down,mae-up}-{1h,4h} are served from their policy table files. No kata row is served at 2026-10-06: every well-formed kata call abstains with no region, with under_calib, or non_evaluable for a lean of exactly 0 on a dir class. The grid and staleness checks below run first. A kata request must carry:

    • predictor_id of the form kata:<kataId>@<venue>/<SYMBOL>/<h>, without bucket, <SYMBOL> starting with the class's symbol in upper case, <h> equal to the class's horizon (grammar in section 9 of the specification); otherwise kata_key_invalid;
    • features_digest; otherwise features_digest_required;
    • alpha and nMin equal to the class's values (0.45 and 6 for dir classes, 0.01 and 299 for the others); otherwise policy_alpha_mismatch or policy_nmin_mismatch, also when no row applies;
    • on dir classes, tau at most 1; otherwise policy_tau_cap;
    • yhat a number (otherwise yhat_type_mismatch) in the class's domain (a lean in [−1, 1], or a sigma_hat greater than 0); otherwise kata_yhat_domain;
    • produced_at on the horizon grid (seconds 00, every fraction digit 0, the instant a multiple of the horizon); otherwise produced_at_off_grid;
    • a call received at most 300 s after produced_at; otherwise produced_at_stale.

    A lean of exactly 0 answers non_evaluable, after all the checks above.

  15. Tool schemas. The output schemas of gate and calibrate, and the description of gate, change in tools/list and in /openapi.json with the formats above. /openapi.json also describes the HTTP 400 and 500 bodies of item 11 and lists the existing HTTP 413 answer (request body too large) on every operation. The input schemas do not change.

3. What does not change

  • The decision order (specification, section 6).
  • The params fields and their meaning. alpha and nMin remain required on every call. On a class that imposes them, a different value is still refused, never replaced.
  • The produced_at grammar and the 300 s future check.
  • The attestation formats AttestedPrice, AttestedFlow and AttestedBook keep schema_version "1.0.0". A request that carries attested is still refused with attested_inconsistent.
  • The reserved key prefix kata:. btc-dir-15m still answers task_class_retired.
  • No existing error code is renamed or reused. A code you do not know must be read as a refusal.

4. What callers must do

  1. Send schema_version "1.1.0".
  2. Read scores_sha256 where you read calib_digest (verdict) or set_digest (calibrate). Values stored under the old fields cannot be compared with the new ones.
  3. Accept region: null, the new verdict fields and the new reasons.
  4. Send I-JSON: no lone surrogates, no number outside binary64, no repeated object keys.
  5. Send alpha and nMin on every call; on kata classes, the class's values.
  6. If you supply your own calibration under a class name in the widened pattern, rename the class.
  7. On kata classes, follow the request rules of section 2, item 14, and handle the 400 codes listed there.
  8. Read errors by code, not by message.
  9. If you cached the tool schemas from tools/list or /openapi.json, fetch them again.
  10. If you installed a copy of the MONARK skill, update it from the public mirror.

5. Where the specification lives

The specification, its conformance vectors, its schemas (prediction, coverage-verdict, gate-decision, policy-row, tool-error) and the policy table files are published in the directory contract-1.1.0 of https://github.com/KraidleAI/monark-kata-spec. Versions are published in their own directory and never withdrawn. These notes are also the release notes of the public mirror, release v0.9.0.