# Understand (/docs/govern/understand)

Understand is the first move of the Trust Loop. Once an agent is
[connected](/docs/govern/connect-your-agents), every run lands as a trace, and
AISquare extracts the reasoning behind it so you can see why the agent decided
what it did, not just what it returned. A transcript tells you what was said. The
reasoning graph tells you what the agent believed, what it leaned on, and how it
got from one to the other.

## Your agent's reasoning, as a graph [#your-agents-reasoning-as-a-graph]

This is one refund-agent run, laid out as the graph AISquare records: the
question it was asked, the context it fetched, the evidence and the one
assumption it leaned on, the policy it cleared, the claim it made, and the
decision it reached. Drag the canvas to pan, scroll to zoom, and follow the
solid line for the timeline and the dashed lines for what each step produced and
consumed.

The recorded run, step by step: user question ("Can I get a refund on order
\#4821?") to refund agent; the agent fetches context (get\_order); two pieces of
evidence (order #4821, $39, placed 6 days ago; the 30-day refund window) and one
assumption (customer tier resolved to standard, confidence 0.72) feed the
reasoning step (claude-opus 4.8); a policy check (refund-auto-approve) passes;
the agent makes its claim (the refund is within policy limits) and reaches a
decision (auto-approve), which is then queued for optional human review because
the tier was assumed rather than confirmed.

## A run is a graph, not a transcript [#a-run-is-a-graph-not-a-transcript]

Each run is recorded as a graph of steps. A step is one unit of work: an LLM
call, a tool call, a retrieval, a logic gate, a memory read. Every step carries
its model or tool, its latency, tokens, and cost, a status, and the policies it
triggered. This is the same anatomy you see in the dashboard.

<div className="liquid-glass my-6 p-5">
  <div className="grid grid-cols-1 gap-4 sm:grid-cols-2">
    <TraceStepCard type="tool" title="Look up order" subtitle="get_order . tool call" latency="0.21s" cost="$0.000" status="ok" policies="['#tool', 'pii: redacted']" />

    <TraceStepCard type="retrieval" title="Search refund policy" subtitle="kb.refunds . vector search" latency="0.34s" tokens="1,204" cost="$0.002" status="ok" policies="['#retrieval', 'k=6']" />

    <TraceStepCard type="llm" title="Assess refund eligibility" subtitle="claude-opus 4.8 . reasoning step" latency="0.82s" tokens="412" cost="$0.004" status="running" policies="['#inference', 'policy: risk-scoring']" />

    <TraceStepCard type="logic" title="Branch on customer tier" subtitle="tier == standard . gate" latency="0.01s" status="ok" />
  </div>
</div>

Reading a step left to right: a refund agent looked up the order, searched the
refund policy, reasoned over both, then branched on the customer tier. The third
card is mid-execution, which is how a live run reads while the LLM step is still
thinking. You can open any run as a flow diagram, as this graph, or as a
plain-English narrative; all three are the same recorded decision.

## A reasoning graph is not a knowledge graph [#a-reasoning-graph-is-not-a-knowledge-graph]

A knowledge graph stores what your organization knows: entities and the
relationships between them. It is a map of facts, and it changes slowly. A
reasoning graph records something a knowledge graph never holds: how an agent
thought on one specific run. Which claims it committed to, which evidence it
weighed, which assumptions it filled in, and how those connected to the
decision it reached.

The two are complements, not competitors. An agent may well consult a knowledge
graph as evidence, and that lookup appears as a step on the reasoning graph.
But when someone asks why the agent decided what it did, a map of what was
known cannot answer. Only the record of how it was used can, and that record is
what AISquare captures.

## Claims, evidence, and assumptions [#claims-evidence-and-assumptions]

Inside a reasoning step, AISquare structures the model's thinking into three
parts. This is the reasoning markup (RML) view, and it is the clearest answer to
"why did it decide that?"

* **Claims** are what the agent asserted, the conclusions it acted on.
* **Evidence** is what each claim rests on, every item carrying a confidence
  score so a weak input is visible rather than buried.
* **Assumptions** are the gaps the agent filled in for itself, the inferred
  facts that were not given to it directly. Surfacing them is the point: an
  assumption you can see is one you can challenge.

The inference chain then shows, step by ordered step, how the agent moved from
evidence and assumptions to its claims.

<div className="liquid-glass my-6 p-5">
  <RMLPanel
    extractionConfidence="0.86"
    claims="[
    'The refund is within policy limits.',
    'No manual review is required for this order.',
  ]"
    evidence="[
    { text: 'Order #4821 total $39, placed 6 days ago', confidence: 0.94 },
    { text: 'Refund window for standard tier is 30 days', confidence: 0.91 },
    { text: 'Customer tier resolved to standard', confidence: 0.72 },
  ]"
    inferenceChain="[
    'Order total $39 is under the $50 auto-approve ceiling.',
    'Placed 6 days ago, inside the 30-day standard window.',
    'No prior refund on this order, so no duplicate-refund risk.',
    'Therefore the refund is auto-approvable without review.',
  ]"
  />
</div>

The third piece of evidence here, that the customer tier resolved to standard,
carries a noticeably lower confidence than the rest. That is an assumption the
agent leaned on: tier was inferred, not confirmed. Seen on the graph, it is the
first thing a reviewer would probe, and it is exactly the kind of weak link the
[Fix](/docs/govern/fix) step exists to correct.

<Callout intent="note" title="Extraction confidence is its own signal">
  The bar at the top of the panel is the confidence of the extraction itself, how
  sure AISquare is that it captured the agent's reasoning faithfully. A low
  extraction confidence is a prompt to read the raw trace, not to trust the
  structured view blindly.
</Callout>

## Why this matters [#why-this-matters]

Structured reasoning is what turns a black-box run into a decision you can defend
and improve.

* **Audit.** When someone asks why an agent did what it did, you point at the
  claims, the evidence, and the rule it triggered, not a wall of transcript.
* **Debugging.** A wrong answer usually traces to one weak claim or one bad
  assumption. The graph shows you which, so you fix the cause, not the symptom.
* **Trust.** Reasoning you can inspect is reasoning a regulator, an auditor, or a
  customer can be shown.

Understanding a decision is the input to acting on it. From here the loop
continues: [Prevent](/docs/govern/prevent) stops a bad action before it runs,
[Fix](/docs/govern/fix) corrects a decision that already happened, and
[Remember](/docs/govern/remember) carries the result forward so the next run
starts ahead.

## Next steps [#next-steps]

<Cards>
  <Card title="Prevent" href="/docs/govern/prevent" description="Enforce policy at the decision point, before an action runs." />

  <Card title="Fix" href="/docs/govern/fix" description="Correct a decision in context and keep the correction on the record." />

  <Card title="Core Concepts" href="/docs/getting-started/core-concepts" description="The entities behind the reasoning graph and the API." />

  <Card title="Connect your agents" href="/docs/govern/connect-your-agents" description="Bring an agent from any framework. It keeps running as-is." />
</Cards>