Compare outcome, population, method, timing, calculation, and decision—then match, translate, extend, or resolve each proposed measure.
In short: Define measures the organization and funder can both use by comparing the intended outcome, population, definition, method, timing, disaggregation, and decision—not by choosing whichever metric appears in the application template. Keep exact matches, translate differences explicitly, add valid funder-specific views, and escalate conflicts or missing evidence. The output is a shared measure specification that both parties can interpret without weakening the organization’s own outcome logic.
In short: A measure is shared when both parties agree on what is being observed, who is included, how and when it is measured, how it is calculated, what missing evidence means, and which decision it can support.
The label is the least reliable part. “People served,” “jobs created,” “retention,” “well-being,” or “households reached” can conceal different populations, thresholds, time windows, data sources, and exclusions. Agreement on a label without agreement on the specification creates false alignment.
Begin with the outcome the organization is accountable for and the decision the funder needs to make. Then ask whether one indicator can represent that outcome credibly, whether several indicators are needed, or whether the evidence is not yet available. Fewer measures are useful only when they still cover the claims and decisions that matter.
In short: Every proposed measure should fall into one of four action categories. The category determines whether to reuse, crosswalk, add, or discuss the measure.
In short: Compare at least seven attributes before treating two measures as equivalent.
| Attribute | Question | Common hidden difference |
|---|---|---|
| Construct | What change or condition is being represented? | Job start versus stable employment |
| Population | Who is eligible for the numerator and denominator? | All enrolled participants versus program completers |
| Method and source | How is the value produced and verified? | Self-report versus employer or administrative verification |
| Timing | At what event or follow-up window? | At exit versus 90 days after exit |
| Calculation | What are the numerator, denominator, aggregation, and rounding rules? | Rate among respondents versus rate among all eligible participants |
| Disaggregation | Which groups or places must remain visible? | Portfolio total hiding disability or place-based differences |
| Decision and claim | What action or conclusion is this measure allowed to support? | Operational monitoring presented as proof of attribution |
In short: Write enough detail that a program lead, partner, analyst, and funder would compute and interpret the measure the same way using the same records.
The specification should include:
Illustrative example. A workforce funder requests “number of participants placed in employment.” The organization’s primary outcome is “participants in accessible paid employment retained for 90 days.” The terms concern employment, but they are not the same measure.
| Measure | Definition | Alignment action | Report treatment |
|---|---|---|---|
placement_start | Eligible participant begins paid employment during the reporting period. | EXTEND | Provide the required funder output count. |
employment_90d | Program completer remains in accessible paid employment at the 90-day follow-up. | MATCH organization model | Retain as the core outcome. |
access_barrier_theme | Human-reviewed qualitative code describing reported barriers or enabling conditions. | TRANSLATE context | Use to explain differences and guide program action; do not convert it into a placement value. |
The agreement can include all three. The funder receives the requested placement count; the organization does not relabel it as retained employment; and participant evidence explains why results differ by disability, place, or program design. Alignment expands the evidence rather than flattening it.
In short: Keep the smallest set that covers the decisions and material claims without hiding important differences. There is no universal correct number.
Remove a measure when it has no owner, no decision, duplicates another measure exactly, or cannot be interpreted with available evidence. Keep multiple measures when they represent different levels of a pathway, populations, time windows, risks, or stakeholder perspectives. A count of people trained, a competency change, and six-month employment are not redundant merely because they concern the same program.
In short: Map after the shared measure is fully defined. Record the exact external metric or disclosure, version, match quality, and any differences in boundary or calculation.
Use the official UN SDG indicator framework, the current IRIS+ catalog downloads, or the applicable GRI Standards. Do not claim exact alignment because the external label resembles the local outcome.
Compare the approved Organization Evidence Model, verified Funder Context Profile, current measure definitions, and named external standard. For each proposed measure, return: decision supported; organization outcome and definition; funder requirement and exact source; construct; population; method/source; timing; calculation; disaggregation; missing-data rule; external mapping and version; and an action of MATCH, TRANSLATE, EXTEND, or RESOLVE. Cite both sides. Do not invent a metric, target, source, or funder preference. List contradictions, missing evidence, privacy concerns, and human decisions required before approval.
The method can begin in a crosswalk spreadsheet. The problem appears when the same measure is used across forms, partners, programs, periods, funders, and reports while definitions continue to change.
Sopact Sense can connect each shared measure to the source requirement, governed dictionary record, collection fields, qualitative evidence, calculation, disaggregation, and report view. It can flag missing attributes or conflicting definitions and regenerate audience-specific outputs from approved records. People approve definitions, mappings, targets, access rules, and exceptions; generated recommendations never become governed measures automatically.
Name the decision; start from the organization’s outcome; extract the funder’s sourced requirement; compare construct, population, method, timing, calculation, and disaggregation; classify the relationship as Match, Translate, Extend, or Resolve; write the full specification; and test it against real and incomplete records.
An outcome is the change or condition the organization cares about. An indicator is the observable measure used to assess some aspect of that outcome. One outcome may require several indicators, and one indicator rarely captures every stakeholder perspective or causal explanation.
They should draw from the same governed evidence model, but valid audience-specific views may differ. A funder-specific extension is acceptable when it is clearly defined and does not silently replace the organization’s core outcome or rewrite historical data.
Compare the complete specification. The same label can hide different populations, denominators, sources, time windows, or missing-data rules. Treat it as a Match only when the substantive rules agree.
Mark it missing and decide whether to collect it prospectively, use a defensible alternative, disclose the limitation, renegotiate the requirement, or decline the claim. Do not reconstruct unsupported historical values with AI.
Define the question, source, consent, sampling or inclusion rule, coding method, review process, and permitted interpretation. Qualitative evidence can explain mechanism, context, variation, and unintended outcomes; it should not be silently converted into a quantitative value.
AI can compare documents, draft specifications, and flag conflicts. It cannot decide organizational priorities, infer funder intent, establish validity, or approve a measure. Require citations, testing across groups and formats, named owners, and documented human overrides.
No. Comparability also depends on population, unit, period, boundary, calculation, source, and missing-data treatment. Record the exact standard version and mapping quality rather than treating a shared code as proof of identical implementation.
ChatGPT, Claude, and Gemini are fine for a quick test — but not for an answer you'll put in front of a funder or board. When it has to hold up, run it in Sopact Sense.
Define shared measures in Sopact →
