Home · Work

Systems Work · No. 26

Governed Conversational Adviser

Rajesh Ranjan Mahapatra

A customer-facing regulated guidance assistant that holds a hard boundary between information and regulated advice, computes every number deterministically, cites every claim to approved content, and hands off to a human adviser when the conversation crosses the line.

Start reading
Systems WorkCase study

© 2026 Rajesh Ranjan Mahapatra. 6 min read

Governed Conversational AdviserAll Systems Work
Home · Work

Governed Conversational Adviser

A customer-facing regulated guidance assistant that holds a hard boundary between information and regulated advice, computes every number deterministically, cites every claim to approved content, and hands off to a human adviser when the conversation crosses the line.

Challenge

A major regulated enterprise wanted to offer customers conversational regulated guidance: what they spend, where it goes, what a realistic savings habit could look like.

Architectural move

Every turn passes a suitability router before any generation:

Control boundary

The suitability router, the guardrails and the refusal behaviour each carry their own evaluation set, including adversarial phrasings designed to walk the assistant across the boundary.

Outcome

The programme took the design through build and assurance for a major regulated enterprise.

FIG.00 // SYSTEM MAPREJECTED PATHSTORE / RECORDGATE / HUMANMODELDETERMINISTICSIGNAL / DATAIN · 01Customer turnin the enterprise appGATE · 02Suitability routerinformation orregulated advice, perturnDET · 03Calculation layerevery number,deterministicREC · 04Approved contentversioned guidance baseMDL · 05Guidance composerexplains computedresults, cites contentGRD · 06Blocking guardrailsuncited claims strippedor regeneratedOUT · 07Cited answer rendersGUIDANCE SIDEADVICE SIDEHUMHuman adviseradvice-side turns, withcontext packaged for awarm startSYS/GCAD · FIG.00 · SCHEMATIC · NOT TO SCALE
FIG.00 // SYSTEM MAPSIGNAL / DATADETERMINISTICMODELGATE / HUMANSTORE / RECORDREJECTED PATHIN · 01Customer turnin the enterprise appGATE · 02Suitability routerinformation or regulated advice, per turnGUIDANCE SIDEDET · 03Calculation layerevery number, deterministicREC · 04Approved contentversioned guidance baseMDL · 05Guidance composerexplains computed results, cites contentGRD · 06Blocking guardrailsuncited claims stripped or regeneratedOUT · 07Cited answer rendersADVICE SIDEHUMHuman adviseradvice-side turns, with context packagedfor a warm startSYS/GCAD · FIG.00 · SCHEMATIC
FIG.00 System map. A per-turn boundary, deterministic numbers, cited composition and a designed handoff.

The problem

FIG.01 // THE PROBLEMREJECTED PATHGATEDETERMINISTICINFORMATION"You spent this much onsubscriptions"safe side of the boundaryLEGAL LINEInformation versus advicea fluent model drifts across it inone friendly sentenceREGULATED ADVICE"You should move that intothis product"suitability obligations and anaccountable person→ GUIDANCEESCALATE ←SYS/GCAD · FIG.01 · SCHEMATIC · NOT TO SCALE
FIG.01 // THE PROBLEMDETERMINISTICGATEREJECTED PATHINFORMATION"You spent this much onsubscriptions"safe side of the boundary↑ GUIDANCELEGAL LINEInformation versus advicea fluent model drifts across it in onefriendly sentence↓ ESCALATEREGULATED ADVICE"You should move that into thisproduct"suitability obligations and an accountablepersonSYS/GCAD · FIG.01 · SCHEMATIC
FIG.01 The problem. The demand is obvious and so is the trap: one sentence can cross from information into regulated advice.

A major regulated enterprise wanted to offer customers conversational regulated guidance: what they spend, where it goes, what a realistic savings habit could look like. The demand is obvious and so is the trap. In a regulated market there is a legal line between giving information and giving advice, and a fluent model drifts across that line in a single friendly sentence. "You spent this much on subscriptions" is information. "You should move that into this product" is regulated advice, with suitability obligations attached and a person accountable for it.

I designed the architecture for a governed conversational adviser: spending insight and savings guidance on the safe side of the boundary, a deterministic layer for every number, citations for every claim, and escalation to a human adviser the moment a conversation asks for more than guidance.

Why it was hard

FIG.02 // WHY IT WAS HARDGATE / HUMANDETERMINISTICSIGNAL / DATAHZ · 01Not a topic listPhrasingCustomer circumstancesThree turns earlierHZ · 02Numbers the customercan checkArithmetic belongs tocodeExplanation belongs tothe modelHZ · 03Refusal is a productsurfaceExplain the boundaryOffer the human pathSYS/GCAD · FIG.02 · SCHEMATIC · NOT TO SCALE
FIG.02 // WHY IT WAS HARDSIGNAL / DATADETERMINISTICGATE / HUMANHZ · 01Not a topic listPhrasingCustomer circumstancesThree turns earlierHZ · 02Numbers the customer can checkArithmetic belongs to codeExplanation belongs to the modelHZ · 03Refusal is a product surfaceExplain the boundaryOffer the human pathSYS/GCAD · FIG.02 · SCHEMATIC
FIG.02 Why it was hard. A static blocklist fails in both directions; the boundary has to be classified per turn, in context.

The boundary is not a topic list. The same question can be information or advice depending on phrasing, customer circumstances and what was said three turns earlier, so a static blocklist fails in both directions: it refuses harmless questions and misses the drift that matters. The boundary had to be classified per turn, in context, and enforced by something stronger than a system prompt.

Numbers were the second hazard. A guidance assistant that miscalculates a customer's own spending destroys trust instantly and unfairly, because the customer can check. Language models are the wrong tool for arithmetic and the right tool for explanation, and the architecture had to keep those jobs physically separate.

And refusal itself is a product surface. A wall of "I cannot help with that" teaches customers the assistant is useless; the design needed refusals that explain the boundary and offer the human path.

Key decisions

FIG.03 // KEY DECISIONSGATE / HUMANDETERMINISTICSIGNAL / DATATURNEvery turnbefore any generationROUTERSuitabilityclassifiertiered against theboundaryGUIDANCECalculation layer + composermodel cannot produce a number thelayer did notINFORMATIONCONSERVATIVEAdviser handoffambiguous turns default toadvice-sideAMBIGUOUSADVICEDesigned refusaldecline, explain in plain language,offer the adviserADVICESYS/GCAD · FIG.03 · SCHEMATIC · NOT TO SCALE
FIG.03 // KEY DECISIONSSIGNAL / DATADETERMINISTICGATE / HUMANTURNEvery turnbefore any generationROUTERSuitability classifiertiered against the boundaryINFORMATIONGUIDANCECalculation layer + composermodel cannot produce a number the layerdid notAMBIGUOUSCONSERVATIVEAdviser handoffambiguous turns default to advice-sideADVICEADVICEDesigned refusaldecline, explain in plain language,offer the adviserSYS/GCAD · FIG.03 · SCHEMATIC
FIG.03 Key decisions. The failure mode is a conservative handoff, never a quiet overstep.

Every turn passes a suitability router before any generation: a classifier tiered against the boundary, with ambiguous turns treated as advice-side by default. The failure mode is a conservative handoff, never a quiet overstep.

All arithmetic lives in a deterministic calculation layer: spending aggregation, categorisation, projections, comparisons. The model receives computed results and composes the explanation. It cannot produce a number the calculation layer did not.

Model answers cite approved content. The composer works from a versioned knowledge base of approved guidance material, and a blocking guardrail strips or regenerates any claim without a source.

Refusal behaviour was designed and evaluated as a feature, with its own test set: decline the advice, explain why in plain language, and offer the adviser handoff in the same breath.

The whole stack runs on the enterprise's GCP estate: managed conversational infrastructure at the front, managed model endpoints for composition, the calculation layer as ordinary governed services against curated data.

Architecture

FIG.04 // ARCHITECTUREREJECTED PATHSTORE / RECORDGATEMODELDETERMINISTICSIGNAL / DATAGCP · 01Managed conversational frontcustomer in the appGCP · 02Suitability routerGCP · 03Calculation servicesagainst the customer's owntransactionsGCP · 04Approved contentretrieved per turnGCP · 05Composercomputed results + content, rebuilteach turnGCP · 06Blocking guardrailsthen renderTOTAL SEPARATIONThe model never sees raw balances to add uponly computed results to explainSYS/GCAD · FIG.04 · SCHEMATIC · NOT TO SCALE
FIG.04 // ARCHITECTURESIGNAL / DATADETERMINISTICMODELGATESTORE / RECORDREJECTED PATHGCP · 01Managed conversational frontcustomer in the appGCP · 02Suitability routerGCP · 03Calculation servicesagainst the customer's own transactionsGCP · 04Approved contentretrieved per turnGCP · 05Composercomputed results + content, rebuilt each turnGCP · 06Blocking guardrailsthen renderTOTAL SEPARATIONThe model never sees raw balances toadd uponly computed results to explainSYS/GCAD · FIG.04 · SCHEMATIC
FIG.04 Architecture. The separation of jobs is total: code computes, the model explains.

The customer talks to the assistant in the enterprise app. Each turn crosses the suitability router; guidance-side turns fan out to the calculation layer and the approved content base, and the composer assembles a cited answer that must clear the blocking guardrails before it renders. Advice-side turns route to a human adviser with the conversation context packaged for a warm start.

The separation of jobs is total. The calculation layer computes against the customer's own transaction data through governed services; the model never sees raw balances to add up, only computed results to explain. The composer's context is the calculation output plus retrieved approved content, rebuilt fresh each turn.

Trade-offs

FIG.05 // TRADE-OFFSREJECTED PATHGATEDETERMINISTIC▼ PAYSDESIGN CHOICE▲ BUYSSome answerable questionshanded offT-01Ambiguous means adviceLicence to operateEngineering, not a prompteditT-02Deterministic layerEvery number defensibleNarrower rangeT-03Approved content onlySays only what theorganisation agreed to sayA MINUTE OF ADVISER TIME AGAINST A SUITABILITY BREACHSYS/GCAD · FIG.05 · SCHEMATIC · NOT TO SCALE
FIG.05 // TRADE-OFFSDETERMINISTICGATEREJECTED PATHT-01Ambiguous means advice▼ PAYSSome answerablequestions handedoff▲ BUYSLicence tooperateT-02Deterministic layer▼ PAYSEngineering, nota prompt edit▲ BUYSEvery numberdefensibleT-03Approved content only▼ PAYSNarrower range▲ BUYSSays only whatthe organisationagreed to sayA MINUTE OF ADVISER TIME AGAINST ASUITABILITY BREACHSYS/GCAD · FIG.05 · SCHEMATIC
FIG.05 Trade-offs. Every cost lands on the safe side of the conduct asymmetry.

Treating ambiguous turns as advice-side means the assistant sometimes hands off a question it could arguably have answered, and that conservatism is the licence to operate; the cost of an over-careful handoff is a minute of an adviser's time, the cost of the opposite error is a suitability breach. The deterministic layer means new guidance capabilities need engineering work rather than a prompt edit, which slows the roadmap and keeps every number defensible. Citing only approved content narrows what the assistant can say to what the organisation has agreed to say, and in a customer conduct setting that is precisely the property you want.

Governance

FIG.06 // GOVERNANCEREJECTED PATHSTORE / RECORDGATEDETERMINISTICCONTROLMECHANISMSTATERouter, guardrails, refusalsOwn evaluation sets, including adversarial phrasingsTESTEDEvery answer reconstructableTurn class, calculation I/O, content versions, final textREPLAYABLECertified patternEvaluation pack and control mappingCERTIFIEDBoundary testsRun on every changeBLOCKINGSYS/GCAD · FIG.06 · SCHEMATIC · NOT TO SCALE
FIG.06 // GOVERNANCEDETERMINISTICGATESTORE / RECORDREJECTED PATHTESTEDRouter, guardrails, refusalsOwn evaluation sets, including adversarialphrasingsREPLAYABLEEvery answer reconstructableTurn class, calculation I/O, contentversions, final textCERTIFIEDCertified patternEvaluation pack and control mappingBLOCKINGBoundary testsRun on every changeSYS/GCAD · FIG.06 · SCHEMATIC
FIG.06 Governance. The boundary is the product's most load-bearing feature.

The suitability router, the guardrails and the refusal behaviour each carry their own evaluation set, including adversarial phrasings designed to walk the assistant across the boundary. Every rendered answer is reconstructable: the turn classification, the calculation inputs and outputs, the retrieved content versions and the final text. The pattern shipped as a certified pattern with its evaluation pack and control mapping, and the boundary tests run on every change, because the boundary is the product's most load-bearing feature.

Outcome

FIG.07 // OUTCOMEDETERMINISTICSIGNAL / DATAMOST REUSED ARTEFACTBoundary testsTHE ADVERSARIAL TEST SETSTATUSReferenceFOR CUSTOMER-FACING CONVERSATIONAL WORKTHE SHAPE THAT SURVIVED REVIEWDeterministic numbersCited compositionPer-turn boundary classifierDesigned handoffSYS/GCAD · FIG.07 · SCHEMATIC · NOT TO SCALE
FIG.07 // OUTCOMESIGNAL / DATADETERMINISTICMOST REUSED ARTEFACTBoundary testsTHE ADVERSARIAL TEST SETSTATUSReferenceFOR CUSTOMER-FACING CONVERSATIONAL WORKTHE SHAPE THAT SURVIVED REVIEWDeterministic numbersCited compositionPer-turn boundary classifierDesigned handoffSYS/GCAD · FIG.07 · SCHEMATIC
FIG.07 Outcome. Taken through build and assurance for a major regulated enterprise.

The programme took the design through build and assurance for a major regulated enterprise. The shape that survived review, deterministic numbers, cited composition, a per-turn boundary classifier and a designed handoff, became the reference for other customer-facing conversational work, and the adversarial boundary test set turned out to be the most reused artefact of the engagement.

What I learned

FIG.08 // WHAT I LEARNEDGATE / HUMANDETERMINISTICAX-01Suitability is per turnAnything that treats it staticallyfails an honest test.AX-02Split computation fromexplanationIt removed arithmetic hallucination asa class.AX-03A good refusal builds trustThe handoff to a person is when thecustomer trusts the machine most.SYS/GCAD · FIG.08 · SCHEMATIC · NOT TO SCALE
FIG.08 // WHAT I LEARNEDDETERMINISTICGATE / HUMANAX-01Suitability is per turnAnything that treats it statically fails anhonest test.AX-02Split computation from explanationIt removed arithmetic hallucination as aclass.AX-03A good refusal builds trustThe handoff to a person is when the customertrusts the machine most.SYS/GCAD · FIG.08 · SCHEMATIC
FIG.08 What I learned. Three lessons from the engagement.

Suitability is a per-turn property, not a product category, and anything that treats it statically will fail an honest test. Splitting computation from explanation removed the entire class of arithmetic hallucination instead of mitigating it. And a well-written refusal is not a failure state; done properly, the handoff to a person is the moment the customer trusts the machine most.