Everything you wanted to ask about TRINITY PRISM.

TRINITY PRISM is BI MATRIX's agentic AI analytics platform. Users connect their data, and PRISM takes them through the analytical journey — interpreting the question, querying the database, generating the chart, and explaining the result in plain language.

What sets PRISM apart is the journey. Instead of a single-shot answer, PRISM moves naturally from one question to the next. For instance, asked "why did last month's revenue drop?", PRISM walks through overall trend → biggest declining product → the affected customer — letting the user keep asking forward.

The bar we measure against is whether the work actually gets easier after deployment.

Different categories of product. ChatGPT and Claude are B2C general-purpose models trained on the open internet. They don't have access to the tables, columns, and business logic inside enterprise databases.

PRISM is purpose-built B2B software. It queries your actual database, uses an ontology layer to interpret your business logic, and shows the SQL and chart behind every answer.

You can upload a spreadsheet to ChatGPT and ask it to summarize. You cannot ask ChatGPT "what was Q2 revenue by region" against your live ERP. That's the line PRISM crosses.

Global BI vendors have announced natural-language analytics capabilities, but general availability timelines have moved slowly. "Conversational analytics over enterprise data" is an area where reliable implementation has taken longer than initial roadmaps suggested.

PRISM is in production in Korea today, with multiple customers using it daily for analytical work.

Microsoft 365 Copilot is a productivity tool — drafting documents, summarizing emails, rewriting text. It does not directly connect to enterprise databases.

PRISM works on your DB data — pulling, joining, aggregating, charting. A different category of tool entirely.

PRISM doesn't just answer a single question and stop. The user asks "what drove Q2 revenue in EMEA?" → PRISM answers → suggests "want to see by product? by sales rep? by month?" → the user clicks → PRISM pivots, surfaces anomalies, proposes the next question. A spectrum of insight, not a single shot.

Under the hood, PRISM is built from eight specialized AI agents. An orchestration agent interprets the question and delegates to the right specialist — query agent, dashboard agent, and so on. We call this the harness pattern: every agent stays in its lane, which keeps autonomy controllable. Communication between agents uses an MCP-style protocol — conceptually similar to traditional API calls, repackaged for the agent era.

Different category of product. Palantir is closer to a high-end data analytics consulting practice, with strengths in defining relationships between data points for what-if analysis — "if production goes up 10%, what happens to operating profit?"

PRISM focuses on a different problem. What PRISM models is how to retrieve the right data and how to analyze it — metadata, schema, semantic layer.

Some segments of the market (particularly defense and public sector) associate "ontology" with Palantir's positioning, which leads to the question "isn't PRISM the same kind of thing?" The value and the usage pattern are different.

PRISM provides about 25 visualization types. The AI recommends the most appropriate chart based on the shape of the data, and the user can switch to a different visualization at any time. Analysis results can be assembled into dashboards as well.

Honestly — "accuracy rate" isn't the metric we focus on. Ask a clear question, you get a clear answer. Ask a vague question, you get a vague answer. That's a property of language itself.

An earlier generation of Text-to-SQL tools fixated on accuracy benchmarks, and that contributed to slower enterprise adoption. The real question to ask is simpler: does the work get easier after PRISM is in place? That's what we hold ourselves to.

"Ontology" is a term used differently across vendors — no single industry definition has settled. In PRISM, the ontology models how to retrieve the right data — table, column, synonym, sample value — and how to analyze it. The closest industry term is semantic layer.

In short: a meta-structure that makes sure your question gets interpreted correctly and routed to the right data.

LLMs are probabilistic by design. The same input doesn't always produce identical output — especially when the question is open to interpretation. The more complex the question, the wider the variation.

Simple questions ("show me May revenue for the Gangnam branch") return the same answer essentially every time.
Complex questions ("which department did well recently?") can return different framings depending on how the intent is parsed.

PRISM's harness pattern keeps intent parsing as consistent as possible across runs. Given the nature of LLM-based systems, complete reproducibility for every input isn't something we commit to.

PRISM runs on an open-source LLM (GPT OSS 120B) by default. The LLM's role inside PRISM is closer to translation than reasoning — parsing the user's question into intent and matching it to metadata. So a top-tier reasoning model isn't required.

PRISM is model-agnostic by design. Customers in regulated industries can pin model versions, swap to a security-approved model, or run the LLM entirely inside their own VPC.

AI trends have moved quickly — LLM fine-tuning → RAG → ontology → harness + orchestration + MCP + agents. No single approach has settled into an industry standard yet. The reason cycles run this fast is straightforward: no approach has worked well enough to settle.

PRISM is not built on a single technique. It combines RAG + ontology + harness (eight agents) + MCP. When any one approach falls out of favor, the others compensate.

Behind the product is BI MATRIX — KOSDAQ-listed (413640), founded 2005, 20 years in enterprise BI. A long-term, stable partner.

Time from user question to generated query is typically 3 to 4 seconds. Actual data retrieval after that runs at your database's native speed — PRISM itself isn't the bottleneck; the database's response time effectively determines total time-to-answer.

No. PRISM does not train on customer data. What PRISM uses is metadata — column names, synonyms, sample values — to generate queries. The queries execute inside your database. The data itself stays where it is.

In the on-premise LLM mode, the model runs inside your environment — no external calls.

PRISM applies four layers of guardrails to keep answers grounded in your database content:

(1) The user selects a business scope — questions outside that scope are restricted.
(2) Output format and answer type are constrained — no freeform speculation.
(3) Harness engineering — each specialized agent stays in its defined role.
(4) Questions that fall outside the ontology's defined relationships are refused rather than guessed.

Within these guardrails, PRISM commits to answers grounded in actual database content.

Yes. PRISM manages synonyms and abbreviations in two ways: the AI generates them automatically, and administrators can add more manually. Added synonyms are merged into the ontology automatically, so the same business term maps to the same database column regardless of how the user phrases the question.

Yes. Metadata and screen templates can be assigned per user group, so each group sees a view tailored to its role over the same underlying data.

Yes — who, when, what, and why are all retained. Even if the session is closed mid-work, temporary saves let users resume where they left off. The full audit trail supports compliance and lets teams understand how the system is actually being used.

Yes — Excel, Word, PowerPoint, and PDF. PRISM's AI Report capability generates a draft from the analysis result, which the user can then refine.

Within limits, yes. A single PRISM instance can connect to multiple databases simultaneously, with metadata-based routing deciding which database serves which question.

Real-time joins across two physical databases, however, are a different problem. They require an intermediate compute layer — a unified view or staging mart.

Our recommendation: build a small analytics mart that consolidates the two systems, and point PRISM at the mart. That's the most reliable production pattern.

A data mart is essentially a pre-aggregated slice of source data optimized for analytics. From PRISM's perspective, a mart and SAP's BW serve the same function.

If you don't have one:
(1) Build a lightweight mart or materialized view containing the columns and aggregations you query most often — by far the most common pattern.
(2) Connect PRISM directly to source tables (cleaner, lower-volume environments only). Performance trade-off applies to very large joins.

Production projects have started without a mart in place. The DW pays off later, not on day one. Customers don't need to wait twelve months for a warehouse build to get value from PRISM.

Worth clarifying up front, because customer expectations on this term often differ from what PRISM actually does.

PRISM's classification:
Structured = tabular data (rows and columns)
Unstructured = documents like policy manuals and procedures — usable as ontology reference material
Out of scope = images, video, audio

PRISM is designed for DB-driven business intelligence. Voice, video, and image analysis aren't on the roadmap. PDFs and scanned forms with embedded tables go through partner OCR vendors first — the partner extracts structured data, PRISM analyzes it.

Technically yes — but we recommend against it. Production OLTP isn't built for analytical workloads, and a misfired query can affect operations. Better pattern: a staging view, materialized view, or thin mapping layer. Same data, no risk to production.

Worth getting this precise up front: SAP is not a database, it's an ERP package. Underneath SAP sits a Hana DB, with SAP's own table structures and business logic on top.

Connection options:
(1) SAP BW (recommended) — BW is SAP's analytical cube layer. Exchange rates, margin calculations, and operating profit are already computed inside BW, making it the best fit for analytics. PRISM connects via OData or MDX queries. This is the most common production configuration for SAP customers.
(2) Direct to Hana DB — technically possible. Requires additional SAP licensing, and the data is in raw form (no FX conversion, no margin logic applied).

Our recommendation: If you have BW, connect via BW. If you use SAP Business Object, point PRISM at the BO mart layer.

Three modes, chosen to match the customer's data governance policy:
(1) Direct source connection — live queries.
(2) Scheduled batch — common where clean cut-off times matter (e.g., finance reporting).
(3) CDC streaming — common where real-time signals matter (e.g., operations).

The right choice depends on the customer's governance model, not on PRISM's pricing.

PRISM uses an enterprise license model based on user count and deployment scope. Detailed pricing is provided after reviewing deployment scenario, concurrent users, and infrastructure setup.

PoC pilots are offered at a fixed fee that converts to credit on production deployment. Talk to sales for a tailored quote.

Note: pricing scales with concurrent users, not data volume. Mid-sized companies are well within scope.

Two paths:
(A) On-site PoC with installation — about a month. PRISM installed at the customer site, PoC executed there.
(B) Sample data + scenarios sent to us — about two weeks. Recommended path.

We generally recommend option B — customer sends a sample database and scenarios, we run the PoC from our side. On-site installation adds schedule and logistical overhead that's worth avoiding when possible.

Typical estimate — ~4 to 5 months for 100 tables, two-to-three engineers. Compared to 6–12 months for a traditional SI build, this is meaningfully shorter.

In well-prepared environments, accelerated timelines down to about a month have been achieved. Actual duration depends on table count, business complexity, and customer collaboration speed.

Most of the time isn't PRISM setup — it's data validation with your domain experts.

Founded 2005. KOSDAQ-listed (413640). 20 years of enterprise BI experience. PRISM is built on TRINITY, the same platform powering large enterprises across multiple industries.

An established, listed company — not an early-stage startup. Two decades of enterprise data tooling experience.

The customer's own team operates PRISM after go-live. During the initial period, BI MATRIX consultants accompany the customer for knowledge transfer — ensuring the customer's people are fully equipped to maintain ontology, add metadata, and onboard new questions independently. PRISM is designed to be run by the business team, not by a permanent vendor presence.