Trace any released number, qualitative theme, or narrative claim through its definition, method, evidence snapshot, source records, limitations, and approval—without exposing sensitive participant data.
To trace every result back to its evidence, give each released number, theme, and narrative claim a Claim-to-Source Trail. The trail should preserve the question being answered, the approved definition, the evidence snapshot, the calculation or qualitative rule, the exact supporting records or excerpts, the permitted attribution level, any exceptions, and the person who approved the release. A reader should be able to inspect why the claim is supported without asking the analyst to reconstruct it.
This chapter is for program, MEL, grant, foundation, portfolio, and data leads who must answer a deceptively simple question: “Where did this result come from?” Chapter 8 produced a stable Reliability Release. Chapter 9 makes that release inspectable. You will build one practical artifact—a Claim-to-Source Trail—for quantitative, qualitative, and attribution claims.
Reliability and traceability are different
Reliability asks: “Will the governed method produce the same released result again?”
Traceability asks: “Can I inspect exactly why this result is supported?”
You need both. A result can be consistently wrong, or well-sourced but impossible to reproduce.
In short: Start with the exact released claim, connect it to its approved meaning and method, preserve the evidence used at release time, and expose a permission-aware path to the supporting records, exceptions, and approval.
In short: A Claim-to-Source Trail is a compact record that connects a released statement to its meaning, method, evidence, judgment, and approval. It is not another report. It is the inspectable path behind the report.
The Evidence Map from Chapter 6 provides the context at the top of this trail. It already states the decision question, approved measure, required sources, gaps, breakdowns, and claim boundary. Traceability carries that context through the analysis and into the released report. Without it, a source link may prove that a file exists while failing to prove that the claim means what the report says it means.
In short: A file is a container, not an explanation. A funder still needs to know which rows counted, which definition and period applied, how duplicates and missing values were handled, what calculation produced the figure, and which version was approved.
| Weak trace | What remains unanswered | Claim-to-Source Trail |
|---|---|---|
| “See attendance.xlsx” | Which cohort, dates, event, rows, denominator, duplicates, and missing states? | Approved attendance definition + query + evidence snapshot + included and excluded records |
| “Interviews show financial hardship” | Which interviews, whose interpretation, which exact words, and how common? | Theme definition + codebook version + reviewed excerpts + source context + exceptions |
| “Our outreach improved attendance” | Does the evidence show sequence, participant attribution, plausible contribution, or causation? | Event timeline + supporting records + Evidence Map attribution limit + reviewer and limitation |
In short: All three use the same trail, but their proof is different. A number depends on governed records and calculation logic. A theme depends on a code and reviewable excerpts. An attribution claim depends on an explicit claim boundary and evidence capable of supporting it.
| Result type | Meaning to preserve | Method to retain | Evidence a reviewer should reach |
|---|---|---|---|
| Number | Indicator, population, numerator, denominator, period, and breakdown | Saved query, filters, joins, exclusions, formula, and versions | Included rows, excluded rows, source records, missing states, and corrections |
| Qualitative theme | Theme definition, population, source type, period, and whether prevalence is being claimed | Codebook, inclusion/exclusion examples, AI proposal, human review, overrides, and version | Exact excerpts, source location, participant/program context, contradictory excerpts, and review status |
| Narrative or attribution claim | What is observed, what changed, and how strongly the program may be connected to it | Evidence Map claim boundary, timeline, comparison or method, assumptions, and approval | Records and excerpts for the claimed sequence, alternative explanations, limitations, and reviewer decision |
Traceability does not turn every statement into proof. It makes the strength of the proof visible. A participant saying that WhatsApp outreach helped them return is valuable participant-attributed evidence. A record showing that attendance followed the message establishes sequence. Neither alone proves causation. The trail should preserve the evidence and the boundary rather than allowing a fluent report to quietly strengthen the claim.
In short: The Open Play example produces three related but distinct results: an attendance result, a reviewed barrier theme, and a later-attendance sequence. Each needs its own supporting trail and its own claim boundary.
Illustrative continuation based on Marco Botha’s Open Play workflow: Young people enroll in a program, but some do not attend the first session. The team reaches out by WhatsApp to understand why. Financial hardship may appear in reviewed responses, and later records may show that some young people attended after outreach. The Claim-to-Source Trail prevents those observations from collapsing into one exaggerated success story.
The same principle applies to unexpected operational evidence. If the field team discovers a water leak, the report should connect that observation to the dated message, photograph, note, responsible site, action taken, and follow-up status. Do not bury it because it is not a standard indicator. It may explain attendance, cost, safety, or service interruption and can be more decision-useful than an isolated metric.
In short: Do not trace an SROI estimate only to its final ratio. Trace it through the approved portfolio definition, each company’s source documents and conversations, its logic model, agreed outcomes, proxy and evidence source, quantity, likelihood, adjustment assumptions, calculation, and scenario. Treat SROI as an indicative validation number—not the answer and not a replacement for the fund’s financial, operational, and impact thesis.
The supplied transcript and screens in the Sopact walkthrough SROI for Grant Management and Impact Investments demonstrate a governable process for funds whose investments differ by geography, sector, fund, and stage. The distinctive point is that consistency begins before the calculation. A clear portfolio definition and common company record establish the evidence every investment must provide; company-specific documents, conversations, outcomes, and proxies preserve the context that should not be forced into one generic template.
The transcript also makes the role of the organization’s own “taste” concrete. Financial documents, social-audit documents, grant proposals, and the approved investment thesis can be extracted into a fund-specific rubric or knowledge base. That internal thesis sits beside external proxy research. It helps the manager ask not merely, “What is the SROI?” but “Is this investment meeting the outcomes and decision criteria we approved?”
Evidence boundary from the transcript and screens
The supplied transcript and walkthrough show the onboarding transcript field, the governed indicator dictionary, source and verification fields, company comparison, the SROI outcome table, adjustment factors, value drivers, and three scenarios. They support the central claim that the same defined process can be repeated for different companies while each company retains its own outcome evidence and SROI analysis. The video description states that the displayed figures are illustrative estimates built from published proxy sources—not audited values or forecasts of financial return.
The walkthrough does not demonstrate a click from the final report into the raw transcript, permission or redaction controls, or a visible version-history interface. Do not infer those features from the report screens. Treat them as traceability requirements to verify separately.
In short: One global foundation team described traceability as the ability to move from the headline SROI ratio all the way back to the specific benchmark study, outcome quantity, proxy choice, adjustment assumption, calculation, and raw research evidence. Identifying details are withheld, but the review standard is useful for any organization preparing a high-stakes SROI report.
This is a field example from a private Sopact demonstration, not a claim that every funder requires the same format. It is nevertheless a strong acceptance test: when leadership points to any figure, can the report answer where it came from immediately, without the analyst searching across files or reconstructing the logic later?
| Traceability component | What the report must retain | Question it must answer |
|---|---|---|
| Benchmark provenance | Specific study or evidence base, direct source link, geography, population, year, unit, and applicability—not merely a broad repository name | Where did this benchmark come from, and why can it apply here? |
| Proxy ledger | Outcome and quantity, proxy value and unit, proxy source, selection rationale, currency/year adjustments, and responsible reviewer | Why was this financial proxy selected for this outcome? |
| Adjustment logic | Deadweight, attribution, displacement, and drop-off percentage or documented rationale for each valued outcome | What portion would have happened anyway, came from others, shifted harm, or diminished over time? |
| Calculation audit trail | Gross valuation, every adjustment, net annual value, duration and discounting, present value, investment amount, and final ratio | Can another reviewer reproduce the final figure step by step? |
| Sensitivity analysis | Conservative, base, and optimistic assumptions, resulting values, confidence range, and the assumptions that drive the change | How dependent is the result on uncertain choices? |
These five components form an SROI Traceability Pack. The proxy ledger is not an appendix added for appearance. It is the bridge between the outcome evidence and the calculation. The sensitivity analysis is not three decorative numbers. It must reveal which assumptions move the result. Together, the pack lets a reviewer travel backward from the ratio to the evidence and forward from the evidence to the ratio.
In short: Gaps and conflicts belong inside the trail. Never fill them with plausible text, remove the weaker evidence, or overwrite an old release. State what is missing, how the conflict was handled, who decided, and whether the claim was narrowed, withheld, or restated.
| Evidence condition | What the trail should show | Release decision |
|---|---|---|
| Required source is missing | Missing source, owner, expected date, and affected claim | Withhold, label incomplete, or narrow the claim |
| Sources disagree | Both records, source priority rule, reviewer, and rationale | Resolve under policy or report the conflict |
| A late record changes the result | Old and new snapshots, affected record, old and new value, and date | Issue a new release with reconciliation |
| A qualitative interpretation is overridden | AI proposal, reviewed decision, reason, reviewer, and codebook version | Use the approved decision; retain both for audit |
In short: No. Traceability and unrestricted access are not the same. A report can show that a claim has an inspectable trail while applying role-based access, redaction, aggregation, consent, retention, and secure review rules to sensitive source evidence.
Design the trail in layers. A public or funder-facing view may show the definition, method, sample size, limitations, and redacted supporting excerpts. An authorized program or MEL reviewer may inspect the relevant source record. Only people with a legitimate need should reach identifying details. The trail should also record when a source cannot be exposed, why, and what independent review occurred instead.
In short: A general chat tool can summarize the files placed in a conversation, but it does not automatically know the approved definitions, identities, evidence snapshot, query history, coding decisions, source permissions, or release approval. If those links were not preserved during the workflow, fluent prose cannot recreate them reliably.
A prompt that asks for citations may return file names, page references, or plausible-looking links. That is useful for exploration, but it is not an evidence lineage system. The model can also omit conflicting records, cite a passage that does not support the full claim, or strengthen correlation into attribution. The right control is architectural: store meaning, method, evidence, source location, judgment, and approval as the result is created.
In short: Sopact Sense keeps governed context and traceability metadata with the evidence, lets people ask questions in ordinary language, retains the inspectable query behind numeric results, preserves source excerpts and reviewed qualitative metadata, and connects each released result to its snapshot, rules, limitations, and approval.
The AI is useful because it can interpret a question, locate relevant evidence, propose qualitative codes, explain a calculation, and draft a narrative. It does not become the source of truth. The deterministic calculation layer produces governed numeric results. Reliability agents check context, identity, query logic, missing evidence, qualitative review status, attribution limits, and change history. The Claim-to-Source Trail then exposes the retained path in plain language.
People remain responsible for approving definitions, resolving conflicting evidence, reviewing sensitive interpretations, deciding whether the evidence supports attribution, controlling access, and authorizing release. The purpose of advanced AI is not to hide that judgment. It is to make the judgment, evidence, and calculation easier to inspect.
In short: Start a Claim-to-Source Register for the few claims that will enter the next funder or board report. The manual method is workable at small scale and reveals exactly where definitions, evidence, review, or access are weak.
| Released claim | Approved meaning | Method/version | Snapshot and sources | Gap/limitation | Reviewer/release |
|---|---|---|---|---|---|
| Paste exact report statement | Indicator, code, population, period, claim level | Query, formula, codebook, inclusion rules | Dated snapshot, rows, files, excerpts | Missing, conflict, alternative explanation | Name, date, version, status |
Test the register by handing one claim to a colleague who did not prepare the analysis. If they can follow it to the relevant definition, calculation or coding rule, snapshot, source evidence, limitation, and approval without calling the analyst, the trail is working. If not, the problem is visible before the funder finds it.
Preserve the exact released claim, connect it to the approved definition and Evidence Map, retain the calculation or qualitative rule and version, freeze the evidence snapshot used at release, link to the relevant records or excerpts, record gaps and overrides, and show who approved it. Apply access and redaction rules without breaking the lineage.
Reliability means the same approved scope, evidence snapshot, and rule versions reproduce the same released result. Traceability means a reviewer can inspect the path from that result to its meaning, method, sources, judgment, and approval. Reliability answers whether the result will hold when rerun; traceability answers why it should be trusted.
No. A citation identifies a source. An evidence trail also shows how that source was selected, what definition and period applied, which records or excerpts support the claim, what calculation or coding rule was used, how conflicts were handled, and who approved the released interpretation.
Yes. Preserve the theme definition, codebook version, inclusion and exclusion examples, AI-proposed code, reviewed decision, override reason, exact excerpt, source location, participant and program context, contradictory evidence, and review status. A theme count should never be separated from the words and judgments that produced it.
Do not overwrite the prior release. Create a new evidence snapshot and release, preserve the earlier value, identify the changed record or rule, explain the effect, state whether comparisons remain valid, and record who approved the correction. A visible correction strengthens trust more than a silent replacement.
It should not expose identities by default. Use role-based access, aggregation, redaction, consent, retention rules, and secure review. External readers can see the method, limitations, release status, and permitted citations while authorized reviewers inspect sensitive source evidence only when necessary.
They can help organize cited material within the context supplied, but they do not automatically preserve your approved definitions, identities, evidence snapshots, query history, coding decisions, permissions, or approvals. The trail must be designed into the evidence workflow. Otherwise, the model is attempting to reconstruct lineage from whatever files happen to be present.
Use those governed results to design a report for a real funding decision. Chapter 10 starts with the decision a funder, board member, or investment committee must make, then selects the claims, evidence, risks, and narrative that belong in that audience’s brief. Traceability makes the report checkable; decision design makes it useful.
Next: You now have a permission-aware trail from each released claim to its meaning, method, evidence, limitations, and approval. Chapter 10 shows how to use those traceable results in How Do You Design a Report for a Real Funding Decision? →
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.
Build a traceable result →
