This deep dive expands on the Loop Asia conversation with Koo Ping Shung, Practicum Director at Data Science Rex.

One line from my conversation with Koo Ping Shung deserves more attention than the episode gives it: "How good the retrieval would be would depend on how good the documentation is done." He said it almost in passing — but for anyone accountable for AI governance and data infrastructure, that's the ceiling on everything you're about to build.

RAG systems, internal copilots, agentic tools reaching into a knowledge base are all a retrieval layer on top of whatever documentation exists. The model doesn't set the ceiling. Your documentation does. Most organisations treat documentation as an afterthought remediated during onboarding, an audit, or a postmortem — not an engineering artifact with a quality bar and an owner. Koo's point: that stops being optional once an LLM sits in front of it — the model confidently retrieves from whatever's there, gaps and stale sections included.

The use-case library as a governance control, not a wiki

Koo's more interesting idea: a library of AI use cases — successes and failures both — as the actual substrate of governance, missing not just inside companies but at a national level. Taken seriously, that's not a documentation nice-to-have — it's a missing control.

It's a structured record of prior decisions, constraints, failure modes, and reasoning — closer to a regression test suite than a wiki page. It lets a governance committee reference precedent instead of re-litigating first principles every time. Without it, every review starts from zero, which is why Koo says most organisations he sees haven't reached governance maturity: they're still working out how to report and dashboard well, let alone maintain precedent.

If you own architecture and integration, this is buildable, not a policy aspiration: a schema — use case, owner, data sources, risk classification, outcome, what you'd do differently — stored somewhere queryable, reviewed at intake for every new AI initiative. It doubles as training material for the next LLM tool you build.

Bootstrapping documentation structure with the model itself

Koo's second idea is smaller but useful: use the LLM to design the documentation schema before you use it to retrieve from that documentation. His example: a new hire asks an LLM what areas to cover when documenting a data collection process, then documents against that structure. Generalise it to whatever your team has never formalised — pipelines, models, integration contracts — and you get a bootstrapping pattern: ask the model for a structure, check it against your own domain knowledge, make documenting against it part of the definition of done. That turns documentation debt into technical debt: visible, trackable, payable down incrementally.

Why this belongs on the CTO's desk, not the compliance team's

The instinct in a lot of organisations is to route AI governance to legal, risk, or compliance, and leave documentation as their problem to chase. Koo's framing argues the opposite: governance quality is downstream of documentation quality, which makes it an architecture decision, not just a policy one. The people who own the pipelines, schemas, and integration contracts determine whether your AI governance has anything real to stand on.