here's Claude's response 😆 --- Thanks for the follow-up! This is a slightly different issue than the general pattern - it looks like a type inference problem with type aliases. Let me help debug this. The Issue When you use a type alias like type SessionCollection = Collection, string>, TypeScript may not fully preserve the generic parameters through method calls, causing sessions.insert() to return Transaction> instead of Transaction>. Solution: Make the function generic // ✅ Instead of using a type alias parameter function startSession>( sessions: Collection ) { const newSession: T = {} as T; const transaction = sessions.insert(newSession); // transaction should now be properly typed as Transaction return { transaction, newSession }; } // Usage - TypeScript infers T from the collection const result = startSession(electricSqlCollection) // T = Tables<'session'> const result2 = startSession(queryCollection) // T = Tables<'session'> Alternative: Type assertion if you're sure type SessionCollection = Collection, string>; function startSession(sessions: SessionCollection) { const newSession: Tables<'session'> = {} as Tables<'session'>; const transaction = sessions.insert(newSession) as Transaction>; // Now properly typed return { transaction, newSession }; } Questions to verify: When you hover over transaction in your IDE, does it actually show Transaction>? Are you able to access transaction.mutations[0].modified and does it have the wrong type? What version of TypeScript are you using? If the generic function approach doesn't solve it, this might be a type inference issue in the Collection interface that we should investigate. Can you try the generic approach and let me know if it works? Your use case (same data model, different collection implementations) is exactly what these patterns are designed for - good catch on finding this edge case! 🎯