Introducing Cense AI

Problem

Before Centinel, compliance professionals relied on structured reports to understand complex crypto activity. When a customer supplied a separate explanation of how their wealth had been accumulated, analysts had to reconcile that account with the report evidence themselves.

An open-ended AI assistant appeared to offer a faster way to investigate the information. However, early concepts resembled a conventional chatbot and brought assumptions that did not fit a regulated workflow. Users could not immediately tell what information the assistant could access, whether it was restricted to the current report, or whether case information might be shared with an external model.

Hallucination was the most significant concern. A fluent response could appear authoritative even when it contained an unsupported connection. Compliance professionals needed to know where important claims came from and what information had influenced the answer before they could rely on it.

The experience also failed to distinguish clearly between two fundamentally different forms of information. The report contained deterministic evidence, while the assistant produced probabilistic summaries and interpretations. Giving both the same visual authority risked turning a helpful explanation into apparent fact.

Suggested questions created another source of ambiguity. Some early prompts related to the report, while others addressed crypto topics more broadly. Users could not reliably predict whether an answer would use report evidence, information from elsewhere in Cense, or external knowledge.

‘If the answer sounds confident but I cannot click through to the report evidence behind it, I cannot use it in a decision. I need to see where the claim came from.’

COMPLIANCE PROFESSIONAL

Needs to trace meaningful claims back to inspectable evidence before using them in a compliance decision.

‘I am never sure what this assistant can see. Is it only this report, or does it pull in other case data, and how much of that leaves our environment?’

COMPLIANCE STAKEHOLDER

Needs to understand what the assistant can access and how probabilistic output differs from verified report information.

The central design question became:

How might we make probabilistic AI useful in an evidence-led compliance workflow without hiding uncertainty or weakening human accountability?

Proposal & Process

The proposal was to transform Centinel from an open-ended chatbot into a report-grounded assistant that could help compliance professionals investigate cases, compare customer-provided information with report evidence, and retain ownership of the final decision.

• Built and tested a live prototype.

  We developed a working prototype during the first month rather than limiting early research to static screens. This allowed us to study variable answers, loading behaviour, source verification, and the questions users naturally asked.

• Interviewed compliance professionals through realistic report tasks.

  During moderated sessions, we showed participants a report and asked them to write the questions they would ask about it. We then observed how they interpreted the answers, when they searched for evidence, what caused hesitation, and how they responded when an answer was incomplete.

• Identified the conditions required for trust.

  Research showed that users needed more than a general disclaimer. They wanted visible boundaries around scope and data handling, clear identification of AI-generated information, and direct access to the report evidence supporting important claims.

• Mapped the information layers.

  We separated the experience into deterministic report evidence, probabilistic AI interpretation, and human judgment. This model helped the team define what the system could establish, what it could only suggest, and what remained the analyst’s responsibility.

• Created several interaction models.

  I prototyped different layouts, response structures, suggested questions, source-navigation patterns, and system states. Keeping the assistant visually close to the report reduced the effort required to move between an answer and its evidence.

• Made suggested questions contextual.

  Early starter prompts were too generic and blurred the boundary between report analysis and broader crypto knowledge. We revised them to reflect the report being viewed, helping users understand the assistant’s scope before composing their own question.

• Designed the complete interaction lifecycle.

  The prototypes included loading, error, retry, feedback, follow-up, source-navigation, and insufficient-evidence states. These were treated as core parts of the experience because an unexplained delay or overly confident fallback could undermine trust as much as an incorrect answer.

• Structured the Source of Wealth experience through research.

  The focused SoW workstream identified the high-level information analysts considered most important when evaluating how wealth had been accumulated. Those findings informed a confidential internal taxonomy and the fallback behaviour for evidence that was ambiguous or did not fit a standard category.

• Reduced the information supplied to the AI.

  Giving the model too much report data increased the opportunity for unsupported connections while adding latency and cost. We constrained the input to task-relevant evidence, structured it before processing, and refined the underlying instructions.

• Iterated through moderated and production learning.

  Interviews, usability testing, and prototype revisions were repeated as new concerns emerged around scope, sources, uncertainty, and edge cases. After release, production feedback and usage analytics extended the research into real-world use and informed further refinement.

• Coordinated implementation with product and engineering.

  I worked with the wider team to align the interaction design with data availability, prompt scope, feasibility, latency, and operating cost. The prototypes acted as behavioural specifications for both the interface and the expected AI response.

• Released the complete designed experience.

  All of the capabilities covered by the project moved from prototype to the shipped product.

Result

The initiative produced four principal deliverables:

• A report-grounded AI assistant.

  Centinel evolved from a general chat concept into an assistant situated within the report workflow. Users could ask case-specific questions while remaining connected to the evidence they were investigating.

• An inspectable response structure.

  AI-generated information was distinguished from deterministic report data. Responses communicated their scope, linked important claims to supporting evidence, and preserved the analyst’s responsibility to review the output.

• Contextual guidance and resilient system states.

  Suggested questions became relevant to the report being viewed. The shipped experience also accounted for loading, follow-up, feedback, errors, retries, unavailable sources, and insufficient evidence.

• A Source of Wealth summary and comparison workflow.

  The SoW experience organised task-relevant information into a concise, reviewable summary. It allowed compliance professionals to compare a customer’s account with the evidence in the report without presenting the AI output as an automated approval or rejection.

Across these deliverables, AI supported retrieval, summarisation, comparison, and explanation. Deterministic calculations remained part of the report, while the final compliance judgment remained with the user.

Impact

Exact customer, usage, and performance figures cannot be disclosed in this public case study. The available impact is therefore described qualitatively.

Client feedback on the shipped experience was strongly positive. Centinel introduced a new way for compliance teams to bring customer-provided information into their analysis and compare it with the evidence available in Cense.

The contextual questions and explanations made complex crypto reports more approachable for users without extensive crypto expertise. At the same time, access to the underlying evidence remained available for verification.

Separating deterministic information from probabilistic interpretation also gave the product a clearer and more credible AI proposition. It demonstrated where AI added value without suggesting that it replaced the report or the compliance professional.

Production feedback and usage analytics created an ongoing learning loop after release. This extended the research beyond moderated sessions and allowed the team to refine the experience based on real behaviour.

Challenges

This initiative faced several challenges, including:

• Designing for justified scepticism.

  Users’ concerns about privacy, hallucination, and auditability reflected professional responsibility rather than resistance to AI. We responded by treating scope, sources, system identity, and uncertainty as interaction requirements rather than relying on a disclaimer.

• Separating evidence from interpretation without overloading the interface.

  Users needed to understand which information came from the report and which had been generated by AI. The design had to communicate that distinction while keeping the report readable and the assistant practical to use.

• Researching a variable, live AI experience.

  The same interaction could produce different responses, and important behaviours only appeared during waiting, failure, or verification. A live prototype allowed us to test the system’s behaviour alongside the visible interface.

• Balancing relevance, latency, cost, and hallucination risk.

  A larger context appeared more comprehensive but increased cost and created more opportunities for unsupported synthesis. We constrained the system to task-relevant evidence, accepting narrower scope in exchange for more focused and explainable responses.

• Handling ambiguity without creating false certainty.

  Real Source of Wealth histories did not always fit a clean category. We designed explicit fallback states so that unclear or insufficient evidence could remain unresolved rather than being forced into a complete-looking narrative.

Role

This initiative required me to wear two hats:

UX Researcher

I planned and conducted interviews and moderated usability tests with compliance professionals. I used report-based tasks to identify the questions participants naturally asked and observed how they interpreted, verified, and challenged the resulting answers.

I translated concerns about hallucination, privacy, scope, and auditability into research findings the team could act on. I also used production feedback and usage analytics to extend the research after release.

For the Source of Wealth workstream, my research helped identify which high-level information mattered most to analysts. These findings contributed to the structure and fallback behaviour of the experience without exposing the confidential internal taxonomy.

UX Designer

I built and iterated the live prototype from the first month of the project. I created several interaction models and designed the relationship between deterministic evidence, AI-generated interpretation, sources, contextual questions, and human judgment.

I also prototyped loading, error, retry, feedback, follow-up, source-navigation, and insufficient-evidence states. This work treated AI behaviour as part of the user experience rather than limiting design to the appearance of the chat interface.

I collaborated with product and engineering on data scope, underlying instructions, feasibility, latency, and cost. Together, we moved the complete designed experience from prototype into the shipped product.

Learnings

From this project, I took away four main lessons:

• Trust must be inspectable:

  A disclaimer cannot carry the full burden of trust in a high-stakes workflow. Users need to see scope, sources, uncertainty, and a path back to evidence while evaluating the answer.

• Live prototypes expose the real AI experience:

  Releasing a usable prototype in the first month allowed us to study variable responses, waiting, verification, and failure behaviour that static screens would not have revealed.

• Constraining AI can increase its value:

  Reducing the available context improved relevance, made answers easier to explain, limited opportunities for unsupported synthesis, and helped control latency and cost.

• UX research can shape system behaviour:

  Research did more than identify interface preferences. It influenced which information the system prioritised, how inputs were structured, and when the experience should return an honest fallback instead of a confident answer.

Bonus

The distinction between deterministic evidence and probabilistic interpretation became useful beyond the core compliance workflow. During demonstrations with prospective customers, it helped the team explain what the report could establish, where AI added interpretation, what guardrails were in place, and why human review remained necessary.