NovizERP Assistant Demo implementation live

Noviz Pro architecture diagram

How Noviz is built — and how it keeps getting better

Three diagrams, from three different angles: the components that make up the system, what happens when an admin changes a setting or uploads a document, and the full path a single chat prompt takes on its way to becoming a validated answer. Each one ends the same way — every turn is logged with its rule outcome, rated with a tap, and rolled back into the pipeline as a sharper model or a fixed rule. Noviz isn't a static integration; it's a Pro agent that learns from its own operating history.

Diagrams are wide — scroll horizontally on a narrow screen, or view on a larger one for the full picture at once.

CLIENT 💬 Chat UI Composer — type, 📎 attach, 📷 camera Response renderer — tables, cards, documents One-click next-step / confirm buttons 🛠️ Admin Console LLM / ERP connection settings Policy document library Demo account provisioning HTTPS · Bearer session token BACKEND — REQUEST PIPELINE 🔑 Auth Session JWT issue/verify Per-user credential store (session cookie or API key — never a shared service login) Role list per person 🗂️ Context Assembler Hot: recent-turn cache. Warm: vector search over embedded policy docs + past turns. Cold: a record lookup, on request → fixed-budget context 🧠 Reasoning Engine Builds the prompt + tool list this person is allowed, drives the tool-call loop, formats the final answer + next-step suggestions 🔒 Gateway + Rule Engine Is this tool on THIS role's allow-list? → business-rule check (block / warn / pass), outcome logged, against the grid below refuses before any write 🔌 System Connector Canonical field names ↔ the ERP's native field names Calls out AS the signed-in person, not a shared account — its actions, its audit trail REST, impersonated 🏢 ERP System of Record Business data + its own permission rules — the final authority, external 👁️ Vision Extraction Photo of a bill/PO → plain text transcription only — never calls a create tool itself extracted text feeds in as a normal prompt 🔀 Workflow Engine Named status state-machines (e.g. qualify → convert), role-gated per transition 📊 Interaction Logger Every turn + tool call + rule outcome + 👍/👎 feedback — feeds the learning loop below ↓ 🔐 Credential Vault Admin-provisioned API keys, AES-256-GCM encrypted at rest — used by the Connector to impersonate BUSINESS MODULES — ONE CONFIG FOLDER EACH (ENTITIES · RULES · TOOLS) CRM Selling Buying Stock Accounting Assets HR & Payroll Manufacturing Quality Projects Support Analytics Every module here is one folder of plain config — entities.ts, rules.ts, training.ts — plus named reports (trial balance, stock ledger…): which entities exist, which fields map to the ERP's real fields, which actions need which role, what validation applies, and how it's curated for training. The Gateway + Rule Engine read this on every call; nothing is hardcoded per-module in the engine itself. read by Gateway on every tool call DATA STORE 🗄️ Postgres + pgvector Session cache · vector embeddings (policy docs, past turns) Encrypted credentials · connection settings · admin audit log interaction_log + rule_evaluations + 👍/👎 feedback — the training source One shared database — no separate vector store to run reads / writes EXTERNAL SERVICES CROSSES THE NETWORK BOUNDARY 🌐 LLM Provider Chat completions (tool-calling) + vision (document scanning) swappable — one interface, incl. your own fine-tune 🏢 ERP System of Record ERPNext today — SAP or any other system-of-record is a config swap, same System Connector interface reasoning + vision calls 🔁 THE LEARNING LOOP — NOVIZ GETS SHARPER FROM ITS OWN HISTORY Sourced from the Interaction Logger + rule_evaluations above — nothing here changes the pipeline's shape, only what's loaded into it. 1 · Every turn logged Prompt, tools called, which rule fired/blocked, latency — always on, day one 2 · 👍 / 👎 feedback One tap turns a raw log into a labeled example of a good or bad decision 3 · Curated into datasets Orchestration set (prompt→tool) + full-response set, deduped & stratified by role/module 4 · Fine-tune, or patch a rule A lightweight tool-router model, or a straight fix to a module's rules.ts / a policy document 5 · Rolls back in Swapped in behind the same LLMProvider / RolePolicy interface — core unchanged ↻ repeats every release — Noviz gets measurably better at YOUR ERP the more it's used, not just at launch

What this shows: a chat/admin client talks only to the backend's request pipeline over an authenticated session. That pipeline — auth, context assembly, reasoning, a role-and-business-rule gateway, then a system connector — is configured entirely by a flat grid of per-module folders (no per-module code inside the engine itself), backed by one shared Postgres/pgvector database, and reaches exactly two external systems: an LLM provider for reasoning and vision, and the ERP system of record for real business data — both swappable behind one interface each. The band at the bottom is what makes it a Pro agent rather than a static integration: every logged turn and rule outcome becomes a labeled example, gets curated, and either fine-tunes a small routing model or patches a rule/policy doc — then rolls back in behind the exact same interfaces, so the pipeline above never has to change shape to get sharper.

🛠️ Admin Console signed in as System Manager 1 · SAVE CONNECTION SETTINGS ⚙️ LLM / ERP settings form Model, base URL, API key, ERP connection details Validated, then saved 🗄️ Postgres — settings table One row per key, 15s in-memory cache — no restart needed read on the next request 2 · UPLOAD A POLICY DOCUMENT 📄 Policy document (PDF / .docx) Text extracted, then split into overlapping chunks so no idea gets cut across a chunk boundary 🌐 Each chunk embedded One call per chunk to the LLM provider's embedding model external call 🗄️ Postgres — pgvector Stored alongside session/context embeddings — one shared index similarity-searched on future prompts 3 · PROVISION ACCESS 🔑 Demo account / stored API key A real person's ERP credential, provisioned once so password login isn't required every time 🔐 Credential Vault AES-256-GCM encrypted, keyed per user, preferred over a cookie used to impersonate this person 4 · 🔁 REVIEW & IMPROVE 🚩 Flagged interactions Any 👎 feedback, or a rule_evaluations row where a business rule blocked/warned 🛠️ Admin patches it Edits a module's rules.ts, corrects a policy doc, or adjusts role access the fix becomes new config closes the loop — same console, no redeploy Same live chat pipeline Auth · Context Assembler · Reasoning Engine · Gateway + Rule Engine · System Connector nothing here needed a code deploy or a restart — and flow 4 means it keeps arriving here a little sharper than yesterday

What this shows: nothing an admin does is a special case — a saved setting is just a row the pipeline re-reads (cached 15s), an uploaded policy document is just another embedding the context assembler can retrieve, and a provisioned credential is just what the system connector uses to impersonate that person. The fourth flow is what turns admin work into the same learning loop the architecture diagram closes with: interactions flagged by a 👎 or a blocked business rule surface here, an admin fixes the actual rule or policy document behind it, and that fix re-enters through the console exactly like flows 1–3 — no separate "admin path," no redeploy, just a sharper pipeline on the next prompt.

💬 User in the chat types a message, or attaches / scans a photo 👁️ if a photo: Vision Extraction One LLM vision call transcribes the image to plain text — reads only, never creates anything becomes the prompt text 1 · 🗂️ Assemble context Recent-turn cache + vector search over embedded policy docs / past interactions, trimmed to a fixed budget 2 · 🧠 Reasoning Engine → LLM Prompt + context + this person's exact allowed-tool list, sent to the LLM provider → picks a tool, or answers directly external LLM call 🌐 LLM Provider (external) tool call chosen → a direct answer skips straight to rendering 3 · 🔒 Gateway + Rule Engine Is this tool on THIS role's allow-list? Runs this module's business rules — block, warn, or pass; outcome logged not allowed / rule fails → refused here passes 4 · 🔌 System Connector Canonical fields → the ERP's own field names, called AS the signed-in person — never a shared account its permissions apply exactly as-is REST, impersonated credential 🏢 ERP System of Record (external) real data / write result returns 5 · ↩️ Result returns to the LLM More tools may be called (up to a fixed limit) before it writes a final answer + a next-step suggestion ↺ loops back to step 2 for another tool call 6 · 🖥️ Rendered in the chat Plain text, a table/card list, a downloadable document, or a one-click confirm button for anything that still needs sign-off 7 · 📊 Logged, then rated Prompt, tools used, rule outcome + answer — one tap of 👍/👎 labels it 8 · 🔁 Feeds the learning loop Curated, then fine-tunes a tool- router model or patches a rule / policy doc — same interfaces → steps 2 & 3 are sharper next time training loop — improves steps 2 & 3 on the next release ✅ Clicked a next step / confirm? Sent right back in as the next turn — starts again at step 1 a confirmed action re-enters as a fresh, ordinary turn

What this shows: every hop a single chat turn takes, whether it started as typed text or a scanned photo — context is assembled once, the LLM reasons in a loop that can call more than one tool, but every single tool call is re-checked against that person's role and the module's business rules before it's allowed to reach the ERP, and nothing marked as needing sign-off (a status change, a send, a create) becomes real until the person clicks the confirm button rendered from step 6. Steps 7–8 are what a Pro agent adds on top of a plain integration: the turn isn't just answered and forgotten — it's logged with its rule outcome, rated with one tap, curated, and rolled back into steps 2–3 as a sharper model or a fixed rule, so the exact same 8-step path gets a little better every release, purely from being used.