v0.9.0

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.

v0.8.0

v0.8.0 - a retired gate class, stable refusal codes, exact engine arithmetic

This release follows v0.7.0. It carries the gate the harness serves since 2026-10-04: one class retired, every refusal named by a stable code, stricter checks on caller-built names and on the committed USDe key, and engine functions that compute the split rank exactly.

What is served

• The gate class btc-dir-15m is retired. A call that names it returns 400 with the code task_class_retired; no served class now carries an attestation subject, so a caller-carried attested price is refused on every served class.
• Every 400 answer of the gate carries a stable error code beside its message, from a closed list of 24 codes exported with the harness (HARNESS_ERROR_CODES). A caller can branch on the code; the message text stays human-readable and may change.
• A BYO task class or predictor name that reduces to a committed or reserved name once common ASCII look-alikes are folded (for example l, I and 1; rn and m; 0 and O; _, . and -) is refused with byo_lookalike_confusable. Names reserved for the kata prefix are refused with byo_reserved_kata. Look-alikes outside this closed folding still pass; they are declared as a residual class.
• The committed USDe key of stable-run-velocity-24h takes alpha 0.1 and nMin 50, imposed by the server; any other value returns 400 (policy_alpha_mismatch, policy_nmin_mismatch).
• The gate's description now states that each band edge is yhat - qhat or yhat + qhat rounded to the nearest double, so it can differ from the exact edge by up to half a unit in the last place.

What changes in the code

• @monark/hikae gains an exact split rank computed in rational arithmetic, a one-pass search for the risk-control row, a scaled band and a single canonical writing of a calibration row. The served decisions are unchanged by them: 84 recorded calls, replayed before and after the deploy, differ only where the gate changes listed above apply.
• The site pages that described the retired class now describe it as retired, and the committed copies of what the harness, Narabi and Ukemi serve were re-read from the hosts after the deploy.
• The recorded end-to-end trace of the gate was re-recorded against the served tool list.

v0.7.0

v0.7.0 - Dōjō hold snapshot and its verifier, site documentation, a committed Ukemi stratum

This release follows v0.6.0 and the README updates published after it. It adds to this repository the reader's verifier of the MONARK Dōjō, whose host now serves a first daily hold snapshot, signed and chained; it adds a documentation section to the site; and it carries the committed calibration of one stratum of Ukemi's gate class.

What is served

• A new host, https://dojo.monarkgate.tech, publishes the MONARK Dōjō hold snapshot: a dated, public record of the MONARK token balances held by each address, read from the chain through two distinct operators, with a hold score per address. Each line of its timeline is signed with Ed25519 and carries the hash of the line before it; a day's lines file is bound to its signed line by its SHA-256, its count and its Merkle root. The copy committed with this release holds the first daily snapshot (day 2026-10-02, counted, four of four scheduled readings) and a history file that rebuilds the earlier days from the token's creation. The hold snapshot stays upcoming in the Dōjō register, and its page shows that status.
• The reader's verifier is exported to this repository with the public keyring it takes as its trust root: node apps/dojo/scripts/dojo-verify-cli.mjs --url https://dojo.monarkgate.tech --keyring apps/dojo/keys/dojo-keyring.json (a local copy of the served tree can replace --url). From the served files alone it recomputes the signed chain of the timeline (Ed25519 signatures under the supplied keyring, the chaining, the key windows), every unit version, the history file, the lines of every snapshot and their Merkle root, and, on request, the inclusion proof of one address (--address) and a past day (--day). It does not replay the collection: the readings are what two operators reported, and a signature attests origin, never the truth of the readings. It does not read the chain, does not check the BLS signature of the public randomness beacon (its report says so), and does not replay the conformity check of the host's deployment; the collector, the publisher and that check stay out of this export.
• The served gate class liquidation-eligible-coverage holds a committed calibration for one stratum of one recorded episode, as read from the served harness: for a caller-carried liquidable amount in that stratum it returns a conformal upper bound, whose lower edge is 0 by construction, and the three other strata abstain (under_calib). The bound holds only if the amount was produced by the frozen close-factor rule, which the gate does not check, and no coverage is claimed on any other event; the served description says both. The cascade tool stays transitional and abstains by construction.
• Beside the Narabi tracker, https://monarkgate.tech/narabi/instrument.json is a diagnostic file written once from a closed block of days, never by the daily job: tracker replays at alternative parameters, and a one-sided CUSUM on the static misses assessed by a permutation test of exchangeability. It is not the official tracker, it claims no bound, and no page reads it.
• MONARK Bell's published records have their own anchors register, beside the register of the counter-verification run: line 2 of the Bell timeline, the latest publication in the committed copy, has a manifest (the line's hash, the hash of the timeline up to that line, the digests of the state and provenance files it names) and an OpenTimestamps proof, both served under /bell/anchors/. Read with the site's own reader, the proof records Bitcoin blocks. An anchor shows that the line and every line before it existed before that block; it does not show that the facts are true, nor when the data was collected.

What changed in the code

• Site, documentation: a new section at /docs, in eleven sections (overview, the gate, the pieces, MONARK Bell, Ukemi, Narabi, integrators, use cases, DeFi research, verify it yourself, glossary), with one page for each of the eleven pieces of the register. Names, statuses and counts are read from the register and figures from committed, hashed data; the research page states literature results in words, attributed to a committed bibliography that gives the reading level reached for each work.
• Site, applications and navigation: /applications replaces /products, which redirects to it permanently. MONARK Bell, the built application, has a card with its served note, its latest signed record and links to its page and to its signed timeline; the upcoming applications stay placeholders. The header reads Applications, Fleet, How it works, Building (the /roadmap page, now titled MONARK Building), Token, Integrators, Docs and Dōjō snapshot; the footer follows. The home page and MONARK Building derive the count of frozen contracts from the schemas and name the one not served yet.
• Site, Dōjō: /dojo renders the hold snapshot from a committed, hashed copy of the served files, with the register's status beside the program's name. A browser that can check Ed25519 signatures rereads the published timeline and lines file and replaces the committed figures only when every check holds; the table of lines and the address look-up run in the browser, and the address entered is not sent anywhere. The token page links to it.
• Site, Narabi: /narabi opens on a committed capture of the two published files, which replaces the former snapshot module, with its checks recomputed at build; it then rereads the files as served and recomputes each line's hash, the chain, and that the timeline served now extends the captured one byte for byte. Each line's list of endpoint URLs is kept as a count only. The home page and /fleet carry a freshness line for Narabi: the day of the last published window, the tracker step and whether a window is late, judged against the committed publication schedule and the external probe's deadline.
• Site, Ukemi: /ukemi shows the figures of the committed stratum (calibration points, bound margin, calibration digest, the day the served verdict was read), read from two committed, hashed files that must agree, or the build fails; the committed course report adds the digests of its inputs, and the fleet panels describe the gate's bound as delivered only once a calibration is committed.
• Site, Bell: /bell is rebuilt around what the host serves (the host, the key, the first record, the latest publication and its per-session rows, read from the files bound to the signed line) and states the latest record's timestamp state as read from its proof file. The hero scene is a native component that pauses out of view; the framed scene file it replaces is removed. A section to request a symbol or early access carries a copyable template. /bell/method states the served schema, and /bell/terms reads its last-updated date from committed data.
• Site, served facts and wording: /integrators and /console read the committed, hashed facts of the served harness, and the site's data manifest pins every new committed file by its SHA-256, the build failing on a mismatch. B_t is described as the served gate treats it: carried by the caller, sent with each call and returned unchanged, with an abstention when it is below the caller's floor; the gate simulation says that it spends B_t only inside the simulation. How it works adds the narrower statement the gate serves for its one class calibrated on measured flow. Shōgen's served scope reads the same on three surfaces: the attest tool and its one committed witness, while the full sensor is under test and not served. The site's description reads two sides, one engine. Source comments drop internal record references, and the component provenance file records the new components.
• Harness: the liquidation-eligible-coverage registry gains its committed stratum, written by an emitter from the output of a frozen generator, never by hand, and checked against its pinned digest at load; strata under one hundred calibration points are not committed. The gate tests now expect the committed clause and the abstention on the other strata. The harness README documents the optional caller-carried attestation of the gate envelope and the committed calibrations. The episode's input series are not in this export; the export manifest names them.
• Sentinel: a separate instrument-replay entry rebuilds instrument.json offline with its own digest. It refolds every window through the attest and step engine of the daily job, fails closed on the first defect, never writes state.json, and refuses an output under a public directory without --publish. The daily job reads an optional host exclusion list, MONARK_SENTINEL_EXCLUDE_HOSTS, for the archive gap draw only: an excluded host leaves the read pool and the published provenance, and a name that is not a host of the pool stops the run at start-up. Test stubs route by exact hostname.
• rpc-guard: ledger format 2 adds a settled line, the signed difference between the cost reserved before a call and the cost billed on the response, for a method metered on the results it returns (a received failed response costs nothing), and a course_reconciled line: reconcile can close the window of one course (--course-end, the hash of that course's unlocked line) and prints a per-method table. The first append of a new ledger writes its genesis head before its first line. The transport gains an opt-in bounded body read (one deadline for head and body, a byte cap); a closed list of exact hosts for the URL of the operator that carries a key, any other host being refused with a fixed reason, never the URL, before any request; and two keyless relays of the public randomness beacon named in the Dōjō anchor, one host and one closed path each, with an optional per-cycle attempt cap for keyless operators. The package index exposes only the relay labels. Six new test files come with these changes.
• Bell: the deployment check of the host accepts, in im...

v0.6.0

v0.6.0 - MONARK Bell served: first signed session record

This release follows the v0.5.0 pre-release of the same day. It carries the Bell host and the pieces that make its record verifiable by anyone.

What is served

• A dedicated host publishes, as plain files, one state, one signed timeline, one provenance record and one public key. Each timeline line is chained to the previous one and signed with Ed25519; the public key is committed in this repository as the trust root (the Bell publisher, its chain library, the verifier and the public keyring are exported to the public mirror with this release; the collector, the host unit and its runbook stay in the private tree until their provider names are purged).
• The first record is a session record for one tokenised equity, read on a public ledger over one full New York trading day (regular session included, split into sessions). It carries the fill count, the number of sessions and the quorum coverage of the read, and it names what is missing: the cash-market leg is off by design, so no gap and no close are served.
• A verifier script in this repository re-reads the served files against the committed key and runs twelve named checks (schema, chain, signature, key root, headers, no listing, cache rules, TLS, no private material, host configuration equal to the released bytes, probe untouched). Its result for the first publication is committed as a JSON file.

What changed in the code

• Bell publisher: bundle validation with a type-derived whitelist, whole-lot refusal before the earliest publication time, duplicate refusal, durable staged writes, chained and signed timeline, key generation on the host only, cross-signed rotation and revocation, fail-closed command line.
• Bell verifier: library and command line, root of trust by a supplied keyring, closed status set.
• Host configuration (private tree): a systemd unit with a credential-loaded key and no network, a Caddy file in a closed subset that the tests model, a runbook whose every step carries its command, its expected output and its rollback; the host root now redirects to the Bell page of the site.
• Site: Bell moves to "built" in the public register by the founder's decision of the day; the Bell pages state what is served and how to verify it. The home page hero is the MONARK core.

Reading rules (unchanged): facts witnessed, not investment advice; a signature attests origin, not truth; no endorsement of or by any venue, issuer or data source; never a probability of being right.

v0.5.0

v0.5.0 - pre-release (continuous updates over the next 24 hours)

This tag is a public checkpoint, not a finished product. The public tree will be updated in place during the next 24 hours as pieces reach the served state; a final release will follow once the Bell host is served.

What this pre-release contains

• Site: the whole site now uses one design (charter C), light and dark, self-hosted OFL fonts (Newsreader included), a header lock-up drawn as paths, and a common footer that states the reading rules. The home page hero is the MONARK core: one engine, AI layers and DeFi layers, every agent drawn from the fleet register with its register status; the cubes scene now opens /bell.
• Bell pages on the main site: /bell (what Bell measures, the four properties, the status table with named placeholders only), /bell/method (method facts pinned to the collector source), /bell/anchors (the anchor register served from the files that are attested: 17 anchors, 16 with an OpenTimestamps proof, 15 of them with a Bitcoin block record read from the proof file).
• Bell stays "upcoming" in the public register: no number is served before the file that carries it is served.
• Bell terms of use and privacy notice (/bell/terms, /bell/privacy), served from hashed data, with the contact mailbox linked.
• Ukemi and Narabi pages: unchanged content, same design. The Ukemi calibration course on one recorded lending episode is closed through its offline steps (book, oracle path, scores, hypothesis report), all keyless replays; its reconcile step follows once the operator dashboard shows the day.
• Sentinel and rpc-guard: durable write-ahead ledger (fsync, tail repair, rollover precedence), a served command-line reconcile and unlock, and a paid-leg quorum rule for bare reverts. These pieces are documented in the ADRs; the served binary stays "upcoming" until its deployment control passes.

What is not in this pre-release

• The Bell host (state.json, timeline.jsonl signed with Ed25519, public key) is not served yet.
• No session row (gap, volume ratio) is published yet; three collection bundles exist on the operator side (TSLAx, AAPLx, SPYx) and are published only once the Bell host is served and its verifier passes.
• Terms and privacy pages are not served yet; the disclaimer block on /bell is.

Reading rules (unchanged): facts witnessed, not investment advice; a signature attests origin, not truth; no endorsement of or by any venue, issuer or data source; never a probability of being right.

v0.4.0

MONARK v0.4.0 — Narabi runs: an adaptive quantile tracker on the attested USDe flow, published daily

This release adds the primitive and the sentinel that make Narabi a running sensor rather than a
committed table.

The primitive is a quantile tracker in the sense of Angelopoulos, Barber and Bates (2024): one
caller-carried state, a decaying step, no clamp. It is a pure function in packages/hikae with its own
tests; nothing in the gate calls it.

The sentinel is a daily job outside the tool surface. Each day it takes the finalized block window,
recomputes the AttestedFlow attestation from onchain bytes, derives the redemption velocity, steps the
tracker on the realized outcome, and appends one line to a hash-chained JSONL timeline. The timeline and
the current state are published at https://monarkgate.tech/narabi/ so anyone can replay them from the
same public RPC data. The first published window is 2026-09-17; that is day zero, and the tracker takes
its first step the day after.

What the tracker does and does not do, stated plainly. The tracker adapts; the gate does not yet. The
gate still answers from the committed split-conformal calibration of v0.3.0, for the single USDe
population, and every other population abstains under_calib. The bound printed each day is Theorem 1 of
the same paper, (B + eta_1) / (T times eta_T), with c = B = 1/24 and epsilon = 0.1; it stays above the
target 0.10 until T = 1789. No coverage is measured. The committed calibration was found non-stationary
across semesters on the recorded series, so the calibration is stated under the split-conformal bound
of Barber, Candes, Ramdas and Tibshirani (2023) with unit weights, and the wire says so. The gate would
switch to the tracker only when a pre-registered drift criterion fires and an ADR records it.

Also in this release: the sentinel's RPC quorum survives a dead public endpoint (it needed two responding ones
and had no fallback), the public texts and the fleet register now say four agents built and seven named,
and the skill text carries the same sentence as the README about what adaptive means here.

Apache 2.0. Five frozen typed contracts. Never a probability of being right.

v0.3.0

MONARK v0.3.0 — Narabi: AttestedFlow and the first committed calibration (USDe)

This release folds in what v0.2.0 carried in the repository and was never tagged: AttestedFlow, the
fifth frozen typed contract — an attestation over token flow (burns, mints and closing supply over a
declared block window) that any agent can recompute from onchain bytes — plus a velocity adapter and a
new gate class, stable-run-velocity-24h, that reads redemption velocity as a fraction of the opening
stock, which it recomputes from those raw numbers.

On top of that, it commits the first measured calibration of that class, for a single population:
USDe (Ethena), under the key
narabi:persistence-v2@eip155:1/erc20:0x4c9edd5852cd905f086c759e8383e09bff1e68b3. It is measured on calm
onchain redemption-flow windows with exchangeability declared as a modelling assumption. Every other
population abstains under_calib: the committed region is locked to this one key, and no family label
routes around it.

A non-degeneracy guard ships with it: a zero-width interval region abstains under_calib and never commits,
so a degenerate all-zero calibration cannot pass as a committed region.

The October 2025 USDe episode is held out of sample and reported only as a witness observation, on bare
dates — not a statement of what the gate emits in real time. One caveat, stated plainly: the first-day
crossing of the committed q99 depends on the pre-registered stress exclusion; only the peak day is robust
to both threshold sets.

An earlier candidate, msUSD, was measured and then refused: its calm regime was degenerate — a single
redemption day, a zero-width region — so the class kept abstaining. We publish the method, not a trophy.

The contract, the adapter and the calibration are in the repository. The public endpoint has not been
redeployed, so it still serves the two original classes. Next: adaptive conformal inference for drift.

Apache 2.0. Five frozen typed contracts. Never a probability of being right.

v0.1.0

MONARK v0.1.0

MONARK returns a coverage-controlled decision over a region you can audit — commit,
defer, or abstain — never a probability of being right. This release tags the current
public state of the mirror.

In this release

• Four MCP tools: attest, gate, cascade, calibrate.
• Typed, frozen interface contracts with closed schemas, held to English-only and a
  vocabulary gate in CI.
• The coverage gate: a conformal region plus a caller-carried budget, fail-closed to
  abstain when it cannot evaluate.
• The published integration skill and the storefront.

Honesty by construction
The gate emits a decision over an auditable region, not a score, and there is no confidence field anywhere in the interface. Frozen contracts do not change without an ADR.

Licensed Apache-2.0. The token contract address is pinned in the README (address only —
no price, no buy call).