Synchronicity detection discovers meaningful temporal co-occurrence patterns across anonymized user profiles. Inspired by Carl Jung’s concept of synchronicity — “meaningful coincidences” that are not causally related — this subsystem finds patterns that emerge organically from collective tool usage.
Synchronicity detection uses pure SQL analysis with no LLM calls. It operates entirely on the temporal_events table and stores discovered patterns in gut_patterns with pattern_type='synchronicity'.
Every tool call and observation is recorded as a temporal event. Events are collected in a fire-and-forget manner — failures never block the critical path.
Copy
User invokes tool | vRecord temporal event (async, non-blocking) | vtemporal_events table: - profile_hash (HMAC-SHA256, never raw UUID) - tool_name - event_type - outcome (success/failure/null) - context_hash (optional) - created_at
Only profile_hash is stored — never the raw profile UUID. This ensures that individual usage patterns cannot be traced back to specific users, even by database administrators.
The synchronicity detector runs three independent analyses in parallel:
Co-occurrence
Failure Correlation
Emergent Workflows
What it finds: Tool pairs that are frequently used together within a short time window.Algorithm:
Identify active tools (those with >= 10 events in the last 30 days)
Use SQL window functions (LEAD) to find sequential tool pairs within the same profile session
Filter to pairs where the gap between uses is less than 5 minutes
Group by tool pair and count distinct profiles
Only surface patterns observed by 3+ unique profiles (k-anonymity)
Example output: “After using pluggedin_memory_search, users frequently use pluggedin_memory_details (47 profiles)”SQL core logic:
Copy
WITH sequences AS ( SELECT tool_name, LEAD(tool_name) OVER ( PARTITION BY profile_hash ORDER BY created_at ) as next_tool, LEAD(created_at) OVER (PARTITION BY profile_hash ORDER BY created_at) - created_at as gap FROM temporal_events WHERE created_at > NOW() - INTERVAL '30 days')SELECT tool_name, next_tool, COUNT(DISTINCT profile_hash) as unique_profilesFROM sequencesWHERE gap < INTERVAL '5 minutes'GROUP BY tool_name, next_toolHAVING COUNT(DISTINCT profile_hash) >= 3
What it finds: Tools that have high failure rates at specific times of day or days of the week.Algorithm:
Group events by tool, day-of-week, and hour-of-day
Calculate failure rate per group
Filter to groups where failure rate exceeds 50%
Only surface patterns from 3+ unique profiles
Example output: “github_api_search has 73% failure rate on day 1 (Monday) hour 9 (15 profiles, 42 events)”Use cases:
Detecting API rate-limit windows
Identifying maintenance-related outages
Finding time-of-day reliability patterns
What it finds: Three-tool sequential patterns that recur across multiple profiles.Algorithm:
Use SQL LEAD with offset 1 and 2 to capture three-step sequences
Filter to sequences where total gap is under 15 minutes
Synchronicity detection uses PostgreSQL advisory locks to prevent concurrent runs:
Copy
// Only one detection can run at a timeconst lockResult = await db.execute( sql`SELECT pg_try_advisory_lock(738203) as acquired`);if (!lockResult.acquired) { return { error: 'Synchronicity detection already running' };}
When the temporal events table exceeds 1,000,000 rows, the detector automatically uses TABLESAMPLE BERNOULLI(1%) to sample the data. This keeps analysis time constant regardless of table size while maintaining statistical accuracy.
In most cases, temporal events are recorded automatically by the memory system during observations. You only need to call this endpoint directly if building custom integrations.
