TRINITY PRISM is BI MATRIX's agentic AI analytics platform. Users connect their enterprise 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, when 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.
Business users can use TRINITY productively within one week of deployment.
Most BI and AI analytics solutions require several months of data modeling, metadata definition, and end-user training before business teams can use them. TRINITY is different — it combines plug-and-play deployment, automated metadata, automated query generation, and automated testing — roughly 17 implementation steps are executed automatically by AI.
The core principle is simple: TRINITY AI autonomously explores the customer's database and completes the analytical groundwork on its own. That is how business users gain access to a usable environment within a week — not in months.
Yes — TRINITY is ontology-based.
When a user clicks any element on a chart, the platform instantly displays the entities and relationships that element holds, organized in a machine-interpretable ontology layer.
This is precisely why TRINITY can answer your business questions accurately — because the data relationships are formally defined, not inferred ad-hoc by an LLM. The platform answers only within the boundaries of defined relationships, which ensures both reliability and traceability.
Yes. Simply drag and drop the file into the TRINITY interface — metadata is generated automatically and charts are produced immediately.
Supported formats: Excel (.xlsx), CSV Prerequisite: a clean tabular structure (header row + consistent columns). Sheets with merged cells, multi-level headers, or free-form layouts require preprocessing.
This means analysis can begin instantly — even without a database connection — using the files already on hand.
The platform combines an ontology-based approach that governs business schemas, terminology, and relationships with an AI model that responds based solely on 100% verified factual data supplied by the system, leaving no room for the AI to fabricate information.
This architecture fundamentally eliminates arbitrary interpretation and hallucination by the AI, providing a reliable foundation for business decision-making.
Edits to text and narrative sections are permitted, but modifications to numerical values derived from source data are strictly controlled at the system level.
In addition, detailed records of who modified what and when are clearly captured in the system audit log.
Rather than operating as a black box, the platform transparently exposes the generated SQL query and source data tables (data lineage) to the user. Users can directly review the extraction process and perform cross-checks (human-in-the-loop).
Recommended verification approaches include ERD validation, column mapping validation, result-value validation, and scenario-based testing against representative questions.
Given the urgency and risk profile of these functions, a phased application logic review is required. (Additional consulting to follow.)
Yes, consistency is guaranteed. Rather than relying solely on the generative LLM for data analysis, the platform combines internal fixed rules (analytical strategies) and a query generation engine to fully ensure data consistency and integrity.
Additionally, the LLM's Temperature is set to 0 to control randomness, and caching technology ensures that identical prompts generate identical SQL, returning 100% consistent numerical results.
TRINITY supports a plug-in architecture that integrates seamlessly with legacy systems through standard enterprise APIs and interfaces, minimizing changes to existing IT assets.
The platform supports a hybrid approach based on the customer's security policy and infrastructure environment. Metadata reference and direct DB query methods operate together in a hybrid configuration.
This is fully supported through our MCP (Model Context Protocol) and external API orchestration capabilities.
Even with a closed (private) in-house LLM, real-time external API data such as meteorological information can be combined in real time (Context invocation) to analyze correlations with sales performance using natural language.
Traditional BI is a passive tool that presents only structured data and predefined charts, whereas an AI-based platform is an intelligent tool that understands context and autonomously generates and reasons over SQL through natural language queries to deliver visualized results.
When Excel or CSV files are added via drag-and-drop, the AI automatically structures and stores the data, enabling natural language query-based analysis on top of it.
When data is connected within TRINITY, the metadata is automatically constructed—including semantic information—to minimize engineering intervention.
The distinction is between data storage (Graph DB) and the definition of meaning and relationships in data (Ontology).
A graph database serves as a warehouse that stores the 'shape' of data in a graph (network) structure, while an ontology functions as the brain—logically defining the 'meaning and context' of that data so the AI can reason intelligently, much like a human. This is the most significant technical distinction between the two.
To enable hybrid search capabilities that go beyond simple data lookup and to rigorously maintain data integrity, the system architecture incorporates organic interconnection technology between the two heterogeneous databases (graph DB and vector DB).
This is technically possible but not recommended. To maximize query performance and text-to-SQL accuracy, configuring a data mart (DM) or data warehouse (DW) environment refined for analytical purposes is the enterprise-standard approach.
The platform supports dashboard implementation for intuitive analysis of results, along with 24 visualization components, delivering visualized analytical outputs that include related metrics for each query.
Performance varies depending on query complexity and data volume, but the platform is optimized to deliver answers and visualizations for typical analytical queries within seconds. (Target metrics can be validated during the PoC phase.)
Yes, a star schema structure is recommended for accurate data analysis. Generating precise SQL from a natural language query requires a data mart organized around well-defined business domains.
When configuring the data mart, we recommend a star schema consisting of one fact table and associated code (dimension) tables.
For enterprise-grade stability, the platform provides full system control under concurrent access, including query execution timeout settings, maximum row limits per query, and Workload Management (WLM) for per-user and per-session resource allocation.
The less mature your data infrastructure and the more manual the work, the greater the impact of this platform. Without a complex database build-out, natural language analysis becomes available the moment manual Excel data is uploaded into the system.
While the tables and visualizations themselves appear similar to traditional BI, AI performs the tasks people previously handled to produce those outputs, dramatically reducing operational workload.
Orchestration is an essential requirement when operating multiple agents and is delivered through TRINITY's core hub functionality.
TRINITY supports orchestration through integration with a wide range of agents, MCP, and API connection methods.
04Adoption · Cost · SecurityImplementation, pricing, licensing, air-gapped, DB risk, updates, LLM API
Recommended host specifications: vCPU 16, 64GB memory, 500GB nVME disk, OS Linux / Docker 24+
LLM GPU: For internal models (OSS-120b class), H100 80G × 2 nodes (1 to 2 units), or alternatively external SaaS deployment.
Pricing is calculated based on server specifications (GPU infrastructure costs), number of user licenses, and the scale of data to be integrated. The platform is offered under a perpetual license model aligned with the customer's budget structure.
If the customer's legacy system integration scope is broad and accompanied by large-scale infrastructure build-out, a consortium model with an SI vendor as prime contractor is more stable and reduces risk.
That said, the core AI analytics layer is delivered independently by our team, ensuring quality regardless of the contracting structure.
The platform integrates with the customer's existing security policy and HR system to strictly control which tables and data ranges are accessible based on the authenticated user's permissions.
This is technically possible but should be avoided for system stability. Complex analytical queries can place significant load on the operational (transactional) database, so we strongly recommend connecting to a replicated Read-Replica DB or an analytical data mart populated via CDC (Change Data Capture).
Within a closed network, only the internal database and on-premise LLM are operational.
To use external web search or external APIs (e.g., OpenAI), prior architectural coordination with the security team is required, including API gateway configuration and firewall whitelisting for network integration.
An AI-driven ontology auto-mapping tool with a GUI is provided so administrators can easily manage scope expansion.
In addition, regular operator training and micro-onboarding programs are offered to support the customer's technical self-sufficiency and internal capability building.
Implementation timelines vary depending on data readiness and project scope, but engagements that previously took several months to several years can be reduced to three to four months.
Beyond rapid deployment, natural language querying that requires no user training accelerates user adoption and operational integration.
Depending on the deployment configuration, licensing is structured as a server (core) based perpetual license plus an annual maintenance fee, allowing flexible adoption tailored to the customer's budget and environment.
In environments with strict network separation and data security requirements—such as financial services and the public sector—we recommend on-premise (sLLM) deployment.
When external APIs are used, sensitive data masking and private endpoints can be applied to comply with security regulations.
No matching questions
Try a different keyword or clear the filter to see all 36 questions.
Have a question we didn't cover?
Tell us about the question your team most wants to ask their data. We'll show you what asking PRISM that question looks like — usually within 48 hours.