Skip to main content
Inspect the result’s evidence and route-specific diagnostics to assess support and identify missing information.

​
Read the response in this order

Read the fields documented for the selected route. Consume its prediction or policy result and use the explanation fields to inspect support. For the first learned result, the response-reading boundary is:
Consume a supported transition result
The tutorial saves the actual responses before and after learning for inspection.

​
What a trace exposes

Public traces expose selected parts of internal execution and learning. Depending on the route, they can identify participating components or the serving model and report readiness, admitted sample counts, model versions, supporting evidence, and outcome attribution. Preserve the fields actually returned and interpret them through their documented contracts. A named score describes the quantity defined by its contract. Model identities and training diagnostics provide more specific evidence about the learner used. Source and coalition weights describe their contribution to selection; they do not enumerate the parameters inside a neural model. These diagnostics describe learned state that includes neural computation and trained parameters. They do not specify its complete neural parameter state, intermediate representations, or sequence of internal training updates. The Preview article describes native model training and the learner versions and decision provenance exposed for inspection. The Discovery article distinguishes its observable API formalization from the private ranking, utility-estimation, and commit algorithms. Use traces to audit evidence, attribution, and changes in later behavior. Agreement on recorded outputs and diagnostics establishes agreement on those observations; it does not by itself establish identical representations, parameters, update rules, or responses to further learning. See Mechanisms for the learned structure, and Verify adaptation for checking the effect of admitted feedback.

​
Inspect a recorded query result

This excerpt comes from a separate recorded Domain query with 15 observations in the structured transition learner. The returned field names and values are preserved; other fields have been omitted.
Recorded Domain query response
status: predicted identifies a returned prediction, and path_values contains its target value. The prediction reports eight supporting records through support_count and evidence_memory_ids. The learner has 15 observations in total, so the prediction’s support count has a different scope from the learner’s sample count. Keep decision_id with the result to request a sealed-decision explanation. state_version identifies the broader state associated with this query; model_version belongs to the transition predictor. Separate evaluations have used acquired state to complete unseen multi-step tasks with learner updates stopped. Combining retained task structure improved completion compared with the same acquired state and evaluation tasks with that composition disabled. These comparisons measure the contribution of the state used by the decision; the trace connects each returned result to its evidence and learner version. See the behavioral report for the acquisition and frozen-evaluation protocols.

​
Workflow

run the goal loop → request explanation → inspect returned fields → add or correct evidence → run again The optional explanation response exposes contract-defined evidence and diagnostics for the result.

​
Gateways

​
Inspect recorded evidence

Use authored observation hypotheses to inspect measurements in retained records. Supply supporting and falsifying conditions, then select the source event through metadata_filter. Keep the event identity in the query and its measurements in the retained event. Inspect decision_context.memory_id to identify the record used as context. Inspect counterevidence on each hypothesis, including candidates that were not selected. An empty top-level counterevidence_memories list does not establish that every candidate lacks counterevidence. Resolve evidence IDs through the application’s source ledger. Interpret scores through the returned score_contract. Inspect falsifying evidence before treating an unmet supporting condition as a request for another measurement. Keep retrieval and selection distinct. A retrieved record does not establish support for a hypothesis. Display abstention as Not established from the recorded evidence, preserving the returned reason and unmet conditions.

​
Sealed-decision audit

Save the complete Domain query response, including decision_id, state_identity, state_version, response_hash, selection, and evidence IDs. To inspect that recorded decision, pass its decision_id to the explanation route:
Check sealed: true and compare the returned decision ID, state identity, state version, response hash, selection, and evidence with the saved response. Historical replay preserves the decision after subsequent writes. Reissuing the original question creates a fresh query against the current state. Keep the route-specific fields in the sealed response with the result they explain. Treat explanatory associations as diagnostic unless the application explicitly supplies them to another request.

​
Field meanings and advanced interpretation

Use only the fields relevant to the audit question. Depending on the route and response contract, these can include:
Interpret each field according to its route’s documented meaning.

​
Read-only transition inspection

Call the applicable Domain query and /explain. Include all query fields and grouping fields that the Domain requires. Set update_memory_state: false and allow_exploration: false for frozen Domain inspection:
Keep the complete response for each read-only call, including unsupported results and evidence diagnostics. Review boundary inputs and contradictory evidence. Inspect these fields when the selected route returns them:
  • transition_prediction;
  • evidence memory IDs;
  • learning_state;
  • the selection or abstention reason;
  • supporting evidence IDs and counterevidence IDs;
  • supporting_memories;
  • missing_evidence;
  • predicted_observations;
  • core_support;
  • Domain, schema, model, and subsystem versions.
After the last intended write, compare consecutive frozen reads. Use state_identity.hash_scope to identify the comparison boundary. For persisted_domain_semantic_state, compare the complete state_identity object, state_version, and applicable learner versions across frozen reads. Inspect core_support.runtime.read_semantics and core_support.runtime.memory_state_mutated alongside that identity. The persisted semantic identity stays fixed during frozen inspection. Fresh decision snapshots, diagnostic counters, and response_hash are separate from this identity. Use the Domain identity for this check; generic State inspection uses a different diagnostic contract.
Interpret confidence as the support signal defined by the route. Examine it alongside evidence IDs, group values, distance, disagreement, missing evidence, and the selection or abstention reason.
Configure candidate hypotheses separately when the application needs to compare mechanisms. A Domain with no configured candidates can return an empty hypotheses list.Use candidates that have equal status and describe the same relation. Each candidate must predict a different observable consequence. A candidate must not contain the preferred answer.Before the application uses hypotheses:
  1. Send ordinary events that distinguish the candidates.
  2. Call /explain without feedback.
  3. Confirm that supporting evidence or counterevidence changes between candidates.
  4. If the evidence does not change, identify the contract that updates hypotheses.
  5. Treat transition output and hypothesis output as separate API contracts.
See Design Domains for transition learning for Domain configuration and response checks.
In this contract, conflicts reports associations that remain active together in superposition.Preserve the conflicts field name and document this meaning where it is displayed. Interpret reasoning_edges, ranked_hypotheses, supporting_memories, diagnostics, and related fields through their route-specific contracts.
Link predictions or selections to the actions executed and the transitions observed afterward. This record lets the application inspect whether feedback changed a scoped policy or whether a learned action-effect mapping was reused.Use the explanation’s evidence IDs to connect each result to the records that supported it.
Use the route’s learned result together with its admission and state diagnostics when evaluating adaptation.For a feedback workflow, inspect policy_scores alongside the explanation fields. Domain transition prediction returns transition_prediction; the interval-policy workflow under /adapt/* returns prediction.<output_key>. Consume the result documented for the selected route.Preserve the explanation with the corresponding result, executed action, and measured outcome when comparing behavior across updates.