What is an accountability partner: a peer, not an overseer

The shortest answer every SERP article gives is some version of 'a person who helps you keep a commitment by checking on your progress.' That sentence is true and also asymmetric by default: one person checks, the other is checked on. The shortest accurate answer on this site is different. An accountability partner is the other human who, every day at roughly the same wall-clock time, opens the same Google Meet URL you do and sits in silence with you. The relation is symmetric by construction. Nobody on the call is the checker and nobody is the checked-on. If you do not show up, neither does your partner, and the database quietly notices both absences. If only one of you shows up, the relation has not ended, but the day's practice has already failed the only way it can fail, which is that the two of you did not sit together.

Two reasons, one code-level and one tradition-level. The code-level reason is that the matcher at src/app/api/auto-match/route.ts scores candidate pairs by symmetric attributes only: readyScore adds to itself whether either side's status is 'ready' (lines 170 to 172), bothOld is whether both attendees are old students in the Goenka tradition (lines 173 to 175), sessionMatch is whether their session_duration fields are equal (lines 176 to 177), and the final sort breaks ties by the absolute UTC time difference (line 188). None of those fields models capacity or willingness to supervise. The tradition-level reason is that the service is free in the dana (donation) tradition that the Goenka courses are taught in. A paid relationship can survive being asymmetric: the supervisor gets paid, the supervised gets a result. A free relationship cannot. If one party were doing the work of checking and the other were merely being checked, the unpaid work would quietly burn out whichever side was doing it. Symmetry is what keeps the whole thing free.

One function: buildCommonTraits in src/lib/emails.ts, lines 4 to 19. The signature is (personA: WaitlistEntry, personB: WaitlistEntry) and returns string[]. The function walks four predicates, each of which is a symmetric comparison: both is_old_student === 'Yes', both frequency equal, both session_duration equal, both timezone equal. Each match pushes one English-language bullet into the result array. The intro email at lines 201 to 213 takes that array and renders it as an HTML unordered list directly under the 'I think you're a great match' line. Four checks, four possible bullets, zero of which describe oversight or a one-way role. That list is the first concrete thing both partners see about each other in their inbox.

Nobody checks in on anyone in the overseer sense. Each partner does notice the other's absence, because Google Meet shows who is in the room. The noticing is mutual and ambient, not delegated. There is no weekly check-in call in either calendar. There is no progress report. There is no DM thread where one partner asks the other 'how did this week go.' There is only the shared room and the identical routine of opening it. The communication layer is a reply-all email thread where replyTo contains both addresses, so either person's message reaches the pair and me together, not a one-way supervisor inbox. If you are looking for structured oversight, the match service is not the product you want. A paid coach is.

Because the matcher has nothing else to pair on. The waitlist form does not ask the signup to pick a goal; it asks for practice traits (old student status, session frequency, session duration, timezone, morning or evening, local time). Those are the fields the matcher has in hand. The intro email reflects the pairing logic exactly. The bullet list you receive is a literal report of which of the four similarity predicates returned true for you and your partner. If all four return true, four bullets appear. If none return true, there are no bullets at all, and the rest of the email carries the whole message on its own. The design choice is to not invent goals that were never declared.

It probably does not, and that is on purpose. If what you want is a human who will ask you, every Friday, whether you hit your three writing deadlines and push you if you did not, the product to build or buy is a coach or a paid accountability service, not the free peer-match on this site. The matcher does not know about deadlines, does not track goals, does not send nudges, does not issue reminders beyond the confirmation flow, and does not escalate on silence. If both partners go dark, the partnership ends without anyone being told. That is a feature for people whose practice is already internal and whose help is mostly just another body doing the same thing at the same time. It is not a feature for people who need external pressure to act.

Yes, and the intro email to every new pair says so, at src/lib/emails.ts line 295, in the first person: 'I've personally been meditating over Google Meet with my buddy for the past three years this way.' That sentence is not marketing. It is the operator's own practice, unchanged, now offered to two strangers whose traits line up. The 'three years' claim is a rolling number that sits in the email template. It grounds the rest of the claim that the peer frame works: a long-running daily partnership between two adults, with no supervisor on either side and no fee on either side, which has not collapsed the way you might predict a peer relation would.

Three of them, adapted. First, the 'shared commitment' part holds: both partners agreed to open the same Meet URL every day. Second, the 'mutual support' part holds, in a thin form: by being present, each partner makes it easier for the other to be present. Third, the 'regular cadence' part holds: the calendar event recurs with RRULE:FREQ=DAILY, so showing up is a daily event, not an on-demand one. What does not hold is the asymmetry: there is no tier, no checker, no checked-on, no reporter, no reportee. Anything the SERP implies about one-way status does not map onto the object the matcher produces.

As a symmetric binary relation. If A is B's partner, then B is A's partner, by the same Meet URL, the same calendar event id, the same daily RRULE, the same token pair in meet_links. There is no field called 'primary_partner' or 'secondary_partner.' The matches row has person_a_id and person_b_id, and which one is 'a' and which is 'b' is an implementation detail of the insertion order in the matcher, not a rank. The word 'partner,' on this site, carries no more and no less asymmetry than the word 'sibling' does. It is a relation two people are in, evaluated the same way from either side.

Not here. Questions about how to sit, how to work with physical sensations, how to handle restlessness, or anything touching the technique itself are for an authorized assistant teacher at a 10-day residential course, arranged through dhamma.org. This page, and the product it describes, restrict themselves strictly to logistics and peer matching. The matcher pairs two humans whose schedules and traits overlap. The practice itself, and any question about how to practice, stays with the tradition and its authorized teachers.