What a Go/No-Go memo looks like

A finance lead has budget approved for "AI on loan documents". The vendor demo went well. The board wants a date. Nobody has yet opened a hundred real bank statements to see what state they are in.

That gap is where trouble starts. The decision to build gets made on a demo. The facts arrive during the build, when changing course is expensive.

We usually start with a short, paid architecture sprint of about two weeks. It ends in a written Go/No-Go memo. The memo is the main deliverable. It says whether to build, what to build first and what could stop it. You make the decision with it in hand.

Why write it down

A call ends with everyone agreeing. A week later, everyone remembers a different agreement. A written memo fixes the decision in one place. It can go to a CFO, a head of risk or an engineering lead who was not on the call. Each of them should be able to read it in one sitting and know what is proposed and why.

Writing also forces precision. "The data looks fine" does not survive being written down. "Statements from four banks parse cleanly; scanned statements do not" does.

What a good memo contains

A useful memo should cover the same ground.

1. Recommendation. Go, No-Go, or Go with conditions. It goes on the first line.
2. The workflow. The one job the system will do, who does it today, and where it starts and ends.
3. What to build first. One thin slice that can reach production, with an explicit out-of-scope list beside it.
4. Data readiness. What data exists, what state it is in, who owns it and whether we can get access.
5. Architecture. The simplest shape that can do the job. Where a language model earns its place, and where plain code or rules are enough.
6. Controls. Where a person approves, what the system may never do alone, and how it fails safely.
7. Evaluation plan. How quality will be measured, on what test set, against what baseline, and who signs off.
8. Risks. The few things that could stop the project, each with an owner and a way to find out early.
9. Costs. The build as a fixed scope. Running costs estimated per unit of work, with the assumptions shown.
10. Rules we design around. The regulations that shape the design. Your legal team decides which apply.
11. Next step and open questions. What happens on a Go, and what still has to be confirmed.

A sample memo

The memo below is illustrative. The company is fictional, and so are its details. It shows the shape and the level of detail. It is not the result of a real engagement.

Go/No-Go memo: document intake for small-business lending Client: "Lender X", a fictional mid-sized small-business lender in India. Illustrative only.

Recommendation Go, with conditions. Build extraction for digital bank statements and GST returns first. Scanned documents wait. Conditions: statements from every partner bank, confirmed write access to the loan system, and analyst time to check the test set.

The workflow Credit analysts key figures from bank statements and GST returns into the loan system by hand. The slice starts when a borrower file arrives. It ends when an analyst approves a structured, cited borrower record.

What to build first Opening and closing balances and every transaction line (date, description, credit, debit, balance) from digital bank statements, and turnover from GSTR-3B returns. Each field cites the page it came from. Where a borrower shares data through the Account Aggregator framework, that structured data is used instead; this slice covers statements that arrive as PDFs. Out of scope: scanned statements, audited financials, credit scoring.

Data readiness We reviewed a sample of past borrower files. Most statements are digital PDFs from a handful of banks. Some are phone photos or scans, and those parse badly. Past analyst entries in the loan system can serve as reference answers once they are checked.

Architecture A pipeline, not an agent. Classify each file, extract to a fixed schema, then run reconciliation rules: every transaction row's running balance must equal the previous balance plus credits minus debits, each page's closing balance must match the next page's opening balance, and the statement's opening balance plus total credits minus total debits must equal its closing balance. Known bank formats are read from the PDF's text layer with per-bank templates. A language model handles layouts the templates don't cover, and every figure it returns must appear in the source text. Rules do the arithmetic.

Controls A statement that fails reconciliation goes to an analyst as a whole. So does any field whose confidence falls below a threshold. Confidence comes from checks (the value appears in the source, the template and the model agree, and it passes the schema), and the threshold is set on the test set. Nothing is written to the loan system without analyst approval. If the model is unavailable, or a file can't be classified or parsed, it falls back to the manual queue.

Evaluation plan A test set of past files, with figures double-checked by two analysts. We measure field-level accuracy (amounts exact to the paisa, dates exact), the share of fields sent for review, the share corrected, and the rate of wrong fields that reached an analyst without being flagged. The baseline is the analysts' current keying error rate and time per file. The test set covers every partner bank and includes bad files. The two analysts resolve disagreements before scoring, and thresholds are tuned on separate files, not the test set. The pass threshold is set with the credit team before the build starts.

Risks

1. Bank formats outside the sample. Owner: Lender X, to supply statements from each partner bank at the start of the build.
2. Write access to the loan system's API. Owner: Lender X IT, to confirm before the build starts.
3. The share of scanned files grows. Owner: Lender X's credit team, reviewed monthly after launch; scans become a separate, quoted phase if needed.
4. Edited or forged statements. Tampering detection is out of scope for this slice; the existing fraud checks stay in place.

Costs Build: fixed scope and fixed fee, quoted separately. Running cost: estimated per borrower file, as a range, with the volume and review-rate assumptions written out.

Rules we design around The Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025, and the Reserve Bank of India (Digital Lending) Directions, 2025. Documents are stored and processed in Lender X's own cloud account in India, and the model is called through an endpoint that processes data in India, confirmed before the build. Lender X's compliance team confirms which rules apply.

Next step On Go: a fixed-scope build of the slice above. Open question: can Lender X give analyst time to double-check the test set?

End of illustrative sample.

How to read a memo

Start with the recommendation, then go straight to the risks. A memo with no risks has not looked hard enough. A memo with twenty has not decided which ones matter.

Check that the first slice is small. It should be narrow enough to finish and real enough to run on live work. If it covers five workflows, it is a roadmap.

Read the evaluation plan before the architecture. If nobody can say how quality will be measured, the architecture is guesswork. The test set should come from your own files. The baseline should come from how your team performs today.

Read the costs for their assumptions as well as their totals. Running cost depends on volume, document length and how often a person has to step in. Those assumptions should be written out so your finance team can change them and see what moves.

When the answer is No-Go

A No-Go is a legitimate result. It usually means one of three things. The data is not ready. The workflow is better served by rules or an existing tool. Or the risk outweighs the value. A good No-Go memo says which, and what would need to change before it is worth looking again.

Learning that in a short sprint costs less than learning it halfway through a build.

What to bring

• One workflow that costs real time or money today
• Who owns the systems and data it touches
• A sample of real files
• Your constraints: where data must stay, vendors you already use, deadlines
• What "good" looks like, in numbers if you have them

Asking about the sprint

If you have a workflow in mind and want to know whether it is ready to build, you can ask about the architecture sprint on neurocell.in. The first conversation is about whether a sprint is the right next step at all.