6- How to Catch At-Risk Participants Early with Mentor Notes

For: program leads and mentorship coordinators sitting on hundreds of weekly mentor notes that nobody reads across the caseload — until someone drops out and the warning turns up in week 4’s note.

Why: mentor notes are the richest early-warning data a program collects, and in traditional case management they are free text filed per participant, invisible at scale, read only in the post-mortem.

Outcome: every note structured on arrival — topics, progress, blockers, next actions, each pinned to the sentence it came from and never a guessed feeling — plus a caseload view that surfaces aging blockers and stalling mentees while the fix is still a bus pass, not an exit interview.

This is Chapter 6 of the Case Intelligence series — the recurring wave. In Chapter 5 you closed the pre/post pair at exit and measured change for the people who finished. But exit is where you count the people you kept, not where you keep them. RiseWorks enrolled 80 and completed 62, and the eighteen who left did not vanish at exit — they slipped weeks earlier, one missed session and one unresolved blocker at a time, while the evidence sat in the mentor notes.

The running example stays the same: RiseWorks Foundation / Pathways 2027 (Train → Match → Place → Earn). Its mentors write a short note after every weekly session — 280 notes across the mentored caseload — and those notes are one of the eight stores in the workspace, joined to intake, mid, and exit by the same persistent ID. This chapter is about making that store watch the caseload instead of archiving it.

As in every chapter, each step is tagged [DIY] or [SENSE]: designing a note template mentors will actually fill, and writing the extraction rule that keeps the analysis honest, is thinking work you can do in any AI today; extracting four fields from every note on arrival and tracing trajectories across the whole caseload is what the product does over the store.

One rule governs everything in this chapter, and it is worth stating before anything else: evidence only — never infer emotion. Extract what was said. Never guess how someone feels. “Missed two sessions; said the bus route changed” is evidence a skeptic can check against the note. “Seems discouraged” is a fabrication — and invented sentiment is the fastest way to make staff stop trusting the analysis.

The best early-warning data is the notes nobody reads

Here is the uncomfortable inventory: RiseWorks already collects exactly the information that predicts drop-off. Every weekly note says what the mentee worked on, whether they moved forward, what is in the way, and what happens next. Multiply by the caseload and the program holds 280 small status reports on the people most likely to slip.

And in a traditional case-management tool, that data is functionally invisible. Notes are filed per participant, in chronological piles. A mentor sees their own mentee’s last note; a coordinator opens a file when there is already a problem. Nobody reads 280 notes across a caseload, week over week — so nobody sees that the same blocker, “still no reliable transport to the shop,” has appeared in three different mentees’ notes for three weeks running. The pattern that would have predicted the 80 → 62 loss is present in the text and absent from every screen. It gets read after someone leaves, when the only thing left to do is record it.

The structural difference, stated once: traditional CM platforms treat notes as documentation — collect now, read never, code by hand if a report demands it. Sopact Sense treats the note as data on arrival: an Intelligent Cell extracts the same four fields from every note the moment it lands, each tied to its evidence quote; the extraction is adaptive — tighten the rule on the first five or ten notes and every note re-extracts; and the store is centralized without merging — Mentor Weekly Notes joins the other seven stores by the persistent email ID, so a note-stream sits on the same timeline as the mentee’s intake baseline and midpoint check.

Two more framing points. First, this wave is recurring, not pre/post. Intake, mid, and exit are point-in-time measures; mentor notes are the same mentee week after week, and their value is trajectory — a blocker mentioned once is noise, the same blocker three weeks running is signal, and momentum going flat is the earliest signal there is. Second, this wave complements the Chapter 4 midpoint flag, not replaces it: the midpoint check catches who is slipping at the halfway line; the mentor trajectory catches the slide forming, weeks before. Together they close the window in which a program can still act.

Step 1 — Design a note a busy mentor will fill [DIY]

What you do. Write a weekly note template with exactly four free-text fields — and resist every urge to add a fifth. Too long and mentors skip it after busy sessions, which are exactly the sessions you need recorded; too loose and there is nothing to extract.

Real example — RiseWorks. The template is four headings with one instruction each:

• Topics discussed — what the session covered.
• Progress — did the mentee move forward, hold, or slip since last week, on what.
• Blockers — what is in the way; be specific and concrete (a named module, a bus route, a childcare gap).
• Next actions — what happens before the next session, and who owns it.

Free text under each heading. Mentors are not asked to code, rate, or tag anything — writing four short paragraphs after a session is a habit that survives; maintaining a taxonomy is not. And one field is deliberately absent: there is no “mood” or “how are they feeling” box. A mood field invites the mentor to speculate, and speculation poisons the store. If a mentee said something that matters, it belongs under blockers or progress as what was said.

Why it matters. The template is the contract between the humans who write and the machine that reads. Four predictable headings mean the extraction lands cleanly on every note; concrete blocker language means the flag that eventually fires carries a checkable fact.

Prompt 1: Mentor Note Template

You are a program designer. Design a WEEKLY mentor-note template
that is light enough for a busy mentor to fill after every session
and structured enough to be extracted reliably later.

INPUTS — paste between the markers:
<<< MY MENTORING PROGRAM, IN ONE OR TWO LINES (who mentors whom, how often) >>>

TASK
Produce the template with exactly FOUR free-text fields — no more:
1. TOPICS DISCUSSED — what the session covered.
2. PROGRESS — did the mentee move forward, hold, or slip since last
  week, and on what.
3. BLOCKERS — what is in the way; specific and concrete (a named
  module, a bus route, a childcare gap — not "struggling").
4. NEXT ACTIONS — what happens before the next session, and who
  owns it.

RULES
- Free text under each heading. Do NOT ask mentors to code, rate,
 tag, or score anything.
- Do NOT add a "mood", "sentiment", or "how are they feeling" field.
 Feelings get guessed; guesses poison the store. If the mentee SAID
 something that matters, it belongs under blockers or progress as
 what was said.
- Keep the whole note under five minutes to write. If your draft
 needs more, cut it until it does not.
- Add one line of writing guidance under each heading, phrased to
 pull concrete facts (dates, names of modules, stated reasons).

OUTPUT
The template: four headings, one instruction line each, plus a
two-line "how to write a useful note" header for mentors.
Nothing else. Deterministic: same input, same output, every run.

Step 2 — Write the extraction rule: evidence only, never emotion [DIY]

What you do. Before any AI touches a note, write down what it is allowed to pull out — and what it is forbidden to invent. This is the single most important artifact in the chapter.

The rule, in four lines:

1. Extract only four things: topics discussed, progress, blockers, next actions.
2. Attach the evidence quote — the exact sentence — to every extracted item.
3. Never infer, guess, or describe emotion, mood, or feeling. “Missed two sessions; said the bus route changed” is allowed. “Seems discouraged” is forbidden — even when it might be true.
4. If a field is not in the note, return “not stated” — never fill a gap with an assumption.

Why the hard line. Because the entire value of this system is that a human can trust a flag without re-reading the note. A flag that traces to a quoted sentence survives scrutiny: the coordinator clicks through, sees the sentence, acts. A flag built on “the model sensed frustration” collapses the first time a mentor says “I never wrote that” — and takes the whole system’s credibility down with it. Emotion-guessing is also unfair to the mentee: it converts a bad bus route into a personality assessment. Evidence can be checked; feelings cannot. Extract the fact, quote the sentence, stop.

Prompt 2: No-Emotion Extraction Rule

You are writing the extraction INSTRUCTION that will govern how any
AI reads a mentor note. The instruction must guarantee: evidence
only, never inferred emotion.

INPUTS — paste between the markers:
<<< MY FOUR NOTE FIELDS (or paste "topics / progress / blockers / next actions") >>>

<<< ONE OR TWO REAL (ANONYMIZED) SAMPLE NOTES, OPTIONAL >>>

THE RULE THE INSTRUCTION MUST ENCODE
1. Extract only four things: topics discussed, progress, blockers,
  next actions.
2. Attach the EVIDENCE QUOTE — the exact sentence from the note — to
  every extracted item. No quote, no extraction.
3. NEVER infer, guess, or describe emotion, mood, or feeling.
  "Missed two sessions; said the bus route changed" is allowed.
  "Seems discouraged" is forbidden — even when it might be true.
  Emotion words are allowed ONLY inside a direct quote of what the
  mentor wrote or the mentee said.
4. If a field is not present in the note, return "not stated" —
  never fill a gap with an assumption.
5. If the mentor stated a recurrence ("third week this has come
  up"), carry the count through as stated. Do not compute or guess
  recurrence from a single note.

FIXED OUTPUT CATEGORIES PER NOTE (use no others):
 topics: [list + quotes]
 progress: [advanced / held / slipped — only as evidenced, + quote,
           or "not stated"]
 blockers: [item + quote, or "not stated"]
 next_actions: [action + owner + quote, or "not stated"]

WHY THE HARD LINE (include this in the instruction so future users
keep it): a flag that traces to a quoted sentence survives scrutiny;
invented sentiment is the fastest way to lose staff trust, and it
converts a bad bus route into a personality assessment.

OUTPUT
The extraction rule as a short, reusable instruction block I can
paste in front of any note. Nothing else. Deterministic: the same
note must produce the same extraction every run.

A sample mentor note

One real RiseWorks weekly note, as written — Marcus D., week 6, the same participant whose exit Chapter 5 measured:

Week 6 with Marcus. Covered blueprint reading and joint prep for the AWS D1.1 practice test. He’s picking up the technical side fast — got through the fillet weld symbols without help this week. But he missed Tuesday’s shop session again; said the bus route to the training center changed and the new one gets him there 40 minutes late. Third week transport has come up. Told him I’d flag it for a bus pass or a schedule shift. Next: confirm transport support with program staff before next session, and he’ll redo the missed module online.

Notice what a good note contains: nothing about how Marcus feels, everything about what happened. A covered topic, a concrete win (fillet weld symbols, unassisted), a missed session with the stated reason, a recurrence count in the mentor’s own words (“third week”), and a next action with an owner. This is the raw material. In a traditional system it would now be filed and forgotten; the “third week” would be re-discovered at exit, past tense.

Step 3 — The note, structured on arrival [SENSE]

From here, this is product output, not a prompt you run. The moment the note lands, an Intelligent Cell on the note text extracts the four fields under the Step 2 rule, and an Intelligent Row assembles the Mentor Note Row — stamped with the note date and the mentee’s email, so it files itself onto Marcus’s timeline next to his intake baseline and midpoint check. Here is week 6, as Sense produces it on arrival:

INTELLIGENT ROW — Mentor Note · Marcus D. · week 6 · Skilled Construction Trades

Every cell is checkable against the sentence beside it. The blocker carries its own age (“3rd week”) because the mentor stated it; nothing was inferred. And because a standalone prompt has no store, it could produce this table for one pasted note — but it could not stamp it onto a persistent timeline, could not know this is the third week without the previous notes, and could not do it for 280 notes as they arrive. The structure is only useful because it accumulates.

Prompt 3 — Note Extractor on Arrival

WHERE IT SITS
Mentor Weekly Notes store — one of the eight stores in the
workspace, joined to Application/Intake, Mid-Program, and
Exit/Completion by the persistent email ID. One Intelligent Cell +
one Intelligent Row, firing on every note the moment it lands.

CELL — FOUR-FIELD EXTRACTION
Sits on: the note text field (mentor_note_text).
Instruction text of the Cell:
 "Extract exactly four fields from this note: topics discussed,
  progress, blockers, next actions. Attach the EVIDENCE QUOTE — the
  exact sentence — to every extracted item; no quote, no
  extraction. NEVER infer, guess, or describe emotion, mood, or
  feeling: 'missed two sessions; said the bus route changed' is
  allowed, 'seems discouraged' is forbidden. If a field is not in
  the note, return 'not stated'. If the mentor stated a recurrence
  ('third week this has come up'), carry the count as stated —
  never compute recurrence from a single note."

ROW — MENTOR NOTE ROW
Assembly spec: the four extracted fields with their quotes
 + note date + mentee ID (email) + mentor name
 → so every note files itself onto that mentee's timeline, next to
   their intake baseline and midpoint check, and the store stays
   queryable across the whole caseload.

SAMPLE RETURN — real note (Marcus D., week 6):
 Topics:      blueprint reading · joint prep · AWS D1.1 practice
              test — "Covered blueprint reading and joint prep for
              the AWS D1.1 practice test."
 Progress:    advancing on technical skills — "picking up the
              technical side fast — got through the fillet weld
              symbols without help this week"
 Blocker:     transport — RECURRING, 3rd week — "he missed
              Tuesday's shop session again; said the bus route…
              changed… Third week transport has come up."
 Next action: confirm transport support with staff before next
              session; mentee redoes missed module online —
              owner: staff + mentee
 Emotion:     not extracted — by rule

WHY A STANDALONE PROMPT CAN'T DO THIS
A chat window can structure the one note you paste into it. It
cannot stamp the result onto a persistent timeline, cannot know a
blocker is in its third week without the earlier notes, and cannot
run on 280 notes as they arrive — or re-extract all of them when
you tighten the rule after the first ten.

Step 4 — Trajectory, aging blockers, and the caseload list [SENSE]

One structured note is a data point. The value is the line through all of them — per mentee, and then across the caseload. The Sopact Assistant reads the mentor-note store in date order and computes momentum from the extracted progress and blocker fields — never from inferred mood. Marcus’s line:

Progress up and risk up at the same time — which is exactly the profile a single number would flatten. The Assistant surfaces it as an aging blocker: any blocker recurring two or more weeks for the same mentee, ranked by how long it has persisted, each with its quotes. Marcus’s transport issue is three weeks old and unresolved; the flag routes to program staff while the fix is still a bus pass or a schedule shift. This is the same transport barrier his intake flagged in Chapter 3 — caught here as it compounds, weeks before it would surface in the midpoint check, and it is the intervention his Chapter 5 counterfactual credits: “the mentor pushing me through the bus mess is the only reason I finished.”

Then the Assistant widens to the caseload — the early-warning list a coordinator opens on Monday:

The middle row is the one worth pausing on: one mentee’s transport problem is a support ticket; the same quote in three mentees’ notes is a program-design finding, surfaced while the cohort is still enrolled. And the coverage gap is the store auditing itself — the mentees this system cannot see are precisely the ones who turned up on the Chapter 4 at-risk list, which is the strongest argument for making sure everyone has a note stream. No emotion anywhere in the table. Every flag traces to a quoted sentence or a countable absence.

Prompt 4 — Trajectory + Aging Blockers

ASSISTANT PROMPT A — one mentee's trajectory

 "For [mentee], order every mentor note by date and read momentum —
  up, flat, or down — from the extracted progress and blocker
  fields only, never from inferred mood. Show week | progress |
  blocker | blocker age, with the evidence quotes."

WHAT IT RETURNS (Marcus D., RiseWorks):
 Wk 4: progress steady · transport blocker first appears (arrived
       late once) · age 1 week
 Wk 5: progress steady · transport again (missed one session) ·
       age 2 weeks
 Wk 6: technical progress up · transport again (missed one
       session) · age 3 weeks — FLAG
 Read: progress up and risk up at the same time — the profile a
 single score would flatten.

ASSISTANT PROMPT B — aging blockers across the caseload

 "Across ALL mentor notes, list every blocker that has repeated
  2+ weeks for the same mentee, ranked by how many weeks it has
  persisted, each with its evidence quotes. Then list blockers
  appearing across MULTIPLE mentees in the same period."

WHAT IT RETURNS (RiseWorks, 280 notes):
 - Marcus D. — transport, 3 weeks running, unresolved → route to
   staff: bus pass or schedule shift this week.
 - "Still no reliable transport to the shop" — the same blocker in
   three different mentees' notes for three weeks running → a
   program-level fix, not three separate conversations.

ASSISTANT PROMPT C — the caseload early-warning list

 "Surface every mentee whose momentum is flat or down, or who
  carries an unresolved aging blocker, and route each to a named
  human. Also list every participant with NO note stream — no
  mentor assigned or no notes arriving — as a coverage gap."

WHAT IT RETURNS (RiseWorks):
 The stall list with quotes and owners — plus the coverage gap:
 mentees with no mentor assigned have no note stream to watch, and
 Chapter 4's midpoint list caught two of them (Whitney Ferreira
 RW2-066 and Rosa Dixon RW2-074, at 41% and 49% attendance). An
 unwatched mentee is a silent one; assign mentors first.

EVERYWHERE: infer no emotion. Every flag traces to a quoted
sentence or a countable absence.

WHY A STANDALONE PROMPT CAN'T DO THIS
Trajectory is a many-record fact. A chat window has no store — it
cannot order weeks it never saw, cannot count recurrence across
mentees, and cannot notice the mentee who has no notes at all.

Common mistakes (and what to do instead)

Adding a mood field to the template. It feels caring and it corrupts the store — mentors start recording guesses, and every downstream flag inherits the speculation. If the mentee said something, record what was said. The template has four fields for a reason.

Letting the AI infer emotion “for richness.” “Seems disengaged” reads like insight and is unverifiable by design. The first time a mentor disputes an inferred feeling, staff trust in every other output dies with it. Evidence quotes only; “not stated” where the note is silent.

Reading notes per participant instead of across the caseload. Per-file reading is how three mentees report the same transport blocker for three weeks and nobody notices. The unit of analysis is the store, not the file.

Treating one mention as a crisis — or three mentions as noise. A blocker named once is context; the same blocker aging across weeks is signal. Write the threshold down (two or more weeks, same mentee) so the flag fires by rule, not by whoever happened to read the note.

Ignoring the mentees with no notes at all. An empty note stream is not good news; it is a blind spot. Whitney and Rosa had no mentor assigned — and surfaced at 41% and 49% attendance on the midpoint list. Audit coverage monthly: everyone at risk deserves a watcher.

What you have now

A four-field weekly note that busy mentors actually complete. A written extraction rule with the hard line in it — evidence quotes, never inferred emotion, “not stated” over assumption. Every note structured the moment it arrives and filed onto the mentee’s timeline by persistent ID. Per-mentee trajectories that read momentum from what was said. And a Monday-morning caseload list — aging blockers ranked by persistence, repeated blockers promoted to program-level findings, coverage gaps named — with every flag traceable to a sentence a human can check.

Why this works

Because the template is light, the data keeps arriving; because the rule forbids emotion, the data stays trustworthy. Because every note joins a persistent ID, 280 notes become timelines instead of piles — and trajectory, not any single note, is what predicts drop-off. Because the Assistant reads the whole store, a blocker repeating across mentees becomes a program fix instead of three unread sentences. And because this wave runs weekly, the catch happens while the intervention is still cheap — the bus pass that, in Marcus’s own exit words, is the reason there was an exit to measure. The skeptic’s one-liner: a flag that traces to a quoted sentence survives scrutiny; a guessed feeling never does.

The one thing to do this week

Restructure your mentor note into the four headings — topics, progress, blockers, next actions — and delete the mood field if you have one. That single change makes every future note extractable, and it costs your mentors nothing but a cleaner form. The trajectories, the aging-blocker flags, and the caseload list are all downstream of notes that arrive in four parts.

Video walkthrough (coming soon)

A screen-by-screen walkthrough — structuring a live note on arrival, tracing Marcus’s three-week transport blocker, and pulling the caseload early-warning list from the Assistant — is in production. Check back on the Academy.

Who this is for

Mentorship coordinators with hundreds of notes and no way to read them at caseload scale. Program leads who learned about a three-week-old blocker in an exit interview. Anyone burned by an analytics tool that reported feelings nobody wrote down. If your program’s richest data is filed per participant and read post-mortem — and your instinct says the warnings are already in there — the fix starts here.

Put your mentor notes to work in Sopact Sense — sopact.com/academy.

Next in the series: How to Calculate SROI — Live, Sourced, and Honest — the outcomes this chapter helped protect become a ratio a funder can check, with every number traced to its store.