MeetingsCount
Verifiable attendance for court-ordered meetings. A participant taps check in and their phone reports where it is, once. The server scores that against the meeting's place and time, and anything it can't settle goes to a person before it affects anyone.
- Role
- Design, web app, backend
- Platform
- Web, installable on a phone
- Stack
- Python, FastAPI, PostgreSQL
- Status
- In development
Screens show a demo county. Every person and record in them is invented.
The problem
MeetingsCount replaces the paper court card.
Today, someone ordered to attend recovery meetings or community service carries a slip of paper, asks the meeting chair to sign it, and hands the stack to their probation officer. The slip is easy to forge and easy to lose. The court gets a signature nobody verifies, and the officer reads compliance off a stack of slips, by hand, for every person.
There's a quieter problem too. Twelve-step meetings protect anonymity, so asking a chair to sign for the court is itself a problem. MeetingsCount needs nothing from the meeting.
What we built
One principle runs through all of it: the system confirms attendance, and a person decides anything that hurts.
- Phone app
- Installable from the browser, with no app store. One tap to check in, a plain answer, and the participant's own record with every reason.
- Rules
- Each check-in is scored for distance, timing, and GPS accuracy. Every rule writes its reason in plain English.
- Review queue
- Anything the rules can't settle waits for an officer, who decides with the evidence in front of them.
- Caseload
- Everyone an officer supervises, this week against their order, and who is behind.
- Report
- A printable attendance report for the file, week by week against the order.
- Audit log
- Every staff view of a record, every decision, and every export, with who and when.
Decisions that matter
A person decides anything that hurts.
The rules never record a failure on their own. A check-in that looks off goes to the review queue, where an officer sees the map, each signal against its limit, how check-ins usually go at that venue, and what the decision would do to the person's week.
Every decision waits six seconds with an undo, so a stray keystroke can't count or fail anyone. Changing a decision needs a reason and keeps the earlier one.
No single check is proof. A free app can fake a location, which is why confidence is built from layers and a person reviews anything unclear.
Unclear is not failed.
A weak signal in a basement isn't a missed meeting. The check-in is recorded, sent for review, and shown as pending, never as a miss. The participant can add a note in their own words.
An officer can also ask a question instead of deciding. It waits at the top of the participant's app, and the answer comes back to the top of the queue.
Location is read once, at the tap.
The app explains the request before the phone asks. It reads the location at check-in and at check-out, and nothing in between. There is no background collection in the code.
Staff lists show outcomes, not coordinates. The phone shows the result as a drawing, not a map, so no location goes to a map provider from the phone.
A report that says only what it knows.
The attendance report shows each week against the order, then every check-in with any review decision in the officer's own words. It explains itself to a reader who has never seen the system.
It says attendance was confirmed or could not be verified. It never says someone did not attend.
Where it stands
Working today
The participant app, the review queue, the caseload and records, sign-in for staff and participants, the printable report, staff accounts, the audit log, and a preview running on demo data.
Next
Recurring meetings and address search, a rotating meeting code on a printed sheet, sign-in codes by SMS, field encryption, and deployment on AWS.
Deliberately not building
Continuous monitoring of any kind, geofence alerts, and scoring by machine learning.
Have a process that still runs on paper? Tell us how it works today.