How to Stop AI From Guessing Your M&E Indicator Definitions:
Practical AI Tutorial for M&E and International Development
Stop Letting AI Guess Your Indicator Definitions: An OKF Starter Guide for M&E Teams
Ask an AI tool for your dropout rate formula and it will answer confidently – whether or not it picked the right one. Google Cloud’s Open Knowledge Format (OKF) gives you a simple way to write your organisation’s canonical definitions once, so any AI tool reads the approved version instead of guessing from whatever document it happened to find.
Quick answer
OKF is an open specification, published by Google Cloud in June 2026, for writing your organisation’s canonical facts – indicator formulas, definitions, standard operating procedures – as plain Markdown files with a short metadata header. Write one file per concept, keep the bundle in a shared folder or Git repository, and give an AI tool like Claude that bundle to check before it answers. For everything outside that curated set, a broader search tool such as NotebookLM still does the job of finding relevant material across your wider document archive.
What you will learn
Why AI search finds similar answers, not necessarily correct ones.
Turn one indicator definition into a canonical reference.
Organise definitions, formulas and SOPs your team can trust.
Get consistent answers instead of confident guesses.
Important: what OKF actually is
OKF is a file format specification, not a product, a service or a piece of software you install. Google Cloud published version 0.1 as a draft in June 2026: a set of conventions for writing knowledge as Markdown files with a short YAML metadata header at the top. Any tool that can read a text file can read an OKF bundle – there is no required software development kit and no vendor lock-in.
Note the name collision: the Open Knowledge Format is unrelated to the Open Knowledge Foundation, a long-running non-profit that promotes open data. They share an abbreviation and nothing else.
Because the specification is new and still in draft, expect it to evolve. What will not change is the underlying idea, which you can start using today with nothing more than a text editor: write your canonical facts down once, in one place, in a format both people and AI tools can read.
The six-step workflow
List the facts your team keeps re-deriving or disputing
A short Markdown file with a metadata header
Organise files into a shared folder or repository
Upload the bundle as reference material
Canonical file first, broader search only if nothing exists
Keep an owner and an approval trail for every file
Why this matters for M&E specifically
Most M&E teams already have a version of this problem: the results framework defines an indicator one way, an old project document defines it slightly differently, and a field office spreadsheet uses a third variant. Ask an AI tool to summarise “the” dropout rate or completion rate across your programme documents, and it will retrieve whichever version reads as most relevant to the question – not necessarily the one your MEL plan actually specifies.
A search tool built on semantic similarity, such as NotebookLM or a typical retrieval-augmented search system, is genuinely good at finding relevant material across a large, messy document archive. It is not designed to know which of three similar-sounding definitions is the approved one. OKF addresses that gap: for the small set of facts that must be exact, you write the answer once, mark it as canonical, and point your AI tools there first.
Identify what actually needs to be canonical
Start small. Not every fact needs this treatment – only the ones people keep getting wrong.
List the indicator formulas, definitions and procedures your team re-derives, disputes, or answers inconsistently across reports. A results framework indicator with a precise formula, a standard case definition used in protection monitoring, or a data collection SOP are strong candidates. A one-off analysis or a document that will not be reused is not – OKF is for facts that need to stay the same every time someone or something asks for them.
Write one OKF file per concept
A short metadata header, then the definition in plain language.
Each file covers exactly one concept – one indicator, one procedure, one definition – so it stays easy to find and easy to review. The header records who owns the definition and when it was last approved; the body states the definition itself, plainly enough that a new team member could apply it correctly without asking anyone.
type: indicator
title: “Programme Completion Rate”
description: “Official formula for reporting completion rate in donor and board reports.”
owner: “meal-unit”
tags: [results-framework, output-indicator]
last_approved: 2026-07-01
—# Programme Completion RateCompletion Rate = (Participants Completing All Required Sessions / Participants Enrolled at Baseline) x 100
Rules:
– Count a participant as enrolled only if present at the baseline session.
– Do not count participants who transferred to another programme as dropouts.
– Source of truth: MEAL tracker, “completion_status” column.
Related: Dropout Rate, Enrolment Register SOP
Keep the language in the body close to how you would explain it to a new enumerator – specific enough to remove ambiguity, short enough that someone will actually read it.
Build the knowledge bundle
A folder of files is the whole system – no database, no special software.
Put your OKF files in a single shared folder – a shared drive folder works, and a Git repository works better if your organisation already uses one, since Git gives you a built-in history of who changed each definition and when. Group related files into subfolders if the bundle grows large, for example one folder for indicator definitions and another for safeguarding and data collection procedures.
Give the bundle to Claude
No special tooling required – Claude reads Markdown files directly.
Upload the OKF files as attachments in a Claude conversation, or add them to a Project’s knowledge base if you use Projects for recurring M&E work, so they are available every time without re-uploading. Because OKF files are plain Markdown, Claude reads them exactly as written – there is no embedding step and nothing to configure.
Set the fallback rule
Tell Claude which source wins when a question could go either way.
The routing rule in plain language
“What’s our dropout rate formula?”
Does a canonical file answer this exactly?
No: fall back to a broader search tool such as NotebookLM
Say this rule explicitly in your prompt or Project instructions, since Claude will not assume it. A short instruction is enough to establish the priority order.
Review and maintain the bundle
A canonical source that nobody updates becomes a confidently wrong one.
Set a review cadence – at minimum whenever your results framework or MEL plan changes – and update the relevant file’s owner and approval date alongside the content. If you keep the bundle in Git, changes go through the same pull-request review your code or documentation already uses, which gives you a full audit trail of who changed a definition, when, and why.
What to put in your first M&E knowledge bundle
Start with the five or six facts your team most often gets asked to clarify or re-derive.
Indicator formulas
The exact calculation for each results-framework indicator, with the source dataset or column named.
Case definitions
Standard definitions used in protection or safeguarding monitoring, so classification stays consistent across field teams.
Data collection SOPs
Step-by-step procedures for enumerators, including consent scripts and quality-control checks.
Results framework glossary
Agreed definitions of outcome, output and impact-level terms as your organisation uses them.
DAC criteria interpretation
How your organisation operationalises relevance, effectiveness, efficiency, impact and sustainability for its own evaluations.
Reporting cut-off rules
Which dates, thresholds or exclusions apply when compiling a quarterly or annual report.
Where this fits into your daily M&E workload
Once your first bundle exists, it earns its keep in the small, repeated tasks that eat a MEAL officer’s week – not just in big report-writing moments.
“How do we calculate this indicator again?” gets answered from the approved file in seconds, instead of a message chain to head office.
Ask Claude to populate a tracking table using the exact formulas in the bundle, so the numbers are calculated the same way every reporting period.
Point new team members at the bundle instead of a scattered set of old emails and outdated SOP versions.
Ask Claude to flag where a partner’s reported figures use a different formula or case definition than your canonical version.
Draft narrative sections that cite indicator definitions consistently with previous submissions to the same donor.
Use the bundle as the reference standard when checking whether field data was recorded and coded consistently with your SOPs.
What to avoid
- Writing an OKF file for a fact nobody actually disputes – it adds maintenance overhead with no benefit.
- Leaving a file without a named owner, so an outdated definition never gets corrected.
- Putting personally identifiable or protection-sensitive information inside an OKF file – these are meant for definitions and procedures, not case records.
- Forgetting to tell Claude the fallback rule – without it, Claude has no reason to prefer the bundle over anything else it can see.
- Treating a draft, unapproved definition as canonical simply because it was the first one written down.
- Assuming OKF replaces your MEL plan or results framework – it is a format for representing the definitions those documents already establish, not a substitute for them.
Responsible-use checklist
Suggested methodology disclosure wording
Frequently asked questions
Is OKF a Google product I need to sign up for?
No. OKF is an open file-format specification, not a hosted service. You write plain Markdown files yourself and store them wherever your organisation already keeps documents – a shared drive or a Git repository both work.
How is this different from the NotebookLM and Claude workflow described elsewhere on the Academy?
That workflow is built for finding and synthesising relevant material across a large, unstructured document archive – literature, reports, transcripts. OKF is for the small set of facts that need one exact, approved answer every time, such as an indicator formula. The two complement each other: canonical facts in an OKF bundle, everything else searched more broadly.
Do I need a developer to set this up?
No. Writing OKF files and uploading them to Claude requires nothing more than a text editor and the attachment or Project knowledge feature. A developer becomes useful only if you want to automate the routing between the bundle and a larger search system at scale.
What if Claude answers from general knowledge instead of the bundle?
Check that the fallback rule was stated explicitly and that the file was actually uploaded or included in the Project’s knowledge for that conversation. If Claude still does not follow the rule, restate it and ask it to confirm which file, if any, it used.
Is the specification stable enough to build on now?
OKF v0.1 is published as a draft and will likely evolve. The underlying practice – writing your canonical definitions once, in a shared, version-controlled format – is worth adopting now regardless of how the formal specification changes, since it is a plain Markdown file either way.
Official guidance
For the current OKF specification, consult Google Cloud’s announcement and the public Knowledge Catalog repository. For current details on uploading files and Projects in Claude, consult Anthropic’s documentation and Claude support.
Continue learning with EvalCommunity Academy
Build practical and responsible AI skills for evaluation, programme management, development and humanitarian work.
