AI Powerhouse · flow-based maintenance AI

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

2 · Category chosen by the user (final classification)

Send via async queue (worker + poll, like production)

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.

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.

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)

Our model — vision · card & training

No model trained yet.
Import the mock samples (or ingest real labeled photos), then press Train.

Add a labeled sample (/ingest)

Every real submission already carries the user's category (§3.2), so labels are free. This form mimics that.

tap to choose a photo

Label (user category)

Learn from AI — self-training loop

When ON, every analyzed photo becomes a training sample: the user's category (ground truth) or the answering AI's verdict (GPT / Gemini / Ollama teaches the own model). With auto-retrain the model gets smarter day by day — data by data.

Learn from AI answers (master toggle) Use the user's category as a label (free ground truth)

Teacher source

Min teacher confidence Auto-retrain after N (0 = manual)

LEARNING MONITOR

…loading

Model versions — capability history

Every training run is versioned; watch accuracy and coverage grow as data flows in.

no versions yet

ML diagnostics — where it's confident vs confused

Cross-validated: every sample is scored on a fold the model didn't train on. The confusion matrix (rows = true class, columns = predicted) shows exactly which classes get mixed up — that tells you what to label next.

train the model to see diagnostics

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

Autonomy — self-improving, safely

The model retrains itself as new labels arrive, but a new version only goes live if it beats the current champion on a frozen golden test set — so it can run unattended and never regress. Rejected challengers are kept for history, not deployed.

loading…

Our model — text · card & training

No text model trained yet.
Add a few example questions per intent (with an answer), then Train.

Add a training example (intent + answer)

Group example phrasings under an intent; give the intent an answer. The model learns to map new questions to an intent and reply with its answer; unsure → it hands off to the LLM (per the Chat flow).

Example question

Intent label

Answer for this intent (set once per intent; reused)

INTENTS & ANSWERS

none yet

Teach from a document (2nd way)

You don't have to write every Q&A. Upload a PDF / TXT / MD and its text is added to the company knowledge the chatbot answers from — the Own Model · Text node uses trained intents first, then this knowledge, then hands off to the LLM. (Two-way learning: precise intents and broad documents.)

tap to choose a PDF / TXT / MD

Knowledge on file: 0 chars · edit the raw text anytime on the Integrations page.

ML diagnostics — where it's confident vs confused

Cross-validated confusion matrix for the intent model (rows = true intent, columns = predicted). Shows which questions get mixed up — same analysis as the vision model.

train the text model to see diagnostics

Self-learning & autonomy — the chatbot teaches itself

When an LLM answers a question the model didn't know, it remembers the Q&A (and matches future paraphrases). It re-studies as it learns, and a new version only goes live if it beats the champion on a frozen golden set — the same safety gate as vision.

loading…

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.

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.

COMING SOON

Slack

alerts + slash-command analysis

Planned: incoming-webhook notify channel and an /analyze slash command.

CRM / any system — HTTP API

available NOW

Any CRM, portal or app integrates today over the token-secured API. Full reference + token generator on the API & Tokens page.

OFF

Main system — where we send events (webhook + reconcile)

push every interaction (messages, analyses, tickets, approvals) to your central system; it can also pull to reconcile

The powerhouse is a middleware: it POSTs signed events to your main system so everything is logged centrally, and your main system relays agent replies back via POST /api/send and toggles bot/human with POST /api/conversations/mode. Full event schemas + verification are on the API & Tokens page.

Webhook URL (your main system's receiver)

Signing secret (HMAC-SHA256; verify X-Powerhouse-Signature)

Timeout (s)
Max retries

Push events to the main system

MANUAL

Maintenance photo mode

what happens after a user sends a maintenance photo on Telegram / WhatsApp

Off — Manual (V1): the AI shows its analysis, then the user taps a category → sub-category to classify the issue and get the price.
On — Auto-detect (V2): the model/VLM auto-detects the type + estimated price + timeline from the image and shows it for one-tap confirm (the user can still correct it; the HOD verifies). Auto-detect is smartest when a cloud vision provider is enabled (it can pin the exact sub-category); with the own model alone it detects the category and shows the category's price range.

Auto-detect the maintenance type & price from the photo (V2)

WHISPER

Voice → text (transcription)

how a Telegram / WhatsApp voice note is turned into text before the chatbot answers

Voice notes are transcribed then fed into the same chat flow as typed text. Engines run strongest-first with a quality gate — a garbled result rolls to the next: Azure gpt-4o-transcribe-diarize (best for unclear audio, Malay pasar slang & mixed Malay+English in one clip) → OpenAI whisper-1 (your Cloud Keys) → local faster-whisper (offline). Leave Azure blank to keep whisper only.

Azure endpoint (AI Foundry / Azure OpenAI resource URL)

Azure API key (stored masked; rotate it if it ever leaks)

Deployment / model
API version

Use Azure first (off = whisper-1 first, Azure as fallback) Best-of-all (run every engine, keep the best transcript — most robust, costs more per clip) Label speakers (prefix “Speaker A:/B:” when a clip has 2+ voices)

Company knowledge (the chatbot's brain)

paste your company info — the chat flow answers grounded in this, whether the Local LLM or Cloud LLM node handles it

Applies immediately to /chat, the Telegram bot and /api/chat. In mock mode the reply is stubbed but shows the knowledge is wired in; real answers need MOCK_MODE=false.

Assistant playground (POST /chat)

runs the Chat flow (Local LLM → Cloud LLM) with your company knowledge — the same brain the Telegram bot uses

say something…

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

From a ticket (optional — pulls its image + the AI's answer)

Or upload the image the AI got wrong

AI's previous answer

Correct answer (name a known type, e.g. “Plumbing → Pipe leak”, to auto-teach the model)

Correct category (key, optional)

Correct sub-type (key, optional)

Remarks

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.

Where do I put my main system's URL?

Paste your main system's receiver URL (+ signing secret) in the global webhook setting — that's where we POST every event. You can also set a per-module webhook (Bot Modules) or pass callback_url per API request, but the global one is the simplest place to start.

checking current webhook…

What we send → you

Your main system builds ONE endpoint to receive our events — any URL/path that accepts a JSON POST and returns 2xx, e.g. POST https://your-system.com/powerhouse/webhook. Then you tell us that URL and we push events to it. There is nothing to "call" to receive — you host the receiver, we deliver to it.

Where to register your URL (any/all — we try them in this order):
① Per request — pass callback_url on /api/message or /api/maintenance
② Per module — the module's webhook URL (Bot Modules page)
③ Global — Integrations → main-system events (one webhook for all traffic) — set the URL + secret and hit “send test”.

The HOD approval loop (the important one):
1. User confirms an issue → we POST you maintenance.request.submitted = image ref + classification + price + timeline + the full chat session + ticket_id.
2. Your HOD system decides, then calls us back: POST /api/maintenance/{ticket_id}/approval with {date, agent, property_type, notes}.
3. We auto-notify the end user on their channel and POST you ticket.approved.

Every POST is signed: header X-Powerhouse-Signature: sha256=HMAC(rawBody, yourSecret) — verify it before trusting the body. If your endpoint was down, pull anything missed with GET /api/events?since=<cursor>.

Envelope — every event is wrapped the same way; the event-specific fields live in data. request_id equals the ticket_id for maintenance events, so you can correlate a chat → its analysis → its ticket → its approval. Each event below expands to its full JSON payload.

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)

auto-refresh (2s) full container logs: docker compose logs -f api worker

loading…

Analyze

1 · Photo of the issue

3 · AI analysis (supporting signal for HOD approval)

Live node monitor

Pattern discovery — clusters over all analyzed photos

Duplicate incidents (near-identical reports)

Brain export / import — move training between machines

Our model — vision · card & training

Add a labeled sample (/ingest)

Learn from AI — self-training loop

Model versions — capability history

ML diagnostics — where it's confident vs confused

Review queue — active learning

Autonomy — self-improving, safely

Our model — text · card & training

Add a training example (intent + answer)

Teach from a document (2nd way)

ML diagnostics — where it's confident vs confused

Self-learning & autonomy — the chatbot teaches itself

Telegram Bots OFF

WhatsApp Sessions OFF

Slack

CRM / any system — HTTP API

Main system — where we send events (webhook + reconcile)

Maintenance photo mode

Voice → text (transcription)

Company knowledge (the chatbot's brain)

Assistant playground (POST /chat)

log feedback

history

Access & authentication — two separate keys

Third-party API — connect any system

API access tokens

Endpoints you call → us

Where do I put my main system's URL?

What we send → you

System status — is everything wired up?

Security — admin token

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

Analyze

1 · Photo of the issue

3 · AI analysis (supporting signal for HOD approval)

Live node monitor

Pattern discovery — clusters over all analyzed photos

Duplicate incidents (near-identical reports)

Cluster

Brain export / import — move training between machines

Our model — vision · card & training

Add a labeled sample (/ingest)

Learn from AI — self-training loop

Model versions — capability history

ML diagnostics — where it's confident vs confused

Review queue — active learning

Autonomy — self-improving, safely

Our model — text · card & training

Add a training example (intent + answer)

Teach from a document (2nd way)

ML diagnostics — where it's confident vs confused

Self-learning & autonomy — the chatbot teaches itself

Telegram Bots OFF

WhatsApp Sessions OFF

Slack

CRM / any system — HTTP API

Main system — where we send events (webhook + reconcile)

Maintenance photo mode

Voice → text (transcription)

Company knowledge (the chatbot's brain)

Assistant playground (POST /chat)

Create bot

Create session

WAHA (self-hosted, scan a QR)

Official Meta WhatsApp Cloud API

Ticket

log feedback

history

Feedback

Access & authentication — two separate keys

Third-party API — connect any system

API access tokens

Endpoints you call → us

Where do I put my main system's URL?

What we send → you

System status — is everything wired up?

Security — admin token

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

Machine learning in this system

Create module

Confirm

Assign module

How the Own Model works

Structure

How to train the vision side (Model Lab → Vision)

How to train the text side (Model Lab → Text) — two ways

Where the data / "brain" lives

Getting smarter