Accountability partner means one JSON field, read at 14:00 UTC.

It means the other human whose email address is attached to the same Google Calendar event as yours, whose attendees[].responseStatus field in that event is not the literal string 'declined' when the /api/check-rsvp cron polls the calendar at 14:00 UTC every day. If either of the two responseStatus values is 'declined' on any daily poll, the partnership is auto-ended the same minute by updateMatchStatus(match.id, 'ended', 'cron') at src/app/api/check-rsvp/route.ts line 134. Nothing else changes that status automatically. Silence does not. A low reply rate does not. A missed sit does not. The only machine-readable predicate the runtime watches for 'accountable' is that one inequality on one JSON field, polled once a day.

Google's Calendar API returns responseStatus as one of four canonical strings: 'needsAction' (the invite has not been answered yet), 'tentative' (the invitee marked it maybe), 'accepted' (the invitee said yes), and 'declined' (the invitee said no). The RSVP cron in route.ts lines 121 to 122 reads the string as-is. Line 133 asks whether either person's value is exactly 'declined'. Everything else, including 'needsAction' and 'tentative', is treated as still in the pool. The design is asymmetric on purpose. 'needsAction' is common, it happens any time Gmail just drops the invite into someone's mail without them tapping a button, and it would be a bad idea to end a partnership on the absence of a tap. 'declined' requires a deliberate click in Gmail or Calendar. The only signal the cron treats as final is the one a human had to affirmatively send.

Within 24 hours, at the next 14:00 UTC tick, the cron fetches the event, reads attendees, finds the string 'declined', updates the match row's status to 'ended' with source 'cron', stores the new calendar_rsvp_a and calendar_rsvp_b values, and queues an operator email. The email lands in i@m13v.com with a subject like 'Calendar RSVP update: 1 match changed (1 auto-ended)' and a table of the old and new statuses. No one tells the two meditators directly. Their intro thread goes quiet, the shared Meet URL stops being opened, and the operator sees the change on the admin dashboard. The relation does not formally announce its own ending because it never formally announced its own starting either; on this site both events are rows in the database that the operator reads.

It means the last reading of the JSON field was not 'declined'. Between cron runs the runtime has no live signal on whether you are still in the relation; it has only the last poll's answer and the heartbeat of meet_clicks rows written each time either of you hits the /meet/<token> link (src/app/meet/[token]/route.ts line 27). The design choice is that a daily cadence is enough. Meditation is a daily practice, not a minute-by-minute one, and the 14:00 UTC tick catches any intentional decline inside one calendar day. Anything shorter would be chasing ambient state at the cost of email volume; anything longer would let the relation drift out of sync with reality. One poll per day, on a field a human had to click, is the full sampling plan.

Because the runtime cannot distinguish a silent day from a traveling day from a sick day from a day the Meet URL was clicked on a phone that the server cannot see. Any automated reading of silence would be a false positive a meaningful fraction of the time, and a false positive here would dissolve a real partnership that both humans still believe in. The only signal the cron treats as final is one that required a human to affirmatively press a button labeled 'Decline'. Everything softer stays in the pool and is left to the pair to resolve with each other or with the operator. This is the boundary between what a program can know about the relation and what it cannot.

Yes. If either person's responseStatus is 'declined', the match ends. The check at line 133 is an OR, not an AND. A unilateral click by one participant is sufficient to close the relation from the runtime's point of view, even if the other participant never touched their invite and would have happily kept sitting. The symmetry is that either side can end it alone; the asymmetry is that nobody can unilaterally keep it alive once the other party has declined. This is the same shape the word carries everywhere else on the product. Two humans enter a partnership together and either one of them can leave it alone.

No, and nothing on this site should. Questions about technique, posture, how to work with sensations, or how to respond to difficulty on the cushion are for an authorized assistant teacher at a 10-day residential course, arranged through dhamma.org. This page is about what a matcher and a cron do with two email addresses and a Google Calendar event. The technique itself stays with the tradition and its authorized teachers. The product handles logistics. The practice is yours and your teacher's.

Four files. The cron schedule is in vercel.json ('schedule': '0 14 * * *' for '/api/check-rsvp'). The check itself is at src/app/api/check-rsvp/route.ts lines 119 to 137, with line 121 extracting rsvpA, line 122 extracting rsvpB, line 133 comparing both against the string 'declined', and line 134 auto-ending the match. The heartbeat counterpart is src/app/meet/[token]/route.ts line 27, which inserts into meet_clicks every time either partner hits their personal Meet URL. The third piece is src/app/api/expire-matches/route.ts line 11, where a separate daily cron at 12:00 UTC drops any match that has been stuck in 'confirming' status for more than 3 days without a reply. Together those four files are the complete machine-readable definition of accountability on this product.