Accountability partner agreement: seven clauses enforced by code, not a PDF

Not in the paper sense. Nothing gets countersigned and no PDF is exchanged. The agreement is enacted the moment you click the 'Yes, introduce me' button in the confirmation email, which hits /api/confirm-match?token=<your token>&response=yes. That click is logged, flips person_a_confirmed or person_b_confirmed to true, and, once both sides have clicked, triggers the run that creates the Meet URL, writes the meet_links rows, sets the calendar recurrence, and sends the intro email. From that moment on, the terms listed on this page apply to you. The closest thing to a 'document you agreed to' is the confirmation email itself: the URLs in it are the offer, and the click is the acceptance.

One, the cadence clause: the partnership repeats daily (recurrence: ['RRULE:FREQ=DAILY'] on src/lib/google-meet.ts line 75). Two, the permanence clause: the Meet URL does not rotate and is reused forever (src/lib/emails.ts line 288, the literal sentence 'This link is permanent, use it every day, at any time'). Three, the 3-day window clause: if both parties do not confirm within 3 days the match is voided and both go back on the waitlist (src/lib/emails.ts line 376, enforced by src/app/api/expire-matches/route.ts line 11). Four, the heartbeat clause: every click to /meet/<token> is logged to meet_clicks with IP and user-agent (src/app/meet/[token]/route.ts lines 26 to 29). Five, the unilateral-exit clause: either party can unsubscribe and all active matches for them end in one SQL UPDATE (src/app/api/unsubscribe/route.ts line 59). Six, the no-repeat clause: once paired with someone, the matcher will not pair you with them again (src/app/api/auto-match/route.ts, getPriorMatchedIds, lines 241 to 245). Seven, the pre-existing-condition clause: you represent that you have assessed your own fitness to sit intensive sessions, stated in src/app/disclaimer/page.tsx lines 60 to 73.

Typical templates are Google Docs with blanks: 'We, <Partner A> and <Partner B>, commit to meeting every <frequency> for <duration> to work toward <goal>. If one party misses <n> sessions, the consequence is <X>.' The document is the contract. Here, no document is the contract. The product already knows the cadence (daily), the duration (your session length chosen at signup), the channel (one specific meet.google.com URL), the partner (resolved by the matcher), and the consequence of inactivity (silence in meet_clicks, which is visible on the operator dashboard). Filling in a template would be redundant, because the template is already filled in by the runtime. What the templates give you, essentially, is a hand-rolled version of what this product automates. The downside of the hand-rolled version is that nothing enforces it. The downside of the code-enforced version is that it is narrow: only one kind of partnership (daily Vipassana sits) is supported.

Yes, and it is the slimmest plausible version of one. /terms covers the service-level agreement (free matching, no guarantees, participation is voluntary, we are not responsible for what happens between matched users). /privacy covers data handling (email stored, anonymous PostHog analytics, unsubscribe anytime). /disclaimer covers the mental-health caveat (if you have a history of certain conditions, talk to a professional before an intensive course). These three pages are the legal layer, and the seven clauses on this page are the operational layer sitting on top of them. The two layers do not conflict. The operational layer is what determines day-to-day behavior of the product; the legal layer is the background contract with the service itself.

Not by the two partners, not in the way a legal contract can be amended. The product does not expose a 'change cadence' button, a 'move the URL' button, or a 'renegotiate the window' button. If something has to change, either party uses the unsubscribe link to end the partnership and rejoins the waitlist with new preferences. The operator, Matt, can edit the calendar event manually (that is how the calendar_event_id column on the match row exists). In practice this only happens in recovery scenarios (a broken URL, a guest-permission issue). The unchangeability of the agreement, mid-flight, is intentional: the whole point is to move the commitment out of reach of a tired future self who wants to renegotiate at 5:30 in the morning.

Nothing immediate. There is no automatic nag, no missed-session penalty, no public leaderboard. The only signal is meet_clicks: if only one token shows clicks for N days, the operator dashboard flags the pair. The default resolution is to reach out over email (the intro email thread already includes both addresses in replyTo). If the ghosting continues, the remaining partner can unsubscribe and rejoin, and the matcher will pair them with someone new (skipping the ghost, because getPriorMatchedIds remembers the prior match). The system's theory is that an accountability partner whose partner has quit is not being held accountable, and the best thing to do is get them a live partner as fast as possible, not to manufacture guilt.

No. There is no 30-day minimum, no 'trial' that auto-converts to a paid plan, no clawback if you leave early. The only time-boxed clause is the 3-day confirmation window: if both parties do not click yes within 72 hours of the confirmation email, the match is voided (src/app/api/expire-matches/route.ts:11 passes 3 to expireStaleMatches). Once the partnership is active, you can unsubscribe at any time with a single click on the footer link of any email, and the SQL UPDATE at src/app/api/unsubscribe/route.ts:59 ends all your active matches in one go. That choice, 'no minimum,' follows from the dana-tradition constraint: the service is free, so there is no floor to protect.

Because the partnership is daily, and signed documents are a human ritual with a once-at-the-start cadence. A signed agreement works well for things that happen infrequently (a lease, a job offer, a coaching contract). It does not work well for things that happen 300 times a year. For a daily practice the enforcement that matters is, 'the thing that should fire today, fired.' A daily calendar event firing is an enforcement. A meet_clicks row being written is an enforcement. A cron job expiring a confirming match after 3 days is an enforcement. None of those are signatures, but all of them make 'yes this is happening' or 'no this is no longer happening' legible to the runtime without human intervention. The result is an agreement whose day-to-day health is measurable, not declared.

Yes, the whole repo is public. The cadence clause is one line: src/lib/google-meet.ts line 75, recurrence: ['RRULE:FREQ=DAILY']. The permanence clause is one sentence in the intro email template: src/lib/emails.ts line 288, 'This link is permanent, use it every day, at any time.' The 3-day window clause is the italicized sentence on the confirmation email: src/lib/emails.ts line 376, 'This match expires in 3 days. If neither of you responds, you'll both be placed back on the waitlist for a new match.' The heartbeat clause is the INSERT at src/app/meet/[token]/route.ts lines 26 to 29. The exit clause is the UPDATE at src/app/api/unsubscribe/route.ts line 59. The no-repeat clause is the filter at src/app/api/auto-match/route.ts lines 241 to 245. The pre-existing-condition clause is the paragraph on src/app/disclaimer/page.tsx lines 60 to 73. Nothing is hidden.

Out of scope, by design. The agreement described on this page is entirely about the partnership infrastructure: who meets whom, when, over which link, for how long, and how exit works. It does not cover anything about how to practice, how to sit, or how to handle what arises in a session. For those questions, the only honest redirect is to dhamma.org and to an authorized assistant teacher at a 10-day residential course. The runtime here has no opinion about your sits and no way to coach you through one. It has an opinion about whether the Meet URL is getting clicked.