Design your indicator once. Execute everywhere.

MERL Studio turns indicator definitions into a single source of truth, flowing into your logframes, data forms, and quality checks automatically. Built for monitoring, evaluation, research, and learning practitioners who deserve better tools.

The methodology-to-execution pipeline

How it works

An indicator usually gets rebuilt at every stage. You define it in planning, retype it into the logframe, build it again in your data tool, then try to reconcile at analysis when the copies don't match.

Here it's defined once, and that definition carries through every stage that follows. Follow one from your theory of change down to analysis: it's the same definition the whole way, never re-entered.

MethodologyExecutionTheory of ChangeIndicatorsLogframeFormsData CollectionQuality ChecksAnalysis
Theory of Change
IMPACTMaternal health outcomes improveOUTCOMEHealth workers apply new protocolsassumptionOUTPUTHealth workers trainedOUTPUTProtocol materials published
Stage 1 · Theory of change

Everything traces back to here.

Your theory of change sets out the change you're aiming for and how you expect to get there, so it's where the pipeline starts. Map it the way your methodology works rather than forced into one fixed shape, and pin each assumption to the outcome that rests on it.

IND · 1.2a
Health workers trained
Type
Count
Frequency
Quarterly
Breakdown
Gender · F / M
Rule
integer ≥ 0
’25 · 80’26 · 90’27 · 100’28 · 112’29 · 125
We'll follow this one the whole way down.
Stage 2 · Indicators

Define what counts as evidence. Once.

Pick the indicators that would actually show whether your programme is working, and define each one properly, with its type, baseline, targets, disaggregation, and the rules that keep it clean. This is the single definition the rest of the pipeline inherits. Nothing downstream needs to have it re-entered.

Output 1.2
Health workers trained IND · 1.2a
58 of 80 this yearon track
Stage 3 · Logframe

It lands in the results framework on its own.

Same definition, now sitting under its result, in whatever shape your donor wants. Nothing retyped, and performance against the target moves as data comes in. The logframe stops being a document you redo at report time.

enter a number…
whole number, 0 or morebreak down by gender (Female / Male)
Rules carried from IND · 1.2a — not retyped
Stage 4 · Forms

The definition becomes the form.

This is the handover from planning to doing. The indicator turns into a question with its rules already attached. What you collect can't drift from what you designed, because it's the same definition. Export it to Kobo, ODK or SurveyCTO if that's where you work.

Stakeholder survey⧉ link
Health workers trainedQ2 2025
enter a number…19
↳ lands on IND · 1.2a14 inClinicPartnerBeneficiary
Their answers come back against the right indicator.
Stage 5 · Collect

The data comes in tied to its indicator.

Collect however the work demands; field teams gathering data from participants, or a survey sent to people outside the programme. Either way, the answers land in the workspace against the indicator they belong to, ready to use. No re-keying, no spreadsheets going round by email.

rejected−2must be 0 or more
flaggedgender breakdown missing
Both rules came straight from IND · 1.2a.
Stage 6 · Quality

The rules you set catch the bad data.

The validation from the indicator runs the moment data arrives, and again in the background. A wrong unit or an impossible number gets flagged then, not six months later mid-analysis. The methodology you committed to in planning is doing the checking.

Health workers trained · 2025on track
61
105% of expected+3 vs target
target58’25’26’27’28’29
Female32
Male29
on trajectoryquality · high→ back into the contribution story
Stage 7 · Analysis

Clean data, and the story it was meant to tell.

Because it was defined once and checked on the way in, the data comes out disaggregated and consistent; the cleaning step mostly isn’t there. And it lines back up against the theory of change you started with, so you're not just reporting numbers: you can show the change behind them, and trace your contribution to it.

1 / 7
Theory of Change
IMPACTMaternal health outcomes improveOUTCOMEHealth workers apply new protocolsassumptionOUTPUTHealth workers trainedOUTPUTProtocol materials published
IND · 1.2a
Health workers trained
Type
Count
Frequency
Quarterly
Breakdown
Gender · F / M
Rule
integer ≥ 0
’25 · 80’26 · 90’27 · 100’28 · 112’29 · 125
We'll follow this one the whole way down.
Output 1.2
Health workers trained IND · 1.2a
58 of 80 this yearon track
enter a number…
whole number, 0 or morebreak down by gender (Female / Male)
Rules carried from IND · 1.2a — not retyped
Stakeholder survey⧉ link
Health workers trainedQ2 2025
enter a number…19
↳ lands on IND · 1.2a14 inClinicPartnerBeneficiary
Their answers come back against the right indicator.
rejected−2must be 0 or more
flaggedgender breakdown missing
Both rules came straight from IND · 1.2a.
Health workers trained · 2025on track
61
105% of expected+3 vs target
target58’25’26’27’28’29
Female32
Male29
on trajectoryquality · high→ back into the contribution story

The pipeline runs between two layers.

At the design end, the Data Framework defines the entity types, attributes, and shared model that everything else in the pipeline references.

At the execution end, the Field Portal is where field teams collect data against participants and activities, filling that shared model with real data from the ground.

Data Framework · design end
HouseholdParticipant
+ Add field
Household nametext
Household sizeinteger
Districtsingle-select
GPS locationgps
compiled schemav6v7
  • Defines the entity types your programme tracks — people, groups, interventions — and the demographic fields relevant to each.
  • Point-and-click field creation. No code, no IT request.
  • A deliberate, one-time setup, not ongoing database admin.
  • Acts as the shared definition layer every other app references, so nothing has to be reconciled across separate tools.
  • A participant registered by field teams is the same one indicators aggregate and analysis reads back later.
  • Indicators disaggregate by characteristics defined once here, not by whatever a given form happened to ask.
Field Portal · execution end
Field Portal Offline · 3 queued Syncing · 1 queued Online · Synced
Household SurveyOpen
Key Informant InterviewOpen
Focus Group DiscussionOpen
Observation ChecklistOpen
DashboardCollectObserveIntervene
  • The app field teams use to collect data — forms, activity logs and impact stories, all captured in one place.
  • Fully offline-capable. Works with no signal, syncs on reconnect.
  • Runs the instruments exactly as they were designed.
  • No re-keying into a separate tool, so collection can't drift from what was designed upstream.
  • Participants register against the entity types set up in the Data Framework, so records line up cleanly.
  • The result is structured data that matches what was meant to be measured, not a mismatch to fix later.

Beyond the pipeline

The pipeline is the core loop. A programme needs more around it: the evidence behind your design choices, the assumptions and risks you're carrying, and the delivery you schedule in the field.

Research Library

A citable evidence base built into the workspace. Add a source once by URL, DOI, or BibTeX import, and cite it from an indicator, a logframe outcome, or a theory of change assertion. Six months on, a new team member can see what evidence justified a design decision, instead of it living in someone's memory or a buried Word doc.

Risk & Assumptions Register

Every assumption and risk you record for your theory of change, or against a logframe result, collects in one register. Write it once, reference it in both places, and see the whole set in a single view: what's active, what's high-impact and still unmitigated, what's already materialised. The assumptions column of a logframe stops being dead text you retype each reporting round.

Activity Planner

Plan what your programme does in the field and when: sessions, visits, distributions. Schedule them on a recurring cadence, generate the daily tasks they produce, and push those to field workers as a checklist. Completion flows back on its own, with no separate tracking sheet to keep in sync.

Pay only for the workspaces you run

First month free on every workspace. Upgrade only when you need to invite others.

Solo
Free

For independent practitioners evaluating the platform or running one small project.

1 workspace owned
Full methodology toolkit
Build & preview forms (deployment on Project)
Get started free
Annual billing. 20% off the monthly equivalent.Pause anytime. Paused workspaces don't accrue charges.Bigger needs? Talk to us.

Stop scrambling at report time

Try MERL Studio with your own project

Get started free