# Reasoning Workflow — Explainer and Worked Example

This is a human-facing companion to `system-prompt.md`. It is **not** meant to be sent to the model — it exists so you (or anyone maintaining this system) can see what the FACTS → ACTION discipline is supposed to produce, and can sanity-check the model's behaviour against it.

## The chain

```
FACTS → APPLICABLE LAW/STANDARD → INTERPRETATION → ANALYSIS
      → EVIDENCE → RISK → PROFESSIONAL JUDGMENT → CONCLUSION → ACTION
```

## Worked example

**User question:** "We capitalised ₹40 lakh of software development cost this year. Is that okay?"

| Step | What the agent should do |
|---|---|
| **Facts** | Missing: entity's accounting framework (Ind AS vs AS), whether this is internally generated or purchased software, what stage of development the ₹40L relates to (research vs development phase), whether recognition criteria evidence exists (technical feasibility, intent, ability to use/sell, resources, reliable cost measurement). Agent should ask 2–3 of these, not all. |
| **Applicable law/standard** | Ind AS 38 (or AS 26 if not Ind AS) intangible assets — internally generated software rules; research phase must be expensed, development phase may be capitalised only if criteria met. |
| **Interpretation** | Where the entity's stage is genuinely borderline (POC vs. production-ready), flag that this is a judgment call, not mechanical. |
| **Analysis** | Apply the six Ind AS 38 development-phase criteria to the stated facts. |
| **Evidence** | What would support capitalisation: technical feasibility study/sign-off, board/management intent documentation, cost records segregating research vs. development spend, resource availability evidence. |
| **Risk** | Overstatement of intangible assets, understated current-period expense, potential audit qualification if evidence is absent, deferred tax mismatch if tax treatment differs. |
| **Professional judgment** | State whether the facts as given support capitalisation, partial capitalisation, or full expensing — with the "safe / defensible / high-risk" framing if genuinely contestable. |
| **Conclusion** | Direct answer: capitalisable / not capitalisable / partially, and why. |
| **Action** | What to actually do: obtain the supporting documentation named above, consider disclosure, consider whether restatement of an in-year entry is needed, note audit evidence to be requested if this is an audit context. |

## Compression for routine questions

For a quick/routine question, the same chain still runs internally but the visible answer compresses to: **conclusion first, then only the reasoning needed to trust it.** Example:

> **Q:** "Is interest on late TDS payment allowed as a business expense?"
> **A:** No — interest for late deposit of TDS is disallowed as a deduction under the Income-tax Act (it is treated as a penal/statutory interest, not a business expense), unlike ordinary interest on borrowings. *(FREQUENTLY CHANGING flag: confirm current-year treatment/section reference before relying on this for a filing.)*

## Why this matters for a website deployment

On a website, most users will not ask for a full FACTS→ACTION treatment explicitly — they'll ask a short question. The discipline still has to run *underneath* the short answer so the short answer is actually correct, and so the agent knows when a short answer isn't safe to give (missing facts, contestable interpretation, frequently-changing figure with no injected knowledge context). The compression rule in §8 of the core prompt exists precisely so the agent doesn't either (a) dump a textbook essay on a simple question, or (b) give a falsely confident one-liner on a genuinely fact-dependent question.
