TERRA-22 screening instrument: inter-login interval near 60min on signInCompleted
Screening instrument for TERRA-22 (silent logout ~1h). Zero code change required: signInCompleted already writes actorUserId as a typed column (auth/callback/route.ts:136; the authorized return at :333 passes appUser.id), measured by coder-terra-cc 2026-08-16. SIGNAL: for one actorUserId, the interval between consecutive signInCompleted rows. TERRA-22 mechanism predicts a TIME, not merely a repeat: jwt_exp=3600, so silent-logout re-logins cluster near 60 minutes after the prior login. A second-device or ordinary re-login has no such clustering. That is what separates them - appEvents carries no host, session id or user-agent, so interval is the only discriminator available, and it works at n=1. MANDATORY CONTROL, file it with any threshold: before reading anything from the interval distribution, count inter-login intervals of ANY length for ANY actor. Only ~3 users have ever logged in, so a zero at ~60min may mean no repeat interval exists at all. Zero = instrument unexercised, NOT defect absent. Same structural-zero trap the TERRA-22 falsifier query hit. CARRIED CONSTRAINT: appUser.id is terras user id, not the Supabase auth id. Do not join it auth-side without checking first. NOT A SUBSTITUTE FOR TERRA-19. This measures that a user re-authenticated; only TERRA-19 measures that the cookie write threw. Two instruments, two claims. ARMING: not worth monitoring at the current cohort (163 of 166 memberships have never logged in). Becomes meaningful when the cohort arrives. Sits on the appEvents plane, which is the only plane the applog rail watches - unlike TERRA-19, which writes to a plane no project has a rail on.
Questions
Activity
-
RAN, CONTROLLED, AND THE ANSWER IS THAT THIS INSTRUMENT CANNOT DETECT TERRA-22. Closed on that verdict rather than left open, because leaving it open implies it might yet produce a signal and it cannot at this population. BASELINE, read-only, coder-terra-cc 2026-08-16: 13 signInCompleted rows carrying actorUserId, 3 actors, 10 inter-login intervals. ZERO in the 50-75 minute band. Min 0.7min, median 342min, max 6985min. The mandatory control is SATISFIED - 10 intervals of arbitrary length exist, so the query can return rows and the zero is real rather than structural. THE ZERO IS UNINFORMATIVE ANYWAY, AND THE REASON IS IN THE PREMISE, NOT THE EXECUTION. The interval this measures is (time until the session dies) PLUS (time until the user next visits). It clusters near 60min only for a user actively browsing ACROSS the expiry boundary. The three real sub-hour intervals are 33.9 / 24.5 / 20.4 min, all one actor on 07-30, all SHORTER than jwt_exp - nobody in this population browses across the boundary. So the band being empty says nothing about TERRA-22 in either direction. The instrument was correctly built against a premise that does not hold here. THE FIRST VERSION RETURNED A FALSE ZERO, and this is the half worth carrying. The query filtered categoryValue = signInCompleted. The event name lives in `action`; categoryValue is the coarse bucket, `auth`. Result was zero logins, zero actors, zero everything - and it looked exactly like a clean answer. Only the control caught it. Same trap as the TERRA-19 falsifier query, hit by the same lane one day later, which makes it a property of the appEvents schema shape rather than of one query: a wrong column name here produces an empty set, never an error. CONSEQUENCE FOR TERRA-22, which is why this closes rather than blocks: there is no before/after reading available. A post-fix run returns the same zero as the pre-fix run. TERRA-22 must therefore be verified by its own mechanism, not by this screen. DOES NOT AFFECT TERRA-30, which stays open on its own terms - signInCompleted attributes only 13 of 21 rows. That gap would have narrowed this instrument further had the premise held, and it still narrows anything else built on actorUserId.