aziel-runtime

Calibrate a memory

memory_calibrate

Calibrate an observed memory using a 3-of-4 triad and Bayesian posterior, then write a LEARN stamp. Use when evidence should update a memory's likelihood, not for ranked search or explanation.

Instructions

Calibrate one memory with the deterministic 3-of-4 triad plus Bayesian posterior (AKM-TRIAD-1.0). Writes a LEARN stamp — not a ranked search and not an explain view. Use this when an observed memory should receive a posterior after evidence, not a ranked search. Do not use it for observing a new fact, resolving an outcome, or explaining a stored node; use memory_observe, memory_resolve, or memory_get instead. Write: forward-only RoseClock LEARN stamp. Posterior ≠ truth. authorizes_action=false. No automatic MODEL_UPDATE. subject or memory_id recommended. use_case labels calibration; it is not a permission. Mutation requires confirm=true (runtime gate) or dry_run=true (preview only, no write). confirm and dry_run stay optional on inputSchema.required. Returns triad_score, omitted leg, posterior, effective N, and Brier notes.

Input Schema

TableJSON Schema

Name	Required	Description
`fact`	No	Fact text clipped to 160 characters. Required on observe. Hash-only cards refuse AKM-NO-FACT.
`confirm`	No	Documented confirmation flag. Optional in inputSchema.required (connector refresh must not break). tools/call still refuses MCP-CONFIRM-REQUIRED when confirm is missing or false unless dry_run=true (preview, no write).
`dry_run`	No	Optional preview flag. When true, return a would-mutate preview and do not write. Alternative to confirm=true. Does not mutate.
`subject`	No	Optional subject key clipped to 80 characters. Used to find or create memory_id.
`use_case`	No	Optional use-case label for calibration / adaptive recall ranking. Not a truth claim.
`memory_id`	No	Optional existing memory id. Alternative to subject for resolve/calibrate/get.

Output Schema

TableJSON Schema

Name	Required	Description
`code`	No	FragGate or fabric code when present: FG-OK, FG-HALLUC-TOOL, FG-STUB, FG-LOCAL-ONLY, FG-UNKNOWN-OP, FG-GATE-REFUSE, FG-LAMB-REFUSE, or a module refuse such as MESH-* / AKM-*.
`door`	No	Door name. The public door is fraggate.
`ran_in`	No	Execution locale (for example aziel-runtime) when present.
`result`	No	FragGate body: ok, code, door, slug, op, engine_digest, ran_in, provenance, refusal, limitations, receipt, plus the engine result. Unknown names refuse FG-HALLUC-TOOL; stubs refuse FG-STUB.
`status`	No	HTTP-like status when present on wrappers (200 ok; 400+ error / refuse).
`display`	No	Human-facing envelope. Show title and summary, then take the next input.
`receipt`	No	Optional receipt, ledger tip, or TemporalLock/ForgeReceipts exit when the door stamped one.
`refusal`	No	Explicit refuse object, code, or message when the door or engine refused.
`engine_op`	No	Resolved engine op when present (often inside result).
`ledger_tip`	No	Ask/refuse ledger tip when the door stamped one.
`provenance`	No	Provenance / input packet when the pipeline attached one.
`session_id`	No	Raw session id when session plumbing was used. Hidden unless the user asked for the chain.
`engine_slug`	No	Resolved engine slug when present (often inside result).
`limitations`	No	Capability limitations or Remain-OFF notes when present.
`engine_digest`	No	64-hex engine_digest when a true in-process engine ran (often inside result).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv2.0.2Sep 18, 2026

changedInput schema / description

Previous value: -"subject or memory_id recommended. Extra keys are accepted."New value: +"subject or memory_id recommended. Extra keys are accepted. Mutation requires confirm=true or dry_run=true."

addedInput schema / properties / confirm

Added value: +{
+  "description": "Documented confirmation flag. Optional in inputSchema.required (connector refresh must not break). tools/call still refuses MCP-CONFIRM-REQUIRED when confirm is missing or false unless dry_run=true (preview, no write).",
+  "type": "boolean"
+}

addedInput schema / properties / dry_run

Added value: +{
+  "description": "Optional preview flag. When true, return a would-mutate preview and do not write. Alternative to confirm=true. Does not mutate.",
+  "type": "boolean"
+}

Addedv1.6.2Sep 12, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only provide basic hints; the description adds substantial behavioral disclosure: it writes a forward-only RoseClock LEARN stamp, states 'Posterior ≠ truth', 'authorizes_action=false', 'No automatic MODEL_UPDATE', and clarifies the confirm/dry_run mutation gate. These are meaningful traits beyond the schema and annotations, with no contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, and every sentence carries information. However, some redundancy exists: 'subject or memory_id recommended' and 'Mutation requires confirm=true or dry_run=true' appear in both the description and the input schema, which adds slight repetition in an otherwise dense definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with six optional parameters, a mutation gate, exclusions, and an output schema, the description covers usage, alternatives, behavioral caveats, parameter interpretation, and return fields ('triad_score, omitted leg, posterior, effective N, and Brier notes'). An agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds valuable nuance: 'subject or memory_id recommended', 'use_case labels calibration; it is not a permission', and the subtle 'confirm and dry_run stay optional on inputSchema.required' runtime distinction. This is helpful above the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Calibrate one memory'), names the exact algorithm (3-of-4 triad plus Bayesian posterior, AKM-TRIAD-1.0), and distinguishes itself from ranked search and explain view. It also names sibling tools it is not, so an agent can differentiate without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use it ('when an observed memory should receive a posterior after evidence') and when not to ('Do not use it for observing a new fact, resolving an outcome, or explaining a stored node'), with direct alternatives (memory_observe, memory_resolve, memory_get). Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.