Commit / defer / abstain over a conformal coverage region - not a probability of being right.
Scored across 4 tools
Each tool has a broadly distinct role: attest projects a witness, calibrate computes a conformal quantile, cascade estimates liquidable amounts, and gate emits a coverage-gated decision. However, the gate description absorbs calibrate's entire BYO split-conformal logic, so the boundary between 'calibrate' and 'gate' is blurry and an agent could plausibly route a calibration request to either.
All four names are single lowercase words (attest, calibrate, cascade, gate), giving a consistent, readable style. They mix verbs (attest, calibrate) and nouns (cascade, gate), a minor inconsistency, but there is no chaotic mixing of casing or conventions.
Four tools is on the thin side for a server whose descriptions imply a huge surface (attestation, conformal calibration, cascade clearing, a multi-class gated policy engine). It is not wildly mismatched, but several conceptually separate operations appear folded into the monolithic gate tool.
The set nominally covers the apparent lifecycle (calibrate → cascade → gate → attest), but key operations are explicitly delegated elsewhere (verification must be done offline with the Shōgen verifier) and the gate overlaps/folds in functionality that isn't exposed as a discrete tool. Notable gaps and dead ends exist for an agent trying to complete a full workflow.
projection of a committed Shōgen-verified witness (Binance BTCUSDT, self-notarized); the verifier is NOT executed at call time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| label | Yes | Honesty label carried OUTSIDE the frozen price (K-1): the witness is demonstrative, not probative. |
| price | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does add one genuinely useful behavioral fact – that the verifier is not run at call time – implying a deterministic read of a committed artifact, plus 'self-notarized' implying authenticity. It stops short of stating read-only semantics, failure modes, or what happens when no witness is committed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single tightly-packed sentence, which is appropriately sized, but the front-loaded clause is the least parseable part and burdens the reader with jargon before delivering the actionable detail (Binance BTCUSDT, no verifier execution). Efficient in length, weak in readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and there are no parameters to document. The remaining gap is that a zero-input, cryptically named tool among equally cryptic siblings gives the agent almost no basis for deciding whether to call it – the fundamental purpose/usage context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. Schema coverage is moot at 0 params, and the description introduces no parameter confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description leans on dense, undefined jargon ('projection of a committed Shōgen-verified witness') and never states plainly what the tool returns or accomplishes. 'Binance BTCUSDT, self-notarized' narrows the domain but does not resolve the core verb+resource. It offers no differentiation from the cryptic siblings calibrate, cascade, and gate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no comparison against the sibling tools. The clause 'the verifier is NOT executed at call time' hints that this is a read of already-committed data rather than a trigger for verification, but that is inference, not instruction. The agent is left to guess the scenario in which attest is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
split-conformal quantile at miscoverage α over caller-supplied nonconformity scores. MONARK does not see, store, or verify the caller's data or model, and does not validate that the supplied numbers are nonconformity scores of any model. Marginal 1−α coverage holds ONLY for future points exchangeable with the supplied scores; non-exchangeable data (e.g. distribution-shifted or time-ordered) voids it. Never a probability of being right.
| Name | Required | Description | Default |
|---|---|---|---|
| nMin | Yes | Minimum calibration count (>= 1); n < nMin fails closed to under_calib. | |
| alpha | Yes | Target miscoverage in the open interval (0,1). | |
| scores | Yes | Caller-supplied nonconformity scores (BYO: the caller owns the score function; MONARK stays agnostic). |
| Name | Required | Description |
|---|---|---|
| n | Yes | The number of supplied scores (echoed). |
| qhat | Yes | The conformal quantile q̂, or null when the calibration is insufficient (fail-closed). |
| alpha | Yes | The target miscoverage (echoed). |
| label | Yes | Honesty label (K-1): the marginal coverage holds only under exchangeability with the supplied scores. |
| method | Yes | The conformal method — always split. |
| reason | Yes | under_calib when q̂ is null, else null on success. |
| scores_sha256 | Yes | scoresSha256(scores) in the caller's order: the audit tie to verdict.scores_sha256 (C2). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses non-obvious traits: MONARK never sees/stores/verifies the caller's data, does not validate inputs as true nonconformity scores, and the coverage guarantee is conditional on exchangeability. It stops short of describing failure behavior or performance, but the fail-closed nMin path is covered in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, front-loaded with the operation before the caveats, and every clause carries real information for a statistically sensitive tool. It is compact for the amount of qualification it conveys, though the sentence density is high.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description covers the trust model, the statistical guarantee, and its limits. Remaining gaps (exact response shape, failure surface) are largely delegated to the schema, but for a tool with zero annotations the operational side could be stated more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so alpha, nMin, and scores are already documented with units, bounds, and fail-closed behavior. The description adds framing ('BYO', MONARK agnostic) but no new per-parameter syntax or constraints, matching the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a precise operation ('split-conformal quantile at miscoverage α over caller-supplied nonconformity scores'), so an agent immediately knows this is a calibration/quantile computation rather than an attestation or gating step. It does not explicitly differentiate itself from the siblings (attest, cascade, gate), so it lands just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use/when-not or routing to alternatives; usage must be inferred from the statistical framing. The exchangeability caveat ('holds ONLY for future points exchangeable...') is a validity condition rather than invocation guidance, but it does tell the agent when the result is meaningful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimated liquidable amount from the real UKEMI cascade primitives (imported, never re-implemented): an Eisenberg-Noe clearing of the interbank system (L, e) with alpha=beta=1 yields the largest clearing vector L*; each node is then read as a leveraged position — collateral is its cleared balance-sheet value (external assets plus interbank receipts under L*), debt is its nominal obligations, liquidation threshold K=1 — and liquidableAmount sums the debts of the nodes whose cleared value, once shocked by the caller-carried 24h fraction, no longer covers their obligations. Shocking the whole cleared value is a v0 simplification; no source supports shocking interbank receivables. yhat is that liquidable amount: a monetary quantity in the reference asset, a single point that HIKAE conformalizes downstream — no guarantee, no score. Downstream, no cascade calibration is committed; the gate abstains (under_calib) on this class. This cascade tool is v0, replaced at U-5.
| Name | Required | Description | Default |
|---|---|---|---|
| L | Yes | Nominal interbank liabilities matrix L[i][j] = what node i owes node j. Square, entries >= 0, zero diagonal. | |
| e | Yes | External assets (liquidation value) per node at the clearing date. One value per node. | |
| shock | Yes | 24h collateral price shock fraction in [0,1] — a declared fixture parameter, not a dynamics model. | |
| producedAt | Yes | Caller-carried RFC3339 instant, injected for hash stability (D4); the tool reads no clock. |
| Name | Required | Description |
|---|---|---|
| yhat | Yes | |
| task_class | Yes | |
| produced_at | Yes | |
| predictor_id | Yes | |
| schema_version | Yes | |
| features_digest | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden and does so richly. It discloses the algorithm, the simplification ('Shocking the whole cleared value is a v0 simplification'), the constraint ('no source supports shocking interbank receivables'), the output semantics ('no guarantee, no score'), and the downstream treatment ('no cascade calibration is committed'). This gives an agent a complete behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and long, but every sentence carries substantive information about algorithm, assumptions, downstream behavior, or version status. It is front-loaded with the primary purpose. It could be better structured with clearer separation of algorithm vs. caveats, but it does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematically complex tool with an output schema and no annotations, the description covers the algorithm, input interpretations, simplifications, output nature (single point, monetary, no score), downstream calibration abstention, and versioning/replacement. An agent can understand what the tool computes, what its limitations are, and how its output relates to the broader pipeline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining how L and e feed the clearing computation, how shock applies to the cleared value, and that producedAt is 'caller-carried' for 'hash stability (D4)' and that the tool 'reads no clock.' This adds algorithmic and protocol-level meaning to each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-plus-resource statement: 'Estimated liquidable amount from the real UKEMI cascade primitives.' It then precisely describes the mechanism (Eisenberg-Noe clearing, liquidation threshold K=1) and the exact output (yhat, a monetary quantity). This is clearly distinguished from general-purpose tools and from siblings by its mathematical and pipeline role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context and caveats: 'This cascade tool is v0, replaced at U-5' and 'the gate abstains (under_calib) on this class.' However, it never explicitly states when to use this tool versus alternatives such as attest, calibrate, or gate, nor does it name a preferred alternative. Usage is implied through the pipeline explanation rather than stated as a decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Coverage-gated decision from the real HIKAE L3 policy (commit/defer/abstain) over a caller-carried authorization budget B_t. Dispatches on task_class. The class 'btc-dir-15m' is retired and answers a named refusal. For 'cascade-liquidable-24h' no cascade calibration is committed; the gate abstains (under_calib) on this class. For 'stable-run-velocity-24h' (Narabi: a redemption-flow velocity forecast) the gate holds a committed stable-run velocity calibration for the USDe synthetic-dollar-whitelisted-redeem population (key narabi:persistence-v2@eip155:1/erc20:0x4c9edd5852cd905f086c759e8383e09bff1e68b3) over calm-window redemption flow; coverage is stated under the split-conformal bound of Barber, Candes, Ramdas and Tibshirani 2023 (Thm 2, unit weights): at least 1 − α minus the average total-variation gap between calibration windows and the next one; that gap is not estimated here and the calibration is measured non-stationary across half-years, so 1 − α is the coverage only if that gap is zero (exchangeability), which is not assumed here; no coverage is measured; on that key it requires alpha = 0.1, nMin = 50; for any other population, no stable-run velocity calibration is committed for this population; the gate abstains (under_calib). For 'liquidation-eligible-coverage' (Ukemi: a per-account liquidable-amount class, class A only) the served region is a conformal upper bound on the liquidable amount for the calibrated class; the lower edge is 0 by construction, not a calibrated bound; abstains (under_calib) outside it; this class requires alpha = 0.01, nMin = 100; calibrated on one recorded episode; no coverage is claimed on any other event; the H-3 exchangeability check is a report, a YES licenses nothing more; the bound holds only if yhat was produced by the frozen close-factor rule on a mono-collateral WETH account at the first crossing, which the gate does not check. The 32 kata classes {btc,eth,bnb,sol}-{dir,range,mae-down,mae-up}-{1h,4h} are served from their policy tables, which hold no committed calibration row: every well-formed kata call abstains with no region (under_calib, or non_evaluable on a dir lean of exactly 0), and no kata class has an attestation subject. A kata call carries a predictor_id of the form kata:<kataId>@<venue>/<SYMBOL>/<h> (no bucket, the class horizon), a features_digest, alpha = 0.45, nMin = 6 on dir classes and alpha = 0.01, nMin = 299 on the others, tau at most 1 on dir classes, and a produced_at on the class horizon grid, received at most 300 s after it; the full request rules are in section 9 of the contract 1.1.0 specification. When the caller instead supplies a calibration (its own nonconformity scores plus a mode: interval ⇒ region [yhat - q̂, yhat + q̂], or set ⇒ a conformal set over caller candidates), the gate conformalizes against THOSE caller-supplied scores (BYO): split-conformal quantile at miscoverage α over caller-supplied nonconformity scores. MONARK does not see, store, or verify the caller's data or model, and does not validate that the supplied numbers are nonconformity scores of any model. Marginal 1−α coverage holds ONLY for future points exchangeable with the supplied scores; non-exchangeable data (e.g. distribution-shifted or time-ordered) voids it. Never a probability of being right. A caller-carried attested price must declare a subject consistent with the committed task class (exact committed-URL membership; BYO classes do not accept attested in P1); the attestation is carried by the caller and is not re-verified at call time (the verifier is not executed here); attest only projects the committed witness — verify a caller-carried attestation offline with the Shōgen verifier; no temporal binding in P1. No served class has a committed attestation subject (the retired 'btc-dir-15m' held the only one), so any attested is refused. The gate only emits a decision; it never calls the named tool.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | ||
| attested | No | ||
| prediction | Yes |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| allow | Yes | |
| action | Yes | |
| intent | Yes | |
| reason | Yes | |
| verdict | Yes | |
| request_sha256 | Yes | |
| schema_version | Yes | |
| remaining_budget | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose a lot: it never stores/verifies caller data, never re-verifies attestations, abstains under_calib, coverage voids under non-exchangeability, and never invokes the named tool. The self-caveating coverage language ('no coverage is measured', 'never a probability of being right') is unusually honest. Minor deduction for the sheer volume that makes the key behavioral guarantees hard to isolate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single unbroken wall of text mixing purpose, per-class policy, BYO rules, attestation rules, and statistical caveats. It is front-loaded on the core purpose, but sentences are long, redundant, and hard to navigate; the structure actively impedes extraction of the decision rules.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the very rich nested schema and an output schema (so return values need not be explained), the description is substantively complete: it covers class dispatch, refusal modes, BYO calibration, and attestation constraints. It is dense rather than missing content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema carries no computed description coverage, so the description must compensate, and it does add real meaning: fixed alpha/nMin per class (e.g. 0.1/50, 0.01/100), tau <= 1 on dir classes, predictor_id format, produced_at grid and 300s receipt bound. It does not explain remainingBudget/bFloor/clockOpen semantics, leaving some required params unclarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening states a specific verb+resource: a coverage-gated decision (commit/defer/abstain) over a caller-carried budget, dispatching on task_class. It also distinguishes itself from the sibling 'attest' ('only emits a decision; it never calls the named tool'). However, the purpose is buried under dense jargon and per-class policy detail, so an agent must work to extract the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives extensive conditional routing: which classes abstain (under_calib), which are retired, when BYO calibration activates, and that 'attest' handles offline attestation verification. What is missing is a crisp statement of when an agent should call gate versus calibrate or cascade; the guidance is embedded in class-by-class prose rather than framed as selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
calibrate3 fields changedOutput schema / properties / scores_sha256Added value: +{
+ "description": "scoresSha256(scores) in the caller's order: the audit tie to verdict.scores_sha256 (C2).",
+ "pattern": "^[0-9a-f]{64}$",
+ "type": "string"
+}Output schema / properties / set_digestRemoved value: -{
- "description": "calibDigest(scores): recalculable by reference; the audit tie to verdict.calib_digest (C2).",
- "pattern": "^[0-9a-f]{64}$",
- "type": "string"
-}Output schema / requiredPrevious value: -[
- "qhat",
- "n",
- "alpha",
- "method",
- "set_digest",
- "label",
- "reason"
-]New value: +[
+ "qhat",
+ "n",
+ "alpha",
+ "method",
+ "scores_sha256",
+ "label",
+ "reason"
+]gate20 fields changedOutput schema / properties / reason / enumPrevious value: -[
- "covered",
- "set_too_large",
- "interval_too_wide",
- "intent_not_in_region",
- "under_calib",
- "no_label_schema",
- "budget_exhausted",
- "clock_expired",
- "upstream_timeout",
- "attestation_absent",
- "attestation_refused",
- "binding_broken",
- "non_evaluable"
-]New value: +[
+ "covered",
+ "set_too_large",
+ "interval_too_wide",
+ "intent_not_in_region",
+ "under_calib",
+ "no_label_schema",
+ "budget_exhausted",
+ "clock_expired",
+ "upstream_timeout",
+ "attestation_absent",
+ "attestation_refused",
+ "binding_broken",
+ "non_evaluable",
+ "calib_silence",
+ "calib_vetoed",
+ "calib_retired",
+ "out_of_support",
+ "region_degenerate"
+]Output schema / properties / request_sha256Added value: +{
+ "pattern": "^[0-9a-f]{64}$",
+ "type": "string"
+}Output schema / properties / schema_version / constAdded value: +"1.1.0"Output schema / properties / schema_version / patternRemoved value: -"^\\d+\\.\\d+\\.\\d+$"Output schema / properties / schema_version / typeRemoved value: -"string"Output schema / properties / verdict / properties / calib_digestRemoved value: -{
- "pattern": "^[0-9a-f]{64}$",
- "type": "string"
-}Output schema / properties / verdict / properties / cell_keyAdded value: +{
+ "minLength": 1,
+ "pattern": "^[ -~]+$",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / verdict / properties / method / enumPrevious value: -[
- "split",
- "hac-cp"
-]New value: +[
+ "split",
+ "hac-cp",
+ "risk-control"
+]Output schema / properties / verdict / properties / policy_row_sha256Added value: +{
+ "pattern": "^[0-9a-f]{64}$",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / verdict / properties / policy_table_sha256Added value: +{
+ "pattern": "^[0-9a-f]{64}$",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / verdict / properties / qhat_unitAdded value: +{
+ "enum": [
+ "label",
+ "scale",
+ "score"
+ ]
+}Output schema / properties / verdict / properties / reason / enumPrevious value: -[
- "covered",
- "set_too_large",
- "interval_too_wide",
- "intent_not_in_region",
- "under_calib",
- "no_label_schema",
- "budget_exhausted",
- "clock_expired",
- "upstream_timeout",
- "attestation_absent",
- "attestation_refused",
- "binding_broken",
- "non_evaluable"
-]New value: +[
+ "covered",
+ "set_too_large",
+ "interval_too_wide",
+ "intent_not_in_region",
+ "under_calib",
+ "no_label_schema",
+ "budget_exhausted",
+ "clock_expired",
+ "upstream_timeout",
+ "attestation_absent",
+ "attestation_refused",
+ "binding_broken",
+ "non_evaluable",
+ "calib_silence",
+ "calib_vetoed",
+ "calib_retired",
+ "out_of_support",
+ "region_degenerate"
+]Output schema / properties / verdict / properties / region / oneOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "kind": {
- "const": "set"
- },
- "label_schema": {
- "minLength": 1,
- "pattern": "^[ -~]+$",
- "type": "string"
- },
- "labels": {
- "items": {
- "pattern": "^[ -~]+$",
- "type": "string"
- },
- "type": "array"
- }
- },
- "required": [
- "kind",
- "labels",
- "label_schema"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "hi": {
- "type": "number"
- },
- "kind": {
- "const": "interval"
- },
- "lo": {
- "type": "number"
- }
- },
- "required": [
- "kind",
- "lo",
- "hi"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "const": "set"
+ },
+ "label_schema": {
+ "minLength": 1,
+ "pattern": "^[ -~]+$",
+ "type": "string"
+ },
+ "labels": {
+ "items": {
+ "pattern": "^[ -~]+$",
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "kind",
+ "labels",
+ "label_schema"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "hi": {
+ "type": "number"
+ },
+ "kind": {
+ "const": "interval"
+ },
+ "lo": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "kind",
+ "lo",
+ "hi"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / verdict / properties / scaleAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / verdict / properties / schema_version / constAdded value: +"1.1.0"Output schema / properties / verdict / properties / schema_version / patternRemoved value: -"^\\d+\\.\\d+\\.\\d+$"Output schema / properties / verdict / properties / schema_version / typeRemoved value: -"string"Output schema / properties / verdict / properties / scores_sha256Added value: +{
+ "pattern": "^[0-9a-f]{64}$",
+ "type": "string"
+}Output schema / properties / verdict / requiredPrevious value: -[
- "schema_version",
- "task_class",
- "method",
- "alpha",
- "n_calib",
- "region",
- "qhat",
- "abstain",
- "reason",
- "residual",
- "calib_digest",
- "produced_at"
-]New value: +[
+ "schema_version",
+ "task_class",
+ "method",
+ "alpha",
+ "n_calib",
+ "region",
+ "qhat",
+ "abstain",
+ "reason",
+ "qhat_unit",
+ "scale",
+ "residual",
+ "scores_sha256",
+ "cell_key",
+ "policy_row_sha256",
+ "policy_table_sha256",
+ "produced_at"
+]Output schema / requiredPrevious value: -[
- "schema_version",
- "action",
- "allow",
- "tool",
- "intent",
- "verdict",
- "remaining_budget",
- "reason"
-]New value: +[
+ "schema_version",
+ "action",
+ "allow",
+ "tool",
+ "intent",
+ "verdict",
+ "remaining_budget",
+ "request_sha256",
+ "reason"
+]gate1 field changedInput schema / properties / attestedAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "attestor": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "identity": {
+ "minLength": 1,
+ "pattern": "^[ -~]+$",
+ "type": "string"
+ },
+ "key": {
+ "pattern": "^([0-9a-f]{2})+$",
+ "type": "string"
+ }
+ },
+ "required": [
+ "identity",
+ "key"
+ ],
+ "type": "object"
+ },
+ "minItems": 1,
+ "type": "array",
+ "uniqueItems": true
+ },
+ "observed_at": {
+ "additionalProperties": false,
+ "properties": {
+ "clock": {
+ "minLength": 1,
+ "pattern": "^[ -~]+$",
+ "type": "string"
+ },
+ "instant": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "clock",
+ "instant"
+ ],
+ "type": "object"
+ },
+ "octets_recalcules": {
+ "type": "boolean"
+ },
+ "residual": {
+ "items": {
+ "minLength": 1,
+ "pattern": "^[ -~]+$",
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array",
+ "uniqueItems": true
+ },
+ "schema_version": {
+ "pattern": "^\\d+\\.\\d+\\.\\d+$",
+ "type": "string"
+ },
+ "sens_emis_digest": {
+ "pattern": "^[0-9a-f]{64}$",
+ "type": "string"
+ },
+ "subject": {
+ "minLength": 1,
+ "pattern": "^[ -~]+$",
+ "type": "string"
+ },
+ "transport": {
+ "minLength": 1,
+ "pattern": "^[ -~]+$",
+ "type": "string"
+ },
+ "utterance": {
+ "additionalProperties": false,
+ "properties": {
+ "bytes": {
+ "pattern": "^([0-9a-f]{2})*$",
+ "type": "string"
+ },
+ "hash": {
+ "pattern": "^[0-9a-f]{64}$",
+ "type": "string"
+ }
+ },
+ "required": [
+ "hash"
+ ],
+ "type": "object"
+ },
+ "verifier_revision": {
+ "minLength": 1,
+ "pattern": "^[ -~]+$",
+ "type": "string"
+ }
+ },
+ "required": [
+ "schema_version",
+ "subject",
+ "attestor",
+ "residual",
+ "transport",
+ "utterance",
+ "observed_at",
+ "octets_recalcules",
+ "verifier_revision"
+ ],
+ "type": "object"
+}attestcalibratecascadegateCalibrated decisions for agents: choice, yes/no and score questions answered with probabilities.
Deterministic decision layer for autonomous agents: reproducible PROCEED/REVIEW/SKIP verdicts.
Deterministic eligibility scoring for AI agents: CLEAR/HOLD/FAIL verdicts, published weights.
Trust gate for AI agents: multi-model adversarial consensus, signed and verifiable verdicts.
Add one secure layer between your agents and this server.
