InSaiT

Canonical registry

The 10-app ecosystem map the copilot uses.

This registry is the grounded source for interview answers, API explanations, HUD cue context, and future GitHub retrieval. Repo contents are not indexed yet, so code-level claims stay out of the AI layer.

XFlow

Automationinternal alpha

XFlow is the ecosystem coordination layer: it should help events move between products, expose operator visibility, and make automation decisions explainable.

I would describe XFlow as a control-plane pattern: app events enter a normalized routing layer, decisions are logged, and operators can inspect or replay outcomes.

Features

route builder
event ingest
operator dashboard
request tracing

Routes

/dashboard/glasses-copilot/routes
/dashboard/glasses-copilot/routes/events
/dashboard/glasses-copilot/routes/fires

APIs

/api/glasses/events/ingest
/api/glasses/routes
/api/glasses/route-fires

Auth

Owner-scoped dashboard auth; production should use Supabase JWT verification.

Billing

No direct billing model in this dashboard yet.

Risks

GitHub indexing is not connected yet
event schemas need app-by-app hardening
operator actions need audit trails

Verixet

SaaS platformprototype

Verixet is positioned as the business control system for customers, subscriptions, billing state, and access rules across products.

I would frame Verixet as the governance and entitlement boundary: billing state becomes explicit product access rather than scattered checks.

Features

customer state
billing status
entitlement checks
governance views

Routes

/dashboard/glasses-copilot/costs
/dashboard/glasses-copilot/routes/secrets

APIs

/api/glasses/costs/summary
/api/glasses/app-secrets

Auth

Supabase JWT model expected for owner/admin access.

Billing

Stripe-oriented billing model; exact production integration should be verified from repo source.

Risks

billing implementation must be verified before claims
entitlement rules need tests
customer lifecycle needs auditability

Rataify

Decision intelligenceneeds review

Rataify should centralize rating logic, score explanations, and decision confidence so the ecosystem can make trustable choices.

I would explain Rataify as a decision-support system: inputs become scored signals, and the product must show why a score exists.

Features

rating workflows
score explanations
review queues
confidence summaries

Routes

/dashboard/glasses-copilot/app-registry

APIs

TBD: repo indexing needed before naming real APIs

Auth

Expected authenticated workspace/admin access.

Billing

Unknown until app repo is connected.

Risks

source repo not indexed
domain rules need clarification
score explanations must avoid false certainty

AudAiX

Audio AIprototype

AudAiX should support audio capture and interpretation workflows that can feed products like the glasses copilot.

I would describe AudAiX as the audio ingestion boundary: it captures speech, turns it into structured context, and hands that context to AI workflows.

Features

audio capture
transcript chunks
speaker-aware context
voice workflow triggers

Routes

/dashboard/glasses-copilot/realtime
/dashboard/glasses-copilot/conversation

APIs

/api/glasses/audio/chunk
/api/glasses/realtime/token
/api/glasses/conversation/analyze

Auth

Owner dashboard auth today; production voice sessions need stricter user/session boundaries.

Billing

Usage-based cost tracking is expected for model/audio calls.

Risks

privacy/consent must stay explicit
latency budgets need real measurements
audio capture varies by device/browser

Crevux

Creative AIprototype

Crevux is the media-generation part of the ecosystem, focused on creative workflows, asset production, and render operations.

I would explain Crevux as an asynchronous media workflow: requests become jobs, jobs produce assets, and operators need visibility into cost and state.

Features

media generation
asset review
render status
creative workflow history

Routes

/dashboard/glasses-copilot/routes/events

APIs

/api/glasses/events/crevux

Auth

Authenticated creator/operator access expected.

Billing

Likely usage-based due to generation cost; exact implementation needs repo verification.

Risks

generation cost controls
asset ownership metadata
queue/retry behavior

WordGeni

Content AIprototype

WordGeni sits in the content layer, producing structured writing outputs that can be reviewed, reused, and routed through the ecosystem.

I would frame WordGeni as a generation workflow, not just a text box: prompts, templates, review state, and cost controls are first-class concerns.

Features

content generation
template workflows
revision variants
campaign copy

Routes

/dashboard/glasses-copilot/prompts

APIs

/api/glasses/events/wordgeni
/api/glasses/prompts

Auth

Authenticated creator/admin access expected.

Billing

Usage/cost tracking expected for model calls.

Risks

prompt versioning discipline
quality evaluation
usage cost controls

JournOwl

Personal knowledgeneeds review

JournOwl should help users capture entries, summarize patterns, and retrieve personal context when needed.

I would explain JournOwl as a privacy-sensitive memory product where capture, summarization, and retrieval must be designed around user trust.

Features

journal capture
summaries
memory retrieval
reflection prompts

Routes

/dashboard/glasses-copilot/notes
/dashboard/glasses-copilot/sources

APIs

/api/glasses/import/note
/api/glasses/sources

Auth

Private user auth with strong data isolation required.

Billing

Unknown until product repo is connected.

Risks

privacy sensitivity
data export/deletion
retrieval quality

UrSite

Web publishingneeds review

UrSite is the publishing layer for creating, customizing, and launching web pages or brand sites.

I would describe UrSite as a publishing workflow where editing, preview, and deployment state need to be explicit and recoverable.

Features

site templates
content editing
preview/publish workflow
brand customization

Routes

/dashboard/glasses-copilot/import

APIs

TBD: repo indexing needed before naming real APIs

Auth

Authenticated owner/editor access expected.

Billing

Likely subscription or project-based; verify from repo before claiming.

Risks

publishing pipeline clarity
custom domain handling
template quality

PitStrike

Interactive experienceneeds review

PitStrike needs repo context before making firm implementation claims; in the registry it is tracked as an interactive app in the ecosystem.

I would be honest that PitStrike needs source indexing before claiming details; the senior framing is to identify its state model and interaction loop first.

Features

interactive sessions
stateful actions
score/status surfaces

Routes

/dashboard/glasses-copilot/app-registry

APIs

TBD: repo indexing needed before naming real APIs

Auth

Unknown until source is connected.

Billing

Unknown until source is connected.

Risks

domain rules need clarification
runtime architecture unknown
state model unknown

1ofakindpiece

Commerceneeds review

1ofakindpiece appears to be the unique-product commerce layer; exact features need repository verification before implementation claims.

I would frame 1ofakindpiece around commerce correctness: product state, inventory, checkout, and order lifecycle need clear boundaries.

Features

product presentation
inventory state
checkout path target
storytelling around items

Routes

/dashboard/glasses-copilot/app-registry

APIs

TBD: repo indexing needed before naming real APIs

Auth

Buyer/admin access model needs repo verification.

Billing

Likely Stripe/checkout if commerce is active; do not claim until indexed.

Risks

checkout details unknown
inventory consistency
order lifecycle

InSAiT Glasses Copilot

Live interview copilot / glasses HUD / phone bridgeinternal alpha

InSAiT Glasses Copilot is the platform surface for Live Copilot, Interview Prep, Translator, Knowledge Hub, Phone Bridge PWA, Proof Lab, Operations, and browser/mock ring controls. It is demo-safe locally today; production safety still requires DB, GitHub OAuth, migrations, secrets, and deployment proof.

I would explain InSAiT as a real-time technical conversation copilot: it detects the app/context, generates short senior-dev cue responses, sends them to browser or phone display targets, and keeps proof/readiness honest about what is real, simulated, or pending.

Features

Live Copilot
Interview Prep
Translator
Knowledge Hub

Routes

/dashboard/glasses-copilot/hud
/dashboard/glasses-copilot/interview
/dashboard/glasses-copilot/translate
/dashboard/glasses-copilot/knowledge

APIs

/api/glasses/live/cue
/api/glasses/live/detect
/api/glasses/bridge/send
/api/glasses/bridge/messages/pending

Auth

Local dev allows owner fallback; production requires owner-scoped auth and server-side GitHub token handling.

Billing

No production billing is claimed for this platform yet; cost and readiness surfaces exist for proof and planning.

Risks

Supabase persistence must stay configured and migrations must be verified
GitHub OAuth/token encryption must be configured before production repo knowledge
Even G2 is a readiness layer only and is not connected
Phone Bridge is a PWA companion, not a native app yet