customer photo

Analyze

ai-powerhouse
indexed 0 · dedup 0 loading… …

1 · Photo of the issue

Tap to take / choose a photo
or drag & drop it here

JPG / PNG · blurry or dark photos are rejected automatically
preview

3 · AI analysis (supporting signal for HOD approval)

Upload a photo and press Analyze.
The photo walks the flow you built in the Flow Editor — every hop is shown live.
Analyzing… 0.0s

    Scale
    Description
    Matches user
    raw JSON
    Drag a node from the toolbar onto the canvas · drag between ports to wire (answered / failed) · click a node to configure it · drag empty canvas to pan · scroll / pinch / the buttons to zoom.
    Nodes
    100%
    ● unsaved changes

    Live node monitor

    Pattern discovery — clusters over all analyzed photos

    Clusters group visually similar reports (k-means, auto-k). Reporting signals only — they never change any task's classification. Click a cluster to see all its photos.
    No clusters yet — analyze a few photos, then press Re-cluster now.

    Duplicate incidents (near-identical reports)

      No duplicate groups yet — upload the same photo twice to create one.
      One Own Model, two sides — train each so it gets smarter.

      Retrieval — what the chatbot is told before it answers

      The chatbot used to receive the entire knowledge base and the entire rate card on every message. Now it receives only the facts the question is about, retrieved from an index of three sources: the company knowledge, every job on the rate card (with the symptom words customers actually type), and what has really been reported. Measured at a 68% smaller prompt with a realistic knowledge base — and the gap widens with every fact you write down.

      …loading
      TRY A QUESTION

      A wrong answer is usually a retrieval problem, not a model problem. This is where you see which it was.

      Token savings — how much the brain answers itself

      Every photo is answered one of three ways. Dedup reuses the verdict of a near-identical photo, own model answers from what it has learned, and cloud sends it to a paid engine. Only the last one costs money, so this is the number to drive down — and it is measured from what was actually recorded, not from a counter kept alongside it.

      …loading
      CAN IT BE TRAINED YET?
      …
      HARVEST PAST ANSWERS

      Photos the cloud has already analysed still carry its verdict. This turns those into training samples — counting distinct faults, not photos, so one leak sent fifty times does not drown out everything else. Safe to run repeatedly.

      Chat photos — confirm or correct the AI

      Every photo a customer has sent, newest first, with what they wrote alongside it and what the model concluded. Confirming or correcting one teaches the model straight away: the exact job goes into the confirmation memory for instant precision, and the category becomes a weighted training sample — a correction counts for more than another easy example, because it teaches the model what it got wrong. The queue below only shows what the brain was unsure about; this shows everything.

      loading…

      Review queue — active learning

      The brain flags photos it was unsure about, or where it disagreed with the AI that answered. Confirm the real type here — these are the highest-value labels, and they feed straight back into training as weighted corrections.

      nothing to review yet

      Brain export / import — move training between machines

      Train on one machine, carry the whole brain to another (staging / prod) — no retraining. Export bundles the trained vision + text models, their training data and the company knowledge into one .tar.gz. Secrets (API tokens, bot config) are never included. Keep the same embedding backend on both ends.

      — or —
      choose a brain file (.tar.gz)
      The powerhouse is a framework, not just a console: connect chat platforms here, or integrate any system (CRM, portal, app) through the HTTP API (API & Tokens page). Everything below is configured HERE — no .env edits, no rebuild.

      Booking page address

      Where /book/<link> is served, as the customer can reach it — not as this server knows itself. Bots using the Booking page capability send people here.
      Leave it empty and the bot stops offering a page: it logs the request and tells the customer the team will be in touch. That is deliberate — a link nobody can open is worse than no link.

      Telegram Bots OFF

      Run many bots — each with its own module (scope + language). Toggle a card to activate; the icons view · edit · delete it.
      How to set up a bot (2 minutes)
      1. In Telegram, open @BotFather → /newbot → copy the token.
      2. Click Create bot, paste the token, pick a module, press Save, then flip it Active.
      3. Test connection (in the edit dialog) shows your bot's username.
      4. Open your bot, send any message, then a photo of a maintenance issue — the analysis comes right back.
      5. Optional: set a chat id so flow Notify nodes can ping you.
      A Bot Module decides which capabilities a bot offers — About/company, Property search, Investment calculator, Maintenance, Feedback. Create modules here, then assign one to each bot. Every bot runs exactly one module (assigning a module to a bot moves it off its previous one); a bot with no module = the full assistant (all capabilities). You can assign two ways — from a module (its Assign button → pick bots) or from a bot (the Bot assignments tab, or the module dropdown on each bot in Integrations).
      Your modules — create, edit, assign, or delete.
      Maintenance requests submitted for HOD approval. Each confirmed issue becomes a ticket pushed to your main system (maintenance.request.submitted). When the main system approves via POST /api/maintenance/{id}/approval, the user is auto-notified on their channel.
      Log a correction when the AI's answer to a photo was wrong. Each feedback is stored, pushed to your main system (feedback.submitted), and — when the correct answer maps to a known type — teaches the model so it improves. A Telegram bot with the Feedback module does the same over chat (send the photo → previous answer → correct answer → remarks).

      log feedback

      history

      A multi-LLM AI router: add one or many cloud keys (OpenAI, Groq, OpenRouter, Gemini, Claude, DeepSeek, Cerebras, Mistral, Cohere…), test each, set a per-key rate limit, and drag to set priority. The vision & chat engines walk the enabled keys top-to-bottom — the first that answers wins, and on a rate-limit / expired key / failure the router falls back to the next key in line. Keys live in the DB (not .env), stored masked; edits take effect with no rebuild. Text-only providers are skipped for photo analysis.
      loading providers…

      Access & authentication — two separate keys

      This system has two distinct auth mechanisms, for two audiences:
      1. Dashboard key (for people) — logs you into this console/dashboard. Sent as header X-Dashboard-Key; the login screen stores it in your browser. Set it server-side with DASHBOARD_KEY. Covers every console page & endpoint (analyze, model, flow, clusters, integrations, debug…). Leave blank = open console.
      2. API bearer tokens (for machines) — for external systems (CRM, portal, app) calling the /api/* endpoints. Sent as Authorization: Bearer aip_…, generated & revoked below, stored hashed. These are independent of the dashboard key.
      3. Admin token (optional extra) — if ADMIN_TOKEN is set, config/training writes also need X-Admin-Token (set it on Logs & Status → Security).
      Open to everyone: GET /health and the WhatsApp webhook (own verify token). Everything else needs the dashboard key.

      Third-party API — connect any system

      Base URL http://localhost:8090 · /api/* calls require Authorization: Bearer <token> (generate one below) · uploads are multipart/form-data · responses JSON.
      Interactive spec: Swagger UI /docs · openapi.json (these are behind the dashboard key). Typical CRM flow: POST /api/analyze-async → store job_id → poll GET /api/result/<job_id> → save the verdict on the ticket.

      API access tokens

      Tokens are stored hashed — the secret is shown once, here, at creation. Give each integration its own token so you can revoke them independently.
      New token — copy it now, it will not be shown again:
      Full endpoint & webhook reference is split across the tabs above: ② Endpoints you call (the requests your system makes to us) and ③ What we send you (the webhook events we push to your system) — each with method, full request body, an example call, and the complete JSON response.

      System status — is everything wired up?

      loading status…

      Security — admin token

      When the server is started with an ADMIN_TOKEN, changing configuration or training (flow, providers, learning, train, recluster, tokens, integrations) requires it. Paste it here once — it's stored in this browser only and attached automatically to those requests. Read-only viewing never needs it. Leave blank if the server has no token set.

      Live logs (api + worker, newest at the bottom)

      full container logs: docker compose logs -f api worker
      loading…