7 docs tagged with "helix"

Domain-level configuration

Helix spans two repos and several external services, which communicate with each other asynchronously via AWS SQS. Below are the two independent flows: getting a bot into a meeting and back with a transcript, and picking up calendar changes.

All Helix tables live in the main Hub database, modelled as dare ORM models in api/db/models/ (camelCase file names, e.g. helixMeeting.js, mapping to snakecase tables, e.g. helixmeeting). These model files are the authoritative schema reference for the helix_* tables.

The standalone helix repo is a small AWS Lambda service (AWS SAM, TypeScript, ESM). Its entire job is to get a bot into a meeting via a third-party vendor and forward whatever comes back to Hub over SQS — a deliberately thin, stateless design. See Why so thin? below.

Helix is 5app's AI agent that joins a user's meetings (Google Meet, Zoom, Microsoft Teams), passively listens, and turns the conversation into soft-skills feedback — a score and coaching-style summary per skill, delivered to the user and rolled up into team/domain analytics for L&D and managers.

Once a meeting transcript lands on HELIXSQSQUEUE_URL (see Architecture), api/modules/helixProcessing/processHelixData.js — the heart of Helix in Hub — turns it into per-user, per-skill scores. This page covers that pipeline, plus the weekly roll-up and manual reprocessing.

Every Helix trial prospect used to land in one shared hub, so they saw each other's data and none of them got the admin experience. Prospect can now gets a hub of their own, cloned from a seed hub that acts as the template. The old method still works for cases where they don't need admin.