Participant Bio System
Version: 1.0 Last Updated: 2026-04-19 Status: Planning
Overview
The Participant Bio System collects positive, personality-focused insights about participants from the staff who work with them, then uses AI to generate a warm "Getting to Know [Name]" guide. This bio sits alongside the clinical ROC (Record of Care) data on each participant's profile, giving support workers a balanced picture: the structured support information they need AND the human context that makes good support possible.
Why This Exists
The Problem
Participant data in RABS is dominated by clinical and risk-focused information:
- ROC data: medication, risk assessments, behaviour support plans, dietary requirements, restrictive practices
- Operational data: schedules, supervision ratios, transport needs
While essential for safety and compliance, this data paints an incomplete picture. A new support worker reading only ROC data would learn that a participant has a behaviour support plan and dietary restrictions, but wouldn't learn that she lights up when you put music on, hates peas but loves corn, and always wants to sit near the window.
The Solution
Staff who work directly with participants hold this knowledge. The Bio System provides structured ways for them to share it, then synthesises their contributions into a readable, practical guide.
The result is two complementary views of each participant:
| ROC Data | Bio |
|---|---|
| What support they need | Who they are as a person |
| Risk mitigation | Positive engagement strategies |
| Clinical requirements | Personality and preferences |
| What to watch out for | What makes them happy |
| Structured, templated | Warm, narrative |
How It Works
The Three Layers
┌─────────────────────────────────────────────────────┐
│ GENERATED BIO │
│ "Getting to Know Karen" │
│ Warm, readable, AI-generated from all submissions │
├─────────────────────────────────────────────────────┤
│ MODERATION │
│ Admin reviews, approves, or rejects submissions │
│ Only approved submissions feed into bio generation │
├─────────────────────────────────────────────────────┤
│ SUBMISSIONS │
│ Raw staff input from web, SMS, Discord, Reggie │
│ Each tagged with who submitted and when │
└─────────────────────────────────────────────────────┘
Submission Flow
- A staff member submits an insight about a participant (via any input channel)
- The submission is stored with
pendingmoderation status - An admin reviews the submission on the participant's profile page
- If approved, the submission becomes part of the bio source material
- If rejected, the submission is excluded with a reason (stored but not used)
- After approval, the bio is automatically regenerated to include the new insight
Input Channels
Staff can contribute through whichever channel is most natural for them:
Web Form (Primary)
On the participant's profile page, the Bio tab contains a simple submission form. Staff type their insight and submit. They can see existing approved submissions and the current generated bio.
SMS Keyword: BIO
Staff text the keyword BIO followed by the participant's name and their insight:
BIO Karen She loves bowling and always wants to sit near the window at lunch
The system:
- Identifies the staff member from their phone number
- Matches "Karen" against active participants
- Stores the insight as a submission
- Replies with confirmation: "Thanks! Your insight about Karen has been submitted for review."
If the name is ambiguous (multiple Karens), the system asks for clarification.
Reggie SMS (Natural Language)
Staff can naturally mention insights to Reggie during conversation:
"Hey Reggie, just a note that Michael really enjoyed the art class today and was asking when the next one is"
Reggie detects the bio-contribution intent, extracts the participant name and insight, and stores it as a submission.
Discord Channel
A dedicated #participant-bios channel in the DSW-CMS Discord server. Staff post observations in any format:
Karen - she was really happy today, loved the music activity and was dancing the whole time
The bot extracts the participant name and content, then stores as a submission.
Proactive SMS Requests
After a shift ends, the system can text the staff member:
"You just worked with Karen. Got any tips, fun facts, or insights to share about working with her? Reply BIO followed by your insight."
This is triggered from shift completion data and rate-limited to avoid fatigue (max once per fortnight per staff-participant pair).
Bio Generation
How the AI Generates Bios
The system uses OpenAI (gpt-4.1-nano) to synthesise all approved submissions into a coherent, warm bio. The generation process:
- Collects all approved submissions for the participant
- Loads the previous bio version (if one exists)
- Generates a new bio that incorporates all submissions and preserves established facts from the previous version
- Compares the new bio against the previous one to check for dropped information
- Stores the new version with a version number and reference to which submissions were used
Bio Structure
Generated bios follow a consistent structure:
- Personality -- Who they are, temperament, general vibe
- Likes & Interests -- Activities, topics, foods, music, shows they enjoy
- Communication -- How they prefer to communicate, things that help
- Practical Tips -- Day-to-day things that make shifts smoother
- Social -- How they interact with others, friendship dynamics, group preferences
- Motivations & Goals -- What they're working towards, what excites them
Sections are only included when there's submission data to support them. A new participant with one submission might only have a "Practical Tips" section, and that's fine.
Consistency Across Versions
A key design principle: new information adds to the bio, it doesn't replace it.
If version 1 says "Karen loves bowling" and version 2 has new submissions about her enjoying art class, the regenerated bio should include both bowling AND art class. The LLM is explicitly instructed to preserve established facts unless newer submissions specifically contradict them.
If contradictory information appears (e.g., one staff says she likes loud music, another says she prefers quiet), both are included with a note, and the moderation queue highlights the conflict for admin resolution.
Moderation
Why Moderation Matters
Not every submission should go straight into a bio:
- Staff might accidentally include clinical information ("she had a seizure last Tuesday")
- Submissions might reference other participants by name
- Content might be negatively framed ("she's really difficult in the mornings")
- Typos or unclear submissions might need editing
Moderation Workflow
| Status | Meaning | What happens |
|---|---|---|
pending | New submission, not yet reviewed | Visible to admin only, not used in bio |
approved | Admin confirmed as appropriate | Included in next bio generation |
rejected | Admin excluded with reason | Stored but never used in bio |
flagged | Needs discussion before decision | Highlighted for team review |
Admin controls on the participant's Bio tab:
- Approve -- submission feeds into bio generation
- Reject -- excluded, with optional reason note
- Flag -- mark for team discussion
- Edit -- fix typos or remove sensitive content before approving
- Pin -- always include this submission, even across regenerations
Database
Schema: core_source
participant_bio_submissions
Stores every raw staff submission.
| Column | Type | Purpose |
|---|---|---|
id | UUID | Primary key |
participant_id | UUID → participants | Which participant this is about |
submitted_by_staff_id | UUID → staff | Staff who submitted (NULL if unmatched) |
submitted_by_name | TEXT | Display name for unmatched sources |
source_channel | TEXT | 'web', 'sms_keyword', 'sms_reggie', 'discord', 'admin' |
source_reference | TEXT | Original message/post ID for traceability |
raw_text | TEXT | The submission content |
moderation_status | TEXT | 'pending', 'approved', 'rejected', 'flagged' |
moderation_note | TEXT | Admin's reason for rejection/flagging |
moderated_by | UUID → users | Who moderated |
moderated_at | TIMESTAMPTZ | When moderated |
pinned | BOOLEAN | Always include in bio generation |
created_at | TIMESTAMPTZ | When submitted |
participant_bios
Stores generated bio versions.
| Column | Type | Purpose |
|---|---|---|
id | UUID | Primary key |
participant_id | UUID → participants | One active bio per participant |
version | INTEGER | Incremented on each regeneration |
bio_text | TEXT | Generated bio (markdown) |
bio_html | TEXT | Pre-rendered HTML |
submission_count | INTEGER | Number of approved submissions used |
submission_ids | UUID[] | Which submissions were included |
previous_bio_text | TEXT | Prior version for consistency comparison |
generated_by_model | TEXT | LLM model used |
generated_at | TIMESTAMPTZ | When generated |
Integration Points
Participant Profile Page
The Bio tab appears alongside existing tabs (Overview, Documents, Schedule, ROC, etc.). It shows:
- The generated bio at the top (or a placeholder if no submissions yet)
- A submission form for staff to contribute
- A list of submissions (admin sees all with moderation controls, staff sees approved only)
- Regenerate button (admin only)
ROC Data Complement
The bio is explicitly designed to complement, not replace, ROC data. On the participant profile:
- ROC tabs: Clinical, structured, risk-focused (existing)
- Bio tab: Personality, positive, practical (new)
Staff are encouraged to read both before working with a participant for the first time.
SMS System
The BIO keyword is handled in routes_v1p/sms.js alongside existing keywords like NOCONTRACT and shift cover responses. The pattern:
Incoming SMS: "BIO Karen She loves bowling"
^^^ ^^^^^ ^^^^^^^^^^^^^^^^^
keyword name insight text
Discord Bot
The bot (in bot/bot.js) watches the #participant-bios channel for new messages. Messages are parsed for participant name mentions and stored as submissions.
Reggie SMS Agent
Reggie's intent classifier (in services/reggie-sms-v3.js) detects when staff are sharing participant insights during natural conversation, extracts the relevant content, and stores it as a bio submission.
TokenWatch
Bio generation API calls are tracked under project tag participant_bios in the TokenWatch system for cost monitoring.
Permissions
| Action | Who |
|---|---|
| Submit via web form | Any logged-in staff/admin |
| Submit via SMS/Discord | Any staff with phone/Discord linked |
| View generated bio | Any logged-in user with participant access |
| View submissions (approved) | Any logged-in user |
| View submissions (all statuses) | Admin, management |
| Approve/reject/flag submissions | Admin, management |
| Edit submissions | Admin, management |
| Regenerate bio | Admin, management |
| Pin submissions | Admin, management |
Privacy Considerations
- Submissions may inadvertently reference other participants or staff by name. The moderation step catches this before it enters the generated bio.
- Generated bios are visible to all staff with participant access. Content should be appropriate for this audience.
- The LLM generation prompt explicitly instructs against including clinical, medical, or risk-related content in the bio.
- All submissions are attributed to their source for accountability.
- Rejected submissions are stored (not deleted) for audit purposes.