Architecture · HuaHelp Insight Platform

BI as sensors. LLM as the analyst.
Consultants stay in the loop.

A three-layer diagnostic engine that turns dashboards into guided narratives — grounded in the same numbers the client sees, never generic advice.

System Flow

How a client metric becomes a consultant-approved insight

flowchart TD A["📊 Client Business Data
(ERP / CRM / spreadsheets)"] B["BI Dashboard
Metrics & KPIs
e.g. supplier_concentration = 0.35"] subgraph CONFIG ["🧑‍💼 Consultant Configuration (one-time, per theme)"] direction LR T["Theme Templates
• Procurement Risk
• Financial Health"] R["Rule Definitions
metric + threshold +
append_instructions"] T --> R end S{"⚡ Sensor Layer
Evaluate every rule
against live metrics"} L["📝 Anomaly Log
rule_id, metric value,
timestamp"] P["💉 Prompt Injector
append_instructions
targeted to triggered rule"] CTX["🧠 LLM Context
• Raw metric values
• Triggered rule instructions
• Theme template prompt"] LLM["🤖 LLM
Generate diagnostic summary
with concrete numbers"] DRAFT["📄 Draft Summary
Risk callouts +
recommended actions"] G{"👁️ Consultant Review
Human gate"} CLIENT["✅ Final Report to Client"] EDIT["✏️ Edit / Reject
back to draft"] A --> B B --> S R -.-> S S -- "threshold crossed" --> L S -- "threshold crossed" --> P L --> CTX P --> CTX B --> CTX T -.-> CTX CTX --> LLM LLM --> DRAFT DRAFT --> G G -- "approve" --> CLIENT G -- "needs changes" --> EDIT EDIT --> DRAFT classDef configBox fill:#F8F5EE,stroke:#C9A96E,stroke-width:2px,color:#6B5D3E classDef sensor fill:#FFFCE0,stroke:#C9A96E,stroke-width:2px classDef llm fill:#E0F7FA,stroke:#0097A7,stroke-width:2px classDef gate fill:#FED7D7,stroke:#9B2C2C,stroke-width:2px classDef final fill:#C6F6D5,stroke:#276749,stroke-width:2px classDef data fill:#EDF2F7,stroke:#4A5568 class A,B data class T,R configBox class S sensor class LLM,CTX,DRAFT llm class G gate class CLIENT final

Solid arrows = runtime data flow · Dashed arrows = configuration reference

Step by Step

The pattern in five steps

1

BI components act as sensors

Every chart, KPI, and table on the dashboard is also a measurement point. The platform reads metric values directly from the same data the user sees — no parallel data store, no stale snapshots.

2

Consultants pre-configure rules per theme

For each diagnostic theme — Procurement Risk, Financial Health, etc. — a consultant defines rules in the admin UI. Each rule has a name, a trigger condition tied to a BI metric (e.g. supplier_concentration ≥ 0.35), and a set of targeted instructions to inject when the rule fires.

3

Threshold crossed → anomaly logged + prompt augmented

When a metric value crosses its rule threshold, two things happen simultaneously: the anomaly is written to an audit log (rule id, value, timestamp), and the rule's append_instructions are inserted into the LLM's prompt context. Multiple rules can fire on the same report, stacking their instructions.

4

LLM generates summary grounded in the exact numbers

The LLM receives: the raw metric values currently displayed, the theme's base prompt template, and the triggered rules' targeted instructions. The output is a diagnostic summary with concrete numbers, specific risk callouts, and recommended actions — not generic advice from training data.

5

Consultant reviews before the client sees it

The draft routes to a consultant review queue. The consultant can approve, edit, or reject. Only approved reports reach the client. The LLM does the heavy lifting; a human is still the gate.

Why this design

Three principles built into the architecture

Grounded, not generic

The LLM sees the same numbers the client sees. No hallucinated metrics, no abstract advice.

Repeatable via rules

Consultant expertise is encoded once as rules + prompts, then runs across every client report consistently.

Human-in-the-loop by default

Every output passes a consultant review gate. AI accelerates; humans take accountability.