IMDA's New LLM Testing Playbook: What Singapore Developers Need to Know
IMDA's Starter Kit provides a structured framework for testing LLM applications (Royalty-free image from Pexels)
IMDA's New LLM Testing Playbook: What Singapore Developers Need to Know
In January 2026, IMDA released version 1.0 of its Starter Kit for Testing LLM-Based Applications for Safety and Reliability — a 109-page document that codifies emerging best practices for testing LLM apps before they reach users. This isn't just another AI governance paper. It's a practical, structured framework built on real-world testing from over 30 companies across diverse sectors, feedback from 60+ companies in public consultation, and direct collaboration with CSA and GovTech.
If you're building or deploying LLM applications in Singapore — whether for a fintech chatbot, a customer service agent, or an internal knowledge base — this document matters. Here's what's in it and why you should care.
Why a Testing Framework Matters Now
Here's the problem the Starter Kit addresses: most organisations today test their LLM models, but they don't systematically test their LLM applications. The difference matters. A base model like GPT-5.5 or Claude 4 might pass safety benchmarks with flying colours, but the application built on top — with its custom prompts, RAG pipeline, system instructions, and input/output filters — can behave very differently.
The Starter Kit tackles this head-on with a three-step approach:
- Identify — Determine relevant risks, calibrate testing extent, set safety thresholds
- Test — Run structured tests from app outputs down to components
- Assess — Analyse results, determine if thresholds are met, decide on mitigations
This mirrors what good software engineers already do: you don't just test your database queries; you test your whole application. The same principle now applies to AI.
The 5 Key Risks Every LLM App Faces
The Starter Kit focuses on five risk categories that cover most common concerns:
1. Hallucination and Inaccuracy — The tendency to produce incorrect or fabricated output. This gets its own deep section covering domain-specific knowledge testing, out-of-domain topic handling, and RAG component testing. IMDA is even developing Singapore-specific factuality benchmarks (Singapore Factuality Benchmark, Singapore Legal Benchmark, ASEAN Factuality Benchmark) to be available in Project Moonshot by 2026.
2. Bias in Decision Making — Systematic unfairness in recommendations or decisions. The kit recommends parity testing (statistical comparison across groups) and perturbation testing (counterfactual checks by changing selected attributes). This is highly context-dependent — fairness means different things for a hiring tool vs a loan application system.
3. Undesirable Content — Toxic, hateful, stereotypical, legally prohibited, or policy-violating output. Testing covers what type of content is produced, how easily it can be elicited, and whether the app is over-conservative (refusing legitimate requests).
4. Data Leakage — Leaking sensitive information that harms individuals or organisations. This covers types of sensitive data leaked, ease of elicitation, and system prompt testing — particularly relevant for Singapore developers working under PDPA.
5. Vulnerability to Adversarial Prompts — Susceptibility to prompt attacks that override safety mechanisms. This covers direct prompt injections and indirect prompt injections (where malicious content is fed through external data sources).
Structured Testing: Output vs Component
One of the most practical aspects of the Starter Kit is the distinction between output testing and component testing.
Output testing treats the app as a black box — you test the end-to-end behaviour as users would see it. This catches issues that only emerge when all components interact.
Component testing goes inside the pipeline — testing the RAG system, input filters, output filters, system prompts, and model behaviour individually. When output tests fail, component testing helps you isolate the failure point.
For example, if your customer service chatbot gives wrong answers about company policies:
- Output testing would reveal the overall accuracy problem
- Component testing would tell you whether it's a RAG retrieval issue, a model hallucination, or a system prompt misconfiguration
Project Moonshot: The Open-Source Testing Toolkit
The testing methodologies recommended in the Starter Kit are being made available through Project Moonshot, an open-source evaluation toolkit by the AI Verify Foundation (established by IMDA in 2023, now with 200+ members including AWS, Google, IBM, Microsoft, and Salesforce).
Moonshot supports benchmarking and red teaming for LLMs and LLM apps. Key features include:
- Curated datasets: Core benchmarks from the Starter Kit progressively incorporated
- Reliable evaluators: Test datasets paired with suitable metrics — for example, the MLCommons AIluminate benchmark is paired with LlamaGuard-2-8B for lower false negative rates
- Custom evaluators: Users can switch evaluators based on their needs
For Singapore developers, Moonshot is particularly valuable because it will include Singapore-specific benchmarks — the Singapore Factuality Benchmark, Singapore Legal Benchmark, and ASEAN Factuality Benchmark — which aren't available through generic testing tools.
Setting Safety Thresholds: A Singapore Perspective
The Starter Kit makes an important point: there is no universal safety baseline. A medical diagnosis app demands higher accuracy than a general customer enquiry chatbot. Each organisation must determine its own thresholds.
For developers in Singapore's regulated sectors:
- MAS-regulated fintech: Higher thresholds for accuracy and bias testing
- PDPA-covered applications: More rigorous data leakage testing
- Government or public services: Stricter requirements for undesirable content and adversarial prompts
The kit provides guidance on calibrating testing extent based on risk profiles — what they call "proportionate testing." A low-risk internal tool needs less testing than a high-risk public-facing application.
What This Means for Singapore Developers
If you're building with AI in Singapore, this framework gives you a defensible testing methodology. When a regulator, client, or compliance team asks "how do you know your LLM app is safe?", you can point to a structured approach backed by IMDA, CSA, and GovTech.
If you're using Project Moonshot, you get access to Singapore-specific benchmarks that generic testing tools don't have. The Singapore Factuality Benchmark and Singapore Legal Benchmark are being developed specifically because off-the-shelf benchmarks don't adequately cover local context.
If you're worried about cost and complexity, the Starter Kit is designed to be proportionate. Start with output testing for the most relevant risks, use the curated core benchmarks where they apply, and escalate to component testing and red teaming as needed.
The Takeaway
IMDA's Starter Kit v1.0 is a significant milestone for Singapore's AI ecosystem. It moves the conversation from "should we test LLM apps?" to "how should we test LLM apps?" — and provides practical, actionable guidance for developers doing the work.
For Singapore developers, the message is clear: testing isn't optional anymore, but it doesn't have to be ad-hoc either. The tools and frameworks are here. Project Moonshot is open-source and free. The Singapore-specific benchmarks are coming. The only question is whether you start building your testing practice now or wait until a compliance deadline forces your hand.
Download the full Starter Kit: IMDA - Starter Kit for Testing LLM-Based Applications
Disclaimer: This article is for informational purposes only and does not constitute professional or technical advice. AI testing methodologies evolve rapidly. Consult with your organisation's compliance and security teams before implementing specific testing frameworks.
