InSaiT

API Explorer

Known route and API surfaces by app.

This is registry-based API context, not live repository indexing. It is safe for interviews because unknowns are marked as unknown.

XFlow

Workflow automation and operator control plane

internal alpha

Known routes

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

Known APIs

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

Auth model

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

Billing / entitlement

No direct billing model in this dashboard yet.
Future routes should respect app-level entitlements before firing actions.

Interview explanation

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.

Verixet

Governance, billing, and entitlement management

prototype

Known routes

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

Known APIs

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

Auth model

Supabase JWT model expected for owner/admin access.

Billing / entitlement

Stripe-oriented billing model; exact production integration should be verified from repo source.
Entitlements should derive from subscription/customer state.

Interview explanation

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

Rataify

Ratings, evaluation, and trust signals

needs review

Known routes

/dashboard/glasses-copilot/app-registry

Known APIs

TBD: repo indexing needed before naming real APIs

Auth model

Expected authenticated workspace/admin access.

Billing / entitlement

Unknown until app repo is connected.
Unknown until app repo is connected.

Interview explanation

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

AudAiX

Audio intelligence and voice workflows

prototype

Known routes

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

Known APIs

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

Auth model

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

Billing / entitlement

Usage-based cost tracking is expected for model/audio calls.
Audio features should be gated by plan/session permissions.

Interview explanation

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

Crevux

Media generation studio

prototype

Known routes

/dashboard/glasses-copilot/routes/events

Known APIs

/api/glasses/events/crevux

Auth model

Authenticated creator/operator access expected.

Billing / entitlement

Likely usage-based due to generation cost; exact implementation needs repo verification.
Generation limits should map to plan or credit state.

Interview explanation

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

WordGeni

Growth content and writing generation

prototype

Known routes

/dashboard/glasses-copilot/prompts

Known APIs

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

Auth model

Authenticated creator/admin access expected.

Billing / entitlement

Usage/cost tracking expected for model calls.
Prompt and generation access should map to plan limits.

Interview explanation

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

JournOwl

Journaling, reflection, and personal knowledge

needs review

Known routes

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

Known APIs

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

Auth model

Private user auth with strong data isolation required.

Billing / entitlement

Unknown until product repo is connected.
Personal memory features should be user-scoped and plan-gated if monetized.

Interview explanation

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

UrSite

Website and landing page builder

needs review

Known routes

/dashboard/glasses-copilot/import

Known APIs

TBD: repo indexing needed before naming real APIs

Auth model

Authenticated owner/editor access expected.

Billing / entitlement

Likely subscription or project-based; verify from repo before claiming.
Publishing/custom domain features should map to plan access.

Interview explanation

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

PitStrike

Game, competition, or tactical interaction product

needs review

Known routes

/dashboard/glasses-copilot/app-registry

Known APIs

TBD: repo indexing needed before naming real APIs

Auth model

Unknown until source is connected.

Billing / entitlement

Unknown until source is connected.
Unknown until source is connected.

Interview explanation

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.

1ofakindpiece

Unique product, commerce, or collectible experience

needs review

Known routes

/dashboard/glasses-copilot/app-registry

Known APIs

TBD: repo indexing needed before naming real APIs

Auth model

Buyer/admin access model needs repo verification.

Billing / entitlement

Likely Stripe/checkout if commerce is active; do not claim until indexed.
Inventory and purchase permissions need verification.

Interview explanation

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

InSAiT Glasses Copilot

Local/dev live interview copilot, glasses HUD, and phone bridge platform

internal alpha

Known routes

/dashboard/glasses-copilot/hud
/dashboard/glasses-copilot/interview
/dashboard/glasses-copilot/translate
/dashboard/glasses-copilot/knowledge
/dashboard/glasses-copilot/operations
/dashboard/glasses-copilot/proof
/phone-bridge

Known APIs

/api/glasses/live/cue
/api/glasses/live/detect
/api/glasses/bridge/send
/api/glasses/bridge/messages/pending
/api/glasses/bridge/messages/ack
/api/glasses/github/index
/api/glasses/retrieval/test
/api/glasses/runtime/readiness
/api/glasses/deployment/proof

Auth model

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

Billing / entitlement

No production billing is claimed for this platform yet; cost and readiness surfaces exist for proof and planning.
Demo tools require Supabase persistence; production entitlements must be DB-backed and verified before deployment claims.

Interview explanation

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.