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 baseline mapped to your theory-of-change outcomes, structured on arrival, stamped with a persistent ID — so intake → mid → exit → follow-up reconcile automatically and the pre/post story writes itself.
For: program leads and evaluators who collect intake data and still can’t prove change at the end of the program.
Why: traditional case management captures intake demographics and a pile of free text, codes it weeks later — and can never prove change, because there is no comparable “before” number on the same scale as any later wave.
Outcome: a baseline mapped to your theory-of-change outcomes, structured on arrival, stamped with a persistent ID — so intake → mid → exit → follow-up reconcile automatically and the pre/post story writes itself.
This is Chapter 3 of the Case Intelligence series — the pre wave. In Chapter 2 you built the application store and learned to score every application on arrival against one rubric. This article is about what that store should also be doing: capturing the before-numbers that make change provable later.
The running example stays the same: RiseWorks Foundation / Pathways 2027 (Train → Match → Place → Earn), whose intake baseline is what later makes these numbers possible: confidence 4.3 → 7.1 → 7.4 across intake, mid, and exit; median wage $9.96 → $25.11 by six-month follow-up; 82% vs 45% employment for completers versus non-completers.
As in Chapter 2, every step is tagged [DIY] or [SENSE]: designing the baseline and the form is thinking work you can do in any AI today; classifying the free text on arrival and auditing the pre/post pairs across waves is what the product does over the store.
Here is the test: a baseline is usable if, for every outcome you promised, there is a “before” number on the same scale as a “later” number, joined by the same ID. Everything else on the intake form is context.
That test fails in traditional case management for a predictable reason. CM intake is built to register people — demographics, eligibility, program assignment — plus a couple of open text boxes that go unread until someone hand-codes them weeks later. It captures a lot and proves nothing, because none of it was designed as the “before” half of a pair. When the funder asks “did confidence improve?”, the honest answer is: compared to what? There is no 4.3, so the 7.4 at exit is just a number floating alone.
The distinction to hold onto:
Demographics describe the person. Age, gender, education, income band, justice involvement, dependents. You collect them once, for segmentation and equity analysis — RiseWorks’ pool is ~22% justice-involved and ~55% first-generation, and you want to know whether outcomes differ across those groups.
The baseline measures the outcome, before. Confidence 1–10. Current hourly wage. Receives public assistance Y/N. Each one exists because an outcome in the theory of change needs a before-number, and each one will be re-asked at a named later wave on the identical scale.
And two conditions make the pair machinery work at all: (1) every baseline measure has a matching later wave on the same scale, and (2) every record carries a persistent ID — email — so the intake row and the exit row are provably the same person. Miss either one and your intake is a registration form, not a baseline.
What you do. Take each outcome in your theory of change and ask one question: what is the before-number for this? Then fix the scale — permanently — and name the later wave that will re-ask it.
Real example — RiseWorks. Its short-term outcome, “participants gain job-ready confidence,” maps to baseline_confidence_1to10 — confidence self-rated 1–10 at intake. The pool’s mean at intake: 4.3. Because the identical 1–10 question reappears at mid and exit, the program can later write the only sentence funders actually check: confidence rose 4.3 → 7.1 → 7.4 on the same scale, same wording, same people.
Its medium-term outcome, “participants earn a living wage,” maps to baseline_hourly_wage (pool median at intake: $9.96) plus receives_public_assistance as the poverty-context companion. The wage question reappears at six-month follow-up — which is what makes $9.96 → $25.11 a provable change rather than a happy anecdote.
Then the open text that explains the numbers — exactly two questions, both real RiseWorks fields: barriers_openended (“What might get in your way?”) and intake_goal_openended (“What do you want out of this program?”). These aren’t decoration. They’re what Intelligent Cell classifies on arrival, and they’re why a 4.3 confidence score comes with a reason attached.
The discipline: one measure per outcome, scale fixed forever, later wave named at design time. A measure with no later wave gets flagged now — not discovered at report time.
Prompt 1: Baseline Designer
PROMPT 1 — BASELINE DESIGNER [DIY]
Chapter 3 of the Case Intelligence series · How to Design an Intake Form That Captures a Usable Baseline
Copy-paste this into any capable AI — Claude, ChatGPT, or the Sopact Sense Assistant.
Purpose: from your theory of change, decide which outcomes need a "before"
number, on what scale, matched to which later wave.
------------------------------------------------------------
You are a baseline designer. Your job is to turn the theory of change I
paste below into a set of usable baseline measures.
THE TEST YOU ARE ENFORCING
A baseline is usable if, for every outcome promised, there is a "before"
number on the same scale as a "later" number, joined by the same
persistent ID. Everything else on an intake form is context.
TASK
For every outcome in the theory of change:
1. Ask: what is the BEFORE number that would let this program prove the
outcome changed?
2. Propose ONE baseline measure and fix its SCALE permanently
(e.g. confidence 1–10; hourly wage $/hr; receives public assistance
Y/N). One measure per outcome — resist adding more.
3. Name the LATER WAVE that will re-ask it on the identical scale, same
wording (mid / exit / follow-up). A baseline measure with no later
wave is a dead field — say so explicitly.
4. Mark any outcome that has no sensible before-number. Mark it, do not
invent one.
5. Add the open text that will explain the numbers — at most two
questions: a barriers question ("What might get in your way?") and a
goal question ("What do you want out of this program?").
RULES (deterministic — do not soften them)
- Verdict categories are fixed: PAIRED (later wave named, same scale),
FLAGGED (no later wave, or scale differs), NO-BASELINE (outcome has no
sensible before-number).
- The scale fixed at intake is a contract with every future wave. Never
propose "roughly comparable" scales.
- Every measure must be joinable to its later wave by a persistent ID
(email). Say so in the output.
- Do not invent outcomes, measures, or waves the theory of change does
not support. The same input must give the same output every run.
OUTPUT FORMAT
A table: Outcome | Baseline measure + scale | Later wave (same scale) |
Verdict | Note — followed by the two open-text questions and the
persistent-ID line.
WORKED EXAMPLE (RiseWorks Foundation / Pathways 2027)
Short-term outcome "participants gain job-ready confidence" →
baseline_confidence_1to10, self-rated 1–10 at intake (pool mean 4.3),
re-asked identically at mid and exit — which is what later lets the
program write: confidence rose 4.3 → 7.1 → 7.4 on the same scale, same
wording, same people. Medium-term outcome "participants earn a living
wage" → baseline_hourly_wage (pool median $9.96) plus
receives_public_assistance Y/N as poverty context, re-asked at six-month
follow-up — which is what makes $9.96 → $25.11 a provable change rather
than a happy anecdote. Open text: barriers_openended and
intake_goal_openended. The audit in Prompt 4 flags the one that got away:
baseline_skill_self_rating_1to5 has no same-scale partner at exit.
------------------------------------------------------------
PASTE YOUR THEORY OF CHANGE BETWEEN THE MARKERS, THEN RUN.
<<<
[your theory of change — outcomes list, logic model, or narrative]
>>>
Here is the move most programs miss: you already collected the baseline — at admission.
The Chapter 2 application form (Form B, structured qualitative) asked for confidence 1–10, current wage, barriers, and goal — because the admission rubric needed them to score Need and Readiness. Those are the same fields the baseline needs. So don’t build a separate intake survey that asks the same questions a second time. Reuse the application store: stamp it as the pre wave, and your baseline is captured the moment an applicant is admitted. “Pre” is free.
This is one form doing two jobs on arrival: the admission rubric reads the fields to score the applicant (Chapter 2), and the baseline stores the same fields as before-numbers for every later wave (this article). One submission, one persistent ID, two uses — and zero duplicate burden on the participant, who never types their wage twice.
When does a separate intake wave earn its place? Only for what admission genuinely can’t capture: measures that only exist post-acceptance (cohort assignment, training site, start-date logistics) or baselines you deliberately don’t want influencing admission. Everything else: reuse, don’t re-ask. If you’re improving an existing intake survey rather than starting fresh, the same rule applies — keep the fields that map to outcomes, mark them REUSED, and cut the rest.
Prompt 2: Intake Form Builder
PROMPT 2 — INTAKE FORM BUILDER [DIY]
Chapter 3 of the Case Intelligence series · How to Design an Intake Form That Captures a Usable Baseline
Copy-paste this into any capable AI — Claude, ChatGPT, or the Sopact Sense Assistant.
Purpose: turn your baseline measures into a three-block intake form —
reusing your application form so "pre" costs zero extra burden.
------------------------------------------------------------
You are building an intake form from baseline measures. Every field must
earn its place.
TASK
Build the form in three blocks:
1. DEMOGRAPHICS — context only: age, gender, education, income band,
justice involvement, dependents. Label each clearly as a non-outcome
field, collected once for segmentation and equity analysis.
2. BASELINE MEASURES — the before-numbers from my baseline table, each on
the exact scale its later wave will re-use, each labeled with the
outcome it maps to and the wave that re-asks it.
3. OPEN TEXT — exactly two questions: barriers ("What might get in your
way?") and goal ("What do you want out of this program?"). These are
what gets classified on arrival; they are why a low confidence score
arrives with a reason attached.
Then apply the reuse rule: compare the form against my existing
application form and mark every field REUSED (already asked at
application — do not ask again; stamp the application store as the pre
wave) or NEW (only what admission genuinely cannot capture: cohort
assignment, training site, start-date logistics, or baselines you
deliberately keep out of admission decisions).
RULES (deterministic — do not soften them)
- The persistent ID (email) is the FIRST required field, validated.
Without it the record can never reconcile with a later wave.
- Field statuses are fixed: REUSED / NEW / CONTEXT-ONLY / CUT. A field
that maps to no outcome and no later wave is CUT or CONTEXT-ONLY —
never quietly kept.
- Never re-ask a question the application already asked. Duplicate
questions cost completion rate and invite inconsistency ($14/hr on the
application, $15/hr at intake — which is the baseline?).
- Scales are copied exactly from the baseline table. No drift.
- The same input must give the same output every run. Do not invent
fields.
OUTPUT FORMAT
A field list: Field | Type/scale | Maps to outcome | Later wave | Status
(REUSED / NEW / CONTEXT-ONLY / CUT) — with the persistent-ID line first.
WORKED EXAMPLE (RiseWorks Foundation / Pathways 2027)
RiseWorks did not build a separate intake survey. Its Chapter 2
application form (Form B, structured qualitative) already asked for
confidence 1–10, current wage, barriers, and goal — because the admission
rubric needed them to score Need and Readiness. Those are the same fields
the baseline needs, so the application store is stamped as the pre wave:
one submission, one persistent ID, two uses — the admission rubric reads
the fields to score the applicant, the baseline stores them as
before-numbers. A sample of what arrives: RW2-004, Javier Brooks, 23,
IT & Cybersecurity, Birmingham 2024-Q3 — email as the persistent ID,
baseline_confidence_1to10 3.6, baseline_hourly_wage $12.69,
intake_goal_openended "support my kids without working two jobs",
barriers_openended "My Corolla finally died and the Birmingham bus only
runs twice a day; my youngest just turned 3 and daycare runs $180 a week
I don't have."
------------------------------------------------------------
PASTE YOUR INPUTS BETWEEN THE MARKERS, THEN RUN.
<<<
BASELINE MEASURES (from Prompt 1):
[paste Prompt 1 output]
EXISTING APPLICATION OR INTAKE FORM (for the reuse check):
[paste your current form's fields]
>>>
One real applicant, exactly as the fields arrive — RW2-004, Javier Brooks, 23, IT & Cybersecurity track, Birmingham cohort 2024-Q3:
email — javier.brooks86@yahoo.com (the persistent ID)
Demographics & context: age 23 · Hispanic or Latino · high school diploma · unemployed · household income <$15k · receives_public_assistance No · has_dependents Yes · justice_involved No · referral: reentry program
Baseline measures: baseline_confidence_1to10 — 3.6 · baseline_hourly_wage — $12.69 (last job) · baseline_skill_self_rating_1to5 — 3
intake_goal_openended — “support my kids without working two jobs”
barriers_openended — “My Corolla finally died and the Birmingham bus only runs twice a day; my youngest just turned 3 and daycare runs $180 a week I don’t have”
Read that barrier answer the way a case manager would have to: it’s compositional — transport (“Corolla died,” “bus runs twice a day”) tangled with childcare (“youngest just turned 3,” “daycare $180 a week”) tangled with financial (“I don’t have”). In a traditional CM system, this sentence sits in a text box until someone codes it, weeks after Javier either got support or quietly stopped showing up. RiseWorks’ intake has 80 of these, 72% of them unique compositions like this one.
From here, this is product output, not a prompt you run. An Intelligent Cell on barriers_openended classifies the primary barrier the moment the record lands; a second Cell sets a readiness flag; and an Intelligent Row assembles the Candidate Intake Profile. Here is Javier’s, as Sense produces it on arrival:
INTELLIGENT ROW — Candidate Intake Profile · RW2-004 · Javier Brooks · IT & Cybersecurity · 2024-Q3 Birmingham
Notice what arrived structured, with zero coding backlog: the compositional barrier text became a taxonomy (transport primary, childcare and financial secondary), each classification pinned to Javier’s exact words — evidence, not inference. The readiness flag routes supports before the first session, not after the first missed one; a transport barrier discovered in week 6 is a dropout, the same barrier discovered on arrival is a bus pass. And the whole profile hangs on javier.brooks86@yahoo.com, waiting to reconcile with his mid and exit waves automatically.
Same setup tip as Chapter 2, and it matters even more here: in the store’s table view, move the Intelligent Cell and Row columns to the front — readiness flag, primary barrier, profile first; raw text after. Intake staff triage the cohort from the leftmost columns.
Prompt 3 — Barrier Classifier on Arrival
PROMPT 3 — BARRIER CLASSIFIER ON ARRIVAL [SENSE]
Chapter 3 of the Case Intelligence series · How to Design an Intake Form That Captures a Usable Baseline
This is product configuration — it runs on arrival in Sopact Sense, not in a chat window.
A chat prompt classifies the one record you paste; this fires on every
intake record as it lands, so supports route before day one — not after
a coder reads the text weeks later.
------------------------------------------------------------
WHERE IT SITS
Cell 1 on barriers_openended → classifies the primary (and any
secondary) barrier
Cell 2 across the record → sets the readiness flag and the
supports needed before day one
Cell 3 on intake_goal_openended → classifies the goal into a theme
(re-read at exit for goal attainment)
CELL INSTRUCTION (the text Cell 1 runs)
Read the barrier text exactly as written. Classify the PRIMARY barrier
into the fixed set — transport / childcare / financial / housing /
health / justice-involved / other — and any SECONDARY barriers present.
Pin every classification to the applicant's exact words; a
classification with no quote is not allowed. Barrier text is often
compositional (transport tangled with childcare tangled with financial)
— classify each strand, do not average them. Do not invent barriers the
text does not contain. The same text must classify the same way every
run.
ROW ASSEMBLY (the Candidate Intake Profile spec)
Assemble the per-record profile: readiness flag (READY /
READY-WITH-SUPPORTS / NOT-READY) with the supports needed before day
one · primary and secondary barriers, each with its quote · the
baseline snapshot — every numeric baseline on the exact scale its later
wave will re-use, with that wave named · the classified goal. Hang the
whole profile on the persistent ID (email) so it reconciles with mid
and exit automatically.
WHAT IT RETURNS — real record, as Sense produces it on arrival
INTELLIGENT ROW — Candidate Intake Profile · RW2-004 · Javier Brooks ·
IT & Cybersecurity · 2024-Q3 Birmingham
Readiness flag: READY-WITH-SUPPORTS
Primary barrier: Transport — "My Corolla finally died and the
Birmingham bus only runs twice a day"
Secondary: Childcare — "daycare runs $180 a week I don't have" ·
Financial — income <$15k, unemployed
Supports needed: transport assistance to Birmingham site + childcare
subsidy referral, BEFORE day one
Baseline snapshot:
Confidence 3.6 (1–10) — re-asked at Mid and Exit, same scale
Hourly wage $12.69 ($/hr) — re-asked at six-month follow-up
Skill self-rating 3 (1–5) — flagged: see the Prompt 4 gap check
Goal (classified): wage stability for family — "support my kids
without working two jobs" — re-read at Exit (goal attainment)
WHY THIS NEEDS SENSE
Classification must happen on arrival, consistently, for every incoming
record — RiseWorks' intake has 80 of these barrier answers, 72% of them
unique compositions. A transport barrier discovered in week 6 is a
dropout; the same barrier discovered on arrival is a bus pass. A one-off
prompt cannot watch the store, and it cannot keep 80 classifications
consistent across weeks of arrivals.
Setup tip: in the store's table view, move the Intelligent Cell and Row
columns to the front — readiness flag, primary barrier, profile first;
raw text after — so intake staff triage the cohort from the leftmost
columns.
A baseline measure that never gets re-asked is dead weight; a later measure with no baseline is an unprovable claim. So the last step is an audit: every baseline measure must reappear at a later wave, on the same scale, joined by the same ID. The Sopact Assistant runs this check across the workspace — something a standalone prompt can’t do, because it never sees the other waves’ instruments.
RiseWorks’ audit, over the real stores:
That last row is the audit earning its keep. The exit’s 0–100 skills assessment is the right tool for placement matching — but it is not the partner of a 1–5 self-rating, and no amount of statistics will make them a pair. The fix costs one question: re-ask the 1–5 self-rating at exit if self-assessed growth is a claim the program wants to make. Caught at design time, that’s a one-line edit. Caught at report time — which is when traditional CM discovers every one of these holes — it’s a year of unprovable claims.
The payoff of a clean audit is the series’ spine: because confidence was paired across three waves and joined by email, RiseWorks can trace one person — 4.3 at intake, through training, to 7.4 at exit, to a $25.11 wage at follow-up — and because every record reconciles, it can say 82% of completers were employed at follow-up versus 45% of non-completers. None of that is analysis heroics. All of it is baseline design.
Prompt 4 — Baseline Gap Check
PROMPT 4 — BASELINE GAP CHECK [SENSE]
Chapter 3 of the Case Intelligence series · How to Design an Intake Form That Captures a Usable Baseline
Run this in the Sopact Sense Assistant over your store.
A standalone prompt cannot audit waves it never sees; the Assistant works
across the workspace — intake, mid, exit, and follow-up instruments at
once — which is the only place this check can run.
------------------------------------------------------------
THE ASSISTANT PROMPTS TO RUN (plain language, over the workspace)
1. "List every baseline measure collected at intake. For each, check
whether a later wave re-asks it on the SAME scale, same wording,
joined by the same persistent ID."
2. "Flag any baseline measure with no matching later wave — dead fields
that can never show change. Recommend: add the later wave, or stop
collecting."
3. "Flag any later-wave measure with no baseline — claims with no
starting point."
4. "Confirm the persistent ID (email) is present and valid on every
record so waves reconcile."
VERDICT CATEGORIES (fixed)
PAIRED — later wave exists, same scale, same wording, joined by ID.
FLAGGED — scale drift, missing later wave, or missing baseline.
Every FLAGGED row gets a one-line fix.
WHAT IT RETURNS — RiseWorks Foundation / Pathways 2027, over the real stores
baseline_confidence_1to10 | Mid AND Exit, 1–10, same wording | Yes |
PAIRED — payoff: 4.3 → 7.1 → 7.4
baseline_hourly_wage | Six-month follow-up, $/hr | Yes |
PAIRED — payoff: $9.96 → $25.11
receives_public_assistance | Six-month follow-up | Yes |
PAIRED — poverty-exit context
baseline_skill_self_rating_1to5 | Exit measures skills as a 0–100
assessment | No — scale drift | FLAGGED — the 1–5 self-rating has no
same-scale partner; "skills improved" cannot be claimed from this pair
That last row is the audit earning its keep. The exit's 0–100 skills
assessment is the right tool for placement matching — but it is not the
partner of a 1–5 self-rating, and no amount of statistics will make them
a pair. The fix costs one question: re-ask the 1–5 self-rating at exit if
self-assessed growth is a claim the program wants to make. Caught at
design time, a one-line edit; caught at report time — which is when
traditional case management discovers every one of these holes — a year
of unprovable claims.
THE PAYOFF OF A CLEAN AUDIT
Because confidence was paired across three waves and joined by email,
RiseWorks can trace one person — 4.3 at intake, through training, to 7.4
at exit, to a $25.11 wage at follow-up — and because every record
reconciles, it can say 82% of completers were employed at follow-up
versus 45% of non-completers. None of that is analysis heroics. All of it
is baseline design.
WHY THIS NEEDS SENSE
The check spans every wave's instrument and every record's ID at once.
A chat window sees only what you paste; the Assistant sees the store —
which is why this audit runs at design time instead of surfacing as a
hole at report time.
Confusing registration with baseline. Demographics tell you who enrolled; they measure no outcome. If your intake form is demographics plus free text, you have a registration form. Add the before-numbers your theory of change needs, or accept that change will be unprovable.
Changing the scale between waves. A 1–5 at intake re-asked as 0–100 at exit is not a pair — it’s two orphans (RiseWorks’ skill rating is the live example). The scale you pick at intake is a contract with every future wave. Same scale, same wording, every time.
Building a separate intake survey when the application already asked. Every duplicate question costs completion rate and invites inconsistency ($14/hr on the application, $15/hr on the intake — which is the baseline?). Reuse the application store as the pre wave; only collect post-acceptance facts separately.
Letting the open text pile up. Two open questions are gold if they’re classified on arrival and dead weight if they wait for a coding sprint that never comes. If the free text isn’t structured the day it lands, it will not be structured the month the cohort needs supports.
Skipping the ID. An intake record without email (or your chosen persistent ID) is a baseline for nobody — it can never reconcile with a later wave. Make the ID the first required field on the form, and validate it.
An intake form where every field earns its place: demographics that segment, baseline measures that each map to a theory-of-change outcome and a named later wave on the same scale, two open questions that arrive pre-classified, and a persistent ID that makes every future wave reconcile automatically. Plus an audit — run at design time, not report time — that flags any measure that can never show change.
Because the baseline is derived from the theory of change, every before-number exists to prove a specific promised outcome. Because the application doubles as the baseline, “pre” costs zero extra burden. Because Intelligent Cell structures the free text on arrival, supports route before day one and no coding backlog ever forms. And because every measure is paired and joined, the end-of-program story — 4.3 → 7.1 → 7.4, $9.96 → $25.11, 82% vs 45% — is a query over reconciled records, not a reconstruction project. The skeptic’s one-liner: a baseline is only usable if it’s comparable and joined — and Sense makes it both, on arrival.
Add two questions to your intake, on the exact scales you’ll reuse later: a 1–10 confidence question (or your program’s core outcome, self-rated) and one open barrier question. That’s it. The 1–10 becomes your 4.3; the barrier text becomes your support-routing. Everything else in this article is refinement on those two.
A screen-by-screen walkthrough — reusing the application store as the pre wave, watching Javier’s barrier text classify on arrival, and running the gap check — is in production. Check back on the Academy.
Program leads whose intake form was designed by the registration process, not the theory of change. Evaluators who found out at report time that the exit survey measured on a different scale than intake. Anyone with a drawer of un-coded open text and a funder asking “compared to what?” If your program collects a lot at intake and proves nothing at exit, the fix starts here.
Capture your baseline in Sopact Sense — sopact.com/academy.
Next in the series: How to spot at-risk participants mid-program — the mid wave reads engagement against this baseline, and the readiness flags you set on arrival become the early-warning system.
Open Sopact Sense, paste your program description, and put it to work.
Try in Sopact