Review an answer

Tattva is good. It's not infallible. A short discipline of reviewing every important answer makes it a tool you can stake decisions on.

This page gives you a checklist.

The 60-second review

For any answer that's going to inform a decision, spend a minute on this:

1. Read the headline. Does it answer the question you actually asked?
2. Skim the evidence. Do the numbers in the body match the headline?
3. Read the assumptions. Anything in there you'd dispute?
4. Spot-check one citation. Click into a row or query. Does it look right?
5. Look for a clarification request. If one appeared, did you answer it well? An answer built on a half-understood question is suspect.

The deep review

For high-stakes decisions, also do:

Check the tool trail

Expand the Execute phase. Every tool run is listed in order. For each:

• Does the tool's input make sense?
• Does its output match what you'd expect?
• Were any rows filtered out you wouldn't have filtered?

Check the metric definition

Click any metric in the evidence. The ontology entry opens. Look at:

• Definition — is this the formula you'd use?
• Last changed — has it been updated recently in a way you weren't aware of?
• Sources — which files feed this metric?

Check for conflicts

On the project's Ontology → Conflicts tab, look for any unresolved disagreements. An answer built on conflicted definitions is fragile.

Compare against a baseline

Re-run the question with a different framing, or compare against the same question a month ago. Big swings without an obvious reason deserve a closer look.

Challenging the answer

You can push back directly in the composer:

• "Why do you think that?" — the platform restates the reasoning chain.
• "Show me the supporting rows." — opens the underlying data.
• "What if [assumption] were wrong?" — re-runs with the assumption flipped.
• "What's the second-most-likely explanation?" — asks for the runner-up hypothesis.

These work like conversational follow-ups; the platform keeps the prior context.

When to escalate to High thinking depth

If you're suspicious of an answer, re-run with High depth. It costs more time but catches issues like:

• Edge cases in segmentation.
• Confounded variables in a comparison.
• Implicit assumptions that should be called out.
• Inconsistent definitions between two cited sources.

When to escalate to a specialist

If a Medium-depth answer to a "why" question is too vague, explicitly request a specialist:

• "Run RCA on this." for root-cause.
• "Run an attribution decomposition." for attribution.
• "Run a scenario where X changes." for forecast / scenario.

Specialists go deeper than the default flow.

Logging the review

If the answer holds up and is going to drive a real decision, Save as decision. This:

• Locks in the answer + citations against the source versions at this moment.
• Lets you record the actual decision made.
• Feeds your Decision Sign.
• Makes the decision searchable later.

This is how a defensible decision trail gets built — one logged answer at a time.