Sopact is a technology based social enterprise committed to helping organizations measure impact by directly involving their stakeholders.
Copyright 2015-2026 © sopact. All rights reserved.
a workflow blueprint you own — every outcome mapped to one indicator, every indicator to a store and a wave, graded by what you can prove today, joined by reference keys, and phased so you start collecting against your weakest claim this week.
For: program leads, evaluators, and grant-funded teams who already have a theory of change and now need to prove it.
Why: a theory of change is a set of promises; a workflow is where each promise meets evidence. Without it, the theory stays an argument on a slide — and traditional case management can’t build it for you, because its screens never saw your theory.
Outcome: a workflow blueprint you own — every outcome mapped to one indicator, every indicator to a store and a wave, graded by what you can prove today, joined by reference keys, and phased so you start collecting against your weakest claim this week.
This is Chapter 1 of the Case Intelligence series. In Chapter 0: How to Build a Theory of Change you built and graded a theory of change — a chain from activities to outcomes to impact, each link marked evidenced, unproven, or missing. If you skipped it, build the theory first. Now you turn it into the smallest workflow that actually proves it.
The running example for the whole series is RiseWorks Foundation / Pathways 2027, a youth workforce accelerator whose theory of change is a four-stage chain — Train → Match → Place → Earn — and whose finished workflow spans eight stores joined by reference keys. The funnel those stores describe end to end: 80 enrolled → 62 completed → 58 credentialed → 108 matches (20 strong / 51 partial / 37 not-qualified) → 29 placed. Every chapter after this one lives inside one of the stores you are about to map.
One more thing before we start, and it matters: this article is honest about what you can do yourself with any AI and what needs Sopact Sense. The first two steps — mapping outcomes to indicators, and assigning stores and waves — are pure thinking work; the prompts below run in any chat window today. The last two — keeping evidence grades live as records arrive, and joining stores so one participant reads as one story — are product behavior, because a standalone prompt has no store, receives no records, and never sees another wave. Each step is tagged [DIY] or [SENSE] so you always know which side of that line you’re on.
A workflow is not a project plan and it is not a case-management screen. A workflow is the answer to one question, repeated for every arrow in your theory of change:
“What would prove this arrow, and where does that evidence get collected?”
That is the whole idea. Your theory of change is a diagram of claims — “training builds confidence,” “confidence plus a credential leads to a living-wage job.” Every one of those claims needs a single, named place where the evidence for it lands. Map each claim to that place and you have a workflow — there is nothing else to invent. The theory already drew the shape; the workflow assigns a store to every node and every arrow.
This is the opposite of how traditional case-management software works. It hands you a rigid, pre-defined workflow — intake form, service log, case notes, discharge — and you conform your program to its screens. Its analytics then describe delivery: sessions held, contacts logged, cases closed. None of it ties to your theory of change, because the software never saw your theory of change.
Sopact Sense · Case Intelligence works the other way around, and the difference is concrete in three places. Analysis happens on arrival, not after a collect-then-clean cycle: an Intelligent Cell scores or extracts each field the moment a record lands, so evidence grades update the day data arrives. The workflow is adaptive, not rigid: tune a scoring instruction on the first 5–10 records and everything already collected re-scores against the new standard. And centralization actually works: stores stay separate but join by reference keys — email, employer_name, requisition_id — so one participant’s intake, mid, exit, and follow-up line up as one story instead of four exports that never reconcile. Steps 3 and 4 show all three at work.
Before the steps, fix the vocabulary, because every later chapter uses it.
A store is a named place where one kind of record lands — one instrument, one table, one owner. RiseWorks’ finished workflow has eight: Application/Intake, Mid-Program, Exit/Completion, Mentor Weekly Notes, Six-Month Follow-up, Employer Accounts, Job Requisitions, and Placements. Eight is where it ends; it starts with one.
A wave is the moment a store fires: application, intake/pre, mid, exit/post, recurring (weekly mentor notes), or follow-up. A pre/post claim needs the same indicator captured at two waves on the same scale.
A reference key is the field that carries a record across stores without merging them: email for a participant, employer_name for a partner, requisition_id for a job opening.
Indicator → store → wave → key. That is the entire anatomy; the four steps below fill it in.
What you do. Take each outcome in your graded theory of change and answer one question: what single piece of evidence would prove this arrow is real? Not five measures — one. Fix its scale permanently, and grade it mechanically: EVIDENCED only when you can quote a figure that already exists, UNPROVEN when the claim is made but nothing backs it yet, MISSING when there is no indicator at all.
What you get. A short list pairing every outcome with exactly one indicator, a fixed scale, and an honest grade.
Why it matters. An outcome without an indicator is a hope. One indicator per outcome keeps the workflow small, stops you collecting fields nobody will analyze, and surfaces — now, not at the funder report — which promises you cannot back up.
Real example — RiseWorks. Here is the indicator map its theory of change produced:
Read the Grade column with the timeline in mind. The EVIDENCED rows are what the finished workflow eventually proved; on the day RiseWorks ran this exercise, the confidence rows had no baseline and the wage rows had no follow-up. The grades are supposed to look bad at kickoff — that is the map telling you where to build.
Notice what the one-indicator discipline does here. RiseWorks could have measured confidence a dozen ways — a psychometric scale, a coach’s rating, a peer review. Instead it committed to one 1–10 self-rating asked identically at three waves, which is what makes the 4.3 → 7.1 → 7.4 line legible: same question, same scale, three points in time, one story. A busier instrument would have produced more data and less proof. And when an outcome cannot be reduced to one defensible indicator — RiseWorks’ “reduced regional talent gap” — the honest move is to grade it MISSING and leave it out of the first workflow rather than fake it. The confidence to say “missing” keeps the rest of the map trustworthy.
Prompt 1: Indicator Mapper
You are an evaluation designer. Your job is to turn a theory of
change into an indicator map: for every outcome, exactly one
indicator, one fixed scale, and one mechanical evidence grade.
TASK
For each outcome in the theory of change I paste below:
1. Name EXACTLY ONE indicator — the single piece of evidence that
would prove the arrow into that outcome is real. Never two.
If no single defensible indicator exists, write "none yet" and
grade the row MISSING.
2. Fix the SCALE the indicator is measured on (e.g. 1-10
self-rating, $/hr, Y/N, fixed category set). The scale is
permanent — every later wave that re-asks this indicator must
use the identical scale and wording.
3. Grade the row using ONLY these three grades, applied
mechanically:
- EVIDENCED : I supplied a quotable figure or fact in my data
summary that already backs this indicator. Quote it in the
grade column.
- UNPROVEN : the outcome is claimed and an indicator can be
named, but nothing in my data summary backs it yet.
- MISSING : no defensible indicator exists for this outcome.
INPUTS (paste between the markers)
<<<
THEORY OF CHANGE (outcomes and arrows, as built in Chapter 0):
[paste yours here]
WHAT I ALREADY COLLECT (surveys, spreadsheets, systems — with any
real figures you can quote):
[paste yours here]
>>>
OUTPUT FORMAT
One markdown table, one row per outcome, exactly these columns:
Outcome | The one indicator | Scale | Grade (with quoted backing
figure if EVIDENCED)
After the table, two lists:
- UNPROVEN arrows, each with one line on what evidence would move
it to EVIDENCED.
- MISSING arrows, each with one line saying the claim should not
be made publicly until an indicator exists.
RULES
- One indicator per outcome. If I push for more, refuse and
explain that a busier instrument produces more data and less
proof.
- Grade EVIDENCED only when a quotable figure or fact appears in
my inputs. Never infer or estimate a figure. Never invent data.
- Grade UNPROVEN whenever the claim exists without backing.
Grade MISSING whenever no indicator can be named.
- Use only the outcomes I pasted. Do not add outcomes, merge
outcomes, or rename them.
- The same input must give the same output every run. No
creativity in the grades — they follow the rules above
mechanically.
What you do. For every indicator from Step 1, decide where it gets collected (the store) and when (the wave), and name the stakeholder who provides it — participant, mentor, employer, or staff. Write it down as one mapping table.
What you get. The mapping table — the spine of your workflow. One row per indicator: Outcome | Indicator | Store | Wave | Stakeholder | Evidence.
Why it matters. This is where a theory of change becomes operational: once every indicator has a store and a wave, you know exactly which instruments to build and when they fire. It also prevents the classic failure — collecting the same thing in three places, or a mid measure with no baseline to compare against.
Real example — RiseWorks.
Read the table as a build list, not a report. Every row that shares a store and a stakeholder can be collected in one instrument — the three confidence rows plus the credential row are not four forms, they are fields on the Application/Intake, Mid-Program, and Exit instruments a participant already fills. Rows on different stores fire at different moments for different stakeholders: match tier on the employer side, mentor notes weekly, the wage row six months out. The two UNPROVEN rows and the one MISSING row are exactly the arrows your current data cannot defend — Step 3 turns that into a build order.
Prompt 2: Store & Wave Mapper
You are a data-collection architect. Your job is to assign every
indicator in my indicator map to a store (the named place it is
collected) and a wave (the moment it is collected), producing the
mapping table that is the spine of my workflow.
TASK
For each indicator in the map I paste below:
1. Assign a STORE — the single named place the data lands. Use
store names that fit my program; typical stores are:
Application/Intake, Mid-Program, Exit/Completion, Mentor Notes
(recurring), Follow-up, Employer Accounts, Job Requisitions,
Placements. Rename to fit; do not invent stores my program
would never run.
2. Assign a WAVE — when the store fires: application, intake/pre,
mid, exit/post, recurring (e.g. weekly mentor notes), or
follow-up.
3. Name the STAKEHOLDER who provides the data: participant,
mentor, employer, or staff.
4. Carry the evidence grade (EVIDENCED / UNPROVEN / MISSING)
forward from my indicator map unchanged. Do not re-grade.
INPUTS (paste between the markers)
<<<
INDICATOR MAP (the Prompt 1 output table):
[paste it here]
HOW THE PROGRAM ACTUALLY RUNS (touchpoints with participants,
mentors, employers — when you see each stakeholder and how):
[paste yours here]
>>>
OUTPUT FORMAT
One markdown table, exactly these columns:
Outcome | Indicator | Store | Wave | Stakeholder | Evidence
After the table:
- ORPHAN CHECK: list every mid, exit/post, or follow-up indicator
that has NO matching pre/baseline row on the same scale in an
earlier wave. Each orphan gets one line: which earlier wave must
ask it, on which scale.
- DUPLICATE CHECK: list any indicator collected in more than one
store that is NOT an intentional pre/post pair, with the row to
delete.
- BUILD LIST: group the rows by store, so each store reads as the
field list of one instrument.
RULES
- A pre/post indicator appears in exactly the waves that compare
it, on the identical scale and wording. Flag scale drift as an
orphan — a 1-5 at intake re-asked as 0-100 at exit is not a
pair.
- One store per row. Never assign an indicator to two stores
outside a pre/post pair.
- Use only the indicators I pasted. Do not add, merge, or rename
indicators. Do not change any grade.
- The same input must give the same output every run. The checks
are mechanical, not judgment calls.
Before the two SENSE steps, look at what actually lands in a store — the workflow you mapped is abstract until the first record makes it concrete. Applicant RW2-003, Aaliyah Johnson, 39, applying to the IT & Cybersecurity track, arriving in RiseWorks’ first store in its first week:
email — (her persistent ID — the key every later wave joins on)
Context: employed low-wage at $15.20/hour · first-generation
Baseline measures: baseline_confidence_1to10 — 5.4 · baseline_skill_self_rating_1to5 — 3
intake_goal_openended — “land a help-desk role and work up to SOC analyst — so I never have to ask anyone for help again”
barriers_openended — “I don’t have a car, so getting out to Huntsville on time is the thing I lose sleep over”
Every field earns its place in the Step 2 table: the 5.4 is the pre half of the confidence pair, the wage is the before-number for the living-wage claim, the open answers are the evidence behind both. In traditional CM this record would now wait — text boxes unread until a coding sprint, the confidence number in a file nothing else joins to. What happens instead is the next two steps.
From here on, this is product output, not a prompt you run. A chat prompt can recommend a build order — but it cannot keep your evidence grades current, because it has no store and receives no records. Sense does, and that liveness is precisely what makes starting small safe.
The start-small decision. Do not build all eight stores. Look at your mapping table, find the arrow that is UNPROVEN or MISSING but most central to your theory — the one you could least defend to a funder — and build the ONE store that would move it to EVIDENCED. For RiseWorks, the weakest central arrows at kickoff were the confidence and readiness claims: the whole program rests on “training builds job-ready confidence,” and there was no baseline at all. So the first store built was Application/Intake — application review plus an intake baseline. The phased roadmap that followed, ordered by evidence gap rather than org chart: Mid-Program → Exit/Completion → Mentor Weekly Notes → Six-Month Follow-up → then the demand side: Employer Accounts, Job Requisitions, Placements. RiseWorks did not build Employer Accounts first even though the development team wanted employer relationships in the system on day one — those arrows were not the claims it had to defend to renew its funding.
What the product does the day the store opens. The moment Aaliyah’s record lands, an Intelligent Cell on each field goes to work: her barriers_openended text is classified (transport — “I don’t have a car… Huntsville”), her goal text is tagged to a theme (role-specific ambition), and her baseline confidence 5.4 is recorded on the 1–10 scale that mid and exit will re-ask. An Intelligent Row then assembles her fields into one per-record profile a human can read in thirty seconds. No coding backlog forms, ever — record #1 and record #80 arrive equally structured.
Why that makes the grades live. The evidence grade on “training builds job-ready confidence” stops being an annual judgment call and becomes a running fact: the week the store starts collecting, the baseline half of the pair exists, and you watch the arrow move from MISSING toward EVIDENCED. When RiseWorks adjusted a Cell’s classification instruction after its first handful of records, everything already collected re-scored against the new standard automatically — the adaptive loop that rigid CM cannot run, because its screens are fixed at implementation time. Starting small stops being a risk when you can see, within days, whether the store you built is closing the gap it was built for.
Prompt 3 — First Store, Scored on Arrival
THE START-SMALL DECISION (made from the Prompt 2 mapping table)
First store: Application/Intake — application review plus the
intake baseline. Why: RiseWorks' weakest central arrows at
kickoff were the confidence and readiness claims. The whole
program rests on "training builds job-ready confidence," and
there was no baseline; without the 4.3 at intake, the later
7.1 -> 7.4 rise could never be proven.
Phased roadmap, ordered by evidence gap (not org chart):
1. Application/Intake <- build now
2. Mid-Program
3. Exit/Completion
4. Mentor Weekly Notes
5. Six-Month Follow-up
6. Employer Accounts <- demand side, after the core
7. Job Requisitions chain is evidenced
8. Placements
----------------------------------------------------------------
INTELLIGENT CELL CONFIGURATION (Application/Intake store)
Cell 1 — sits on field: barriers_openended
Instruction text:
"Classify the primary barrier named in this answer into exactly
one of: Transport, Childcare, Financial, Housing, Health,
Legal/Justice, None stated. If more than one barrier appears,
the primary is the one the applicant gives the most specific
detail about; list the rest as secondary. Quote the applicant's
exact words for every classification. Never infer a barrier
that is not stated."
Cell 2 — sits on field: intake_goal_openended
Instruction text:
"Classify the goal into exactly one of: Specific role named,
General employment, Wage/financial stability, Skill/credential
only, Unclear. Quote the phrase that justifies the class."
Cell 3 — sits on field: baseline_confidence_1to10
Instruction text:
"Record the value on the fixed 1-10 scale. Flag if out of range
or missing. This is the pre half of the confidence pair; Mid
and Exit re-ask the identical question."
INTELLIGENT ROW — assembly spec
For each record, assemble: persistent ID (email) · track ·
baseline confidence (1-10) · baseline wage · Cell 1 barrier
classification with quote · Cell 2 goal class with quote ·
fields still missing. One per-record profile, readable in
thirty seconds.
----------------------------------------------------------------
SAMPLE RETURN — real record, on arrival
INTELLIGENT ROW — RW2-003 · Aaliyah Johnson · IT & Cybersecurity
Persistent ID : email (carries her to mid, exit, follow-up)
Baseline conf. : 5.4 / 10 (pre wave of the 1-10 pair)
Wage at intake : $15.20/hr (employed low-wage) · first-gen
Skill self-rating: 3 / 5
Barrier (Cell 1) : Transport — "I don't have a car, so getting
out to Huntsville on time is the thing I
lose sleep over"
Goal (Cell 2) : Specific role named — "land a help-desk role
and work up to SOC analyst"
----------------------------------------------------------------
WHY THIS IS THE LIVENESS STEP
The moment this store opens, the evidence grade on "training
builds job-ready confidence" becomes a running fact instead of an
annual judgment call: every arriving record adds a baseline, and
the arrow visibly moves from MISSING toward EVIDENCED. Tune any
Cell's instruction on the first 5-10 records and everything
already collected re-scores against the new standard — record #1
and record #80 end up judged identically.
The second thing a standalone prompt cannot do: reconcile records it never received, across waves it never saw. Joining is product behavior — you declare the reference keys, Sense carries them, and the Sopact Assistant (with the Claude MCP connection) answers cross-store questions in plain language.
What you declare. Three keys, each with a specific job:
What the joins pay for. Because email carries each participant across five waves, the Assistant can put the before and after on one line: confidence 4.3 → 7.1 → 7.4 across intake, mid, and exit — same people, same scale; median wage $9.96 → $25.11 from intake to six-month follow-up; 82% of completers employed at follow-up versus 45% of non-completers. Aaliyah’s 5.4 baseline is already waiting to reconcile with her mid and exit answers the moment they arrive. None of that is analysis heroics; all of it is a query over joined stores.
The diagnosis rigid CM can never make. The demand-side keys are what let RiseWorks name its gap precisely instead of blaming training: the Assistant lined up the 108 matches against open requisitions and saw 25 requisitions unfilled — citizen-only requirements and CDL hard fails — while 29 qualified candidates went unplaced. That is a matching and eligibility constraint, not a curriculum failure. Traditional CM, with employers and participants in separate modules and no shared key, could only report “29 placed, 25 open” as two unrelated counts. The join turns two counts into one diagnosis.
Prompt 4 — Join & Interrogate
THE JOINS YOU DECLARE FIRST
email joins Application/Intake, Mid-Program,
Exit/Completion, Mentor Weekly Notes,
Six-Month Follow-up
(one participant, five waves, one story)
employer_name joins Employer Accounts, Job Requisitions
requisition_id joins Job Requisitions, Placements
Keep stores separate; join by key. Never flatten waves into one
mega-form.
----------------------------------------------------------------
ASSISTANT PROMPT A — join audit
"Audit the joins across my stores. For each reference key
(email, employer_name, requisition_id): which stores does it
join, how many records in each store are missing the key, and
which specific analyses become impossible for those records?
List the orphaned records by store."
What it returns (RiseWorks): the key coverage per store, plus
the failure modes in plain language — e.g. a participant with no
email cannot be traced from intake confidence to follow-up wage;
the two live in separate files and never reconcile.
----------------------------------------------------------------
ASSISTANT PROMPT B — the cross-wave story
"Across the joined participant stores, show the pre/mid/post
confidence line on the same 1-10 scale, the wage change from
intake to six-month follow-up, and employment at follow-up
split by completers versus non-completers."
What it returns (RiseWorks, real numbers):
Confidence : 4.3 -> 7.1 -> 7.4 (intake / mid / exit,
same people, same scale)
Median wage: $9.96 -> $25.11 (intake -> six-month
follow-up)
Employment : 82% completers vs 45% non-completers
----------------------------------------------------------------
ASSISTANT PROMPT C — supply vs demand
"Line up the match results against open requisitions. How many
requisitions remain unfilled, what disqualifies our candidates
from them, and how many qualified candidates remain unplaced?"
What it returns (RiseWorks, real numbers):
108 matches (20 strong / 51 partial / 37 not-qualified),
29 placed. 25 requisitions unfilled — citizen-only
requirements and CDL hard fails — against 29 surplus
candidates. A matching and eligibility constraint, not a
curriculum failure: the join turns two counts into one
diagnosis.
----------------------------------------------------------------
WHY A CHAT PROMPT CANNOT DO THIS
Each answer above spans multiple stores and multiple waves,
joined by keys carried on every record. A prompt pasted into a
chat window has none of that: no store, no waves, no keys, no
other records. This is the line between the [DIY] steps (design
work any AI can do) and the [SENSE] steps (product behavior over
your data).
Collecting fields no arrow needs. If a field does not prove an outcome or an arrow in your theory of change, it is not part of the workflow — it is clutter that lowers response rates. Cut it. Every field should trace to a row in your Step 2 table.
Measuring mid or exit with no baseline. A 7.4 confidence score means nothing without the 4.3 it started from. If you collect a mid or post measure, the matching pre measure must exist in an earlier wave, on the same scale, joined by the same key. Baselines are the most common thing teams forget and the most expensive to reconstruct later.
Building the big form first. The instinct to launch one comprehensive intake-through-follow-up system at once is how workflows die in committee. Start with the single store that proves your weakest arrow, get real scored data in days, and let each phase earn the next.
Merging stores instead of joining them. Flattening every wave into one giant table destroys the ability to trace one record across time. Keep stores separate; join by reference key. A missing key, not a missing field, is what silently breaks reconciliation.
Confusing delivery metrics for impact. “Sessions delivered” and “cases closed” describe activity, not change. They cost nothing to collect and prove nothing about your theory of change. Let the theory decide what counts as evidence, and grade honestly when the answer is “we can’t prove this yet.”
A workflow blueprint you own: every outcome in your theory of change mapped to one indicator, every indicator to a single store and wave, graded by what you can prove today, joined by reference keys, and phased so you can start with one store this week. It is not a form the software imposed on you — it is your theory of change made collectable, and it starts returning evidence the week the first store goes live.
Because the workflow is derived from your theory of change, every field you collect earns its place by proving an arrow. Because Intelligent Cell scores each record on arrival, the evidence grades are continuous, not a year-end scramble — and tuning an instrument re-scores everything already collected. Because stores join by reference key, one participant is one story across every wave, and supply can be lined up against demand. RiseWorks turned this into numbers a funder can check: SROI ≈ 2.44:1, cost-per-outcome ≈ $20,076, and a supply/demand gap it could name precisely instead of guessing at. The skeptic’s one-liner: one indicator per outcome, one store per indicator, one key per record — and the grade updates the day data lands.
Run Prompt 1 against your theory of change and count the grades: for every outcome, one indicator, one scale, one honest EVIDENCED / UNPROVEN / MISSING. The count of UNPROVENs tells you what the first store must prove; the MISSINGs tell you which promises to stop making until you can. It takes under an hour, and it converts your theory of change from an argument into a build list.
A screen-by-screen walkthrough — grading the RiseWorks theory of change, standing up the Application/Intake store, watching Aaliyah’s record score on arrival, and wiring the three joins — is in production. Check back on the Academy.
Program leads who have a theory of change and no idea which form to build first. Evaluators tired of reconciling exports by hand. Grant-funded teams who need to show a funder that their outcomes are backed by evidence, not adjectives. If you have promises on a slide and data in five disconnected files, this is the bridge.
Turn your theory of change into a live workflow in Sopact Sense — sopact.com/academy.
Next in the series: How to Review Applications Without Reviewer Bias — the Application/Intake store you picked first gets its rubric, and every application is scored on arrival against it.
Open Sopact Sense, paste your program description, and put it to work.
Try in Sopact