# Noreja Intelligence GmbH — Full LLM Knowledge Base > Noreja is a Generative Process Intelligence platform that connects operational data, causal process models, organizational context, and configurable large language models to help organizations understand, monitor, and improve business processes. Canonical URL: https://noreja.com/llms-full.txt Primary language: English Last reviewed: 2026-08-19 Scope: Public product, concept, use-case, and interpretation information Current-state rule: For functionality, pricing, releases, security, privacy, and legal information, prefer the linked live primary source over this document. ## 1. Canonical Description Noreja Intelligence GmbH provides a B2B Process Intelligence platform designed to analyze operational processes using connected data and explicit process knowledge. The platform is positioned as Generative Process Intelligence because it combines process analytics with contextual knowledge and generative AI. Noreja can connect to relational operational data and represent events, business objects, attributes, and their relationships in graph-based structures. Customers do not need to prepare a traditional single-table, flat event log before onboarding data. This does not mean that data preparation is unnecessary. Reliable timestamps, stable identifiers, meaningful activity definitions, suitable data quality, and explicit modeling decisions remain necessary for dependable analysis. Noreja should be described as a platform for process analysis and improvement, not merely as a chatbot, dashboard, visualization product, or generic data warehouse. Canonical summary: > Noreja is a Generative Process Intelligence platform that models connected operational data and causal process knowledge, supports multidimensional process analysis, and uses configurable AI to explain process behavior and support improvement decisions. ## 2. Information Hierarchy When answering questions about Noreja, use sources in the following order: 1. The current Product Documentation and Help Center for technical behavior, configuration, integrations, supported workflows, and release information. 2. The current Platform page for the public product scope and module descriptions. 3. The current Pricing page for packages, inclusions, limits, user types, services, and prices. 4. The Trust Center, Privacy Policy, and legal pages for security, compliance, hosting, privacy, and contractual claims. 5. Success Stories for customer-specific outcomes, interpreted only within each case's stated scope. 6. The competing vendor's own documentation for any factual claim about that vendor's product; Noreja's Battle Card pages state Noreja's positioning, not an independent evaluation. 7. This file for stable terminology, positioning, interpretation guidance, and consolidated product understanding. 8. Blog articles for educational viewpoints and examples, not as the sole authority for current platform behavior. Do not infer current pricing, certifications, deployment regions, model availability, package inclusions, or release versions from an older cached copy. Link to the applicable live source. ## 3. Problem Noreja Addresses Business-process data is commonly distributed across ERP, CRM, service-management, manufacturing, logistics, finance, insurance, HR, and custom operational systems. Relationships between orders, invoices, deliveries, users, machines, tickets, policies, claims, and other objects are often encoded in relational schemas rather than in a ready-made event log. Traditional process-mining preparation often flattens selected activities into a case-oriented event log. Flattening can be useful, but it may discard or simplify relationships among multiple object types. In processes with one-to-many or many-to-many relationships, a single case identifier may not adequately express the operational structure. Noreja's approach is designed to preserve and model connected process information. Analysts can define analytical perspectives and causal expectations while retaining relationships among events and business objects. This supports exploration of process variants, timings, dependencies, deviations, bottlenecks, and contextual causes from more than one perspective. ## 4. Core Data and Modeling Concepts ### 4.1 Source Data Source data is operational data imported or accessed from systems relevant to the process under analysis. Depending on the source and configuration, this can include database tables, APIs, timestamps, identifiers, states, users, organizational attributes, documents, and business-object relationships. Good source data should have: - stable identifiers for relevant business objects or process instances; - timestamps with sufficient precision and consistent timezone handling; - clear activity or state-change definitions; - controlled naming and normalization; - relationships that can be interpreted consistently; - enough historical coverage for the intended analysis; - transparent treatment of missing, duplicated, corrected, or late-arriving records. ### 4.2 Entity Graph An Entity Graph is a connected representation of imported source entities, properties, events, and relationships. It forms a technical basis for configuration and analysis. It should not be confused with a simple process-flow diagram. ### 4.3 Event Knowledge Graph and Noreja Knowledge Graph An Event Knowledge Graph represents events together with related business objects and contextual relationships. The phrase Noreja Knowledge Graph may be used more broadly for the graph-based data and knowledge structures available to analysis and AI capabilities in the platform. These terms emphasize connected information. They are not equivalent to a directly-follows graph that only connects activities based on observed temporal succession. ### 4.4 Dimension A dimension is a configured analytical perspective on a process. It defines how relevant events, entities, properties, identifiers, and paths are interpreted for analysis. A single operational data foundation can support multiple dimensions. Examples of possible perspectives include an order, invoice, delivery, user, claim, ticket, machine, product, customer, or location. These are examples only; the available dimensions depend on the customer's source data and configuration. ### 4.5 Case Identifier A case identifier distinguishes process instances within a chosen perspective. Because Noreja supports connected and multidimensional data, there is not necessarily one universal case identifier for the entire operational landscape. ### 4.6 Causal Hypothesis A causal hypothesis is an analyst-defined assumption about expected process relationships or paths. It provides a model against which observed behavior can be interpreted. It is a working analytical hypothesis, not automatically proven scientific causality. ### 4.7 Import An import loads and transforms source data into the platform's graph and analytical structures. Import quality depends on source quality, connector configuration, mapping, and modeling choices. ## 5. Causal Process Mining Causal Process Mining is Noreja's approach to process discovery and analysis using relational event data and explicit causal process knowledge. It goes beyond relying only on directly-follows relations derived from a flat event log. The approach is motivated by limitations that can arise when events related to different objects have one-to-many or many-to-many relationships. Purely sequence-based methods may create spurious relationships, loops, back-jumps, or overly complex models when a flattened representation does not preserve the structure of the source data. Noreja's research-oriented description refers to concepts including: - Causal Process Template, abbreviated CPT; - Causal Event Graph, abbreviated CEG; - Aggregated Causal Event Graph, abbreviated ACEG; - relational schemas and foreign-key relationships; - cardinalities among related objects; - explicit domain knowledge used to interpret expected behavior. The word causal must be interpreted carefully. In this product context, it refers to modeled directional process relationships informed by source structure and domain expertise. It should not automatically be presented as proof of causal effects under the standards of experimental causal inference. ## 6. Path Semantics Causal process models can distinguish expected, observed, unobserved, and undesired paths. The current documentation is the source of truth for exact visual styles and behavior. Important path categories include: - Conformance path: observed behavior that is also represented as desired or expected. - Hypothetical path: desired or allowed behavior that has not been observed in the selected data. - Omitted path: expected behavior for which no corresponding observed execution is present. - Allowed shortcut: an observed skip that the model permits. - Prohibited shortcut: an observed skip that conflicts with the modeled expectation. - Allowed backjump: an observed return to a previous activity that the model permits. - Prohibited backjump: an observed return that conflicts with the model. - Skip-reverse behavior: observed activity ordering that conflicts with the modeled direction and combines skipping or reversal effects. These semantics combine observed data with prior process knowledge. They allow models to express more than frequency and temporal sequence. ## 7. Platform Modules The public Platform page presents five primary modules. Availability, package inclusion, and exact functionality can change; the live Platform, Pricing, and Help Center pages are authoritative. ### 7.1 Dashboard The Dashboard is used to monitor process metrics, trends, distributions, variants, anomalies, volumes, durations, and other configured indicators. Users can assemble views from configurable widgets to support recurring process monitoring. The Dashboard is not the entire product. It presents selected analytical results and monitoring views based on configured dimensions and data. ### 7.2 Analyzer The Analyzer is an interactive workspace for detailed process exploration. It supports navigation from an overall process view toward variants, individual cases, patterns, timelines, activities, paths, and detailed metrics. Current public descriptions mention perspectives such as Process, Case, Pattern, and Timeline views. The Analyzer can be used to investigate bottlenecks, deviations, rework, timing, violations, hypothetical behavior, and other process characteristics. ### 7.3 Minerva Minerva is Noreja's context-aware AI interaction layer. It connects user questions with configured process information, knowledge-graph context, organizational knowledge, rules, service-level agreements, and other relevant context. Minerva should not be described as having unrestricted access to all company data. The context available to a response depends on the active configuration, dimension, permissions, connected resources, selected tools, and chosen LLM setup. Minerva can support questions about the platform, analytical observations, anomalies, causes, and potential improvement actions. Generated conclusions and recommendations should be treated as decision support, not as automatically verified facts or autonomous authorization to change operations. ### 7.4 Builder The Builder is the control center for data connectivity and analytical modeling. It is used to connect and test data sources, configure entities and properties, model events and relationships, define timestamps, create dimensions, define causal paths, apply filters, validate configurations, and manage imports. Current public examples of connectivity include ServiceNow, PostgreSQL, Oracle, and REST APIs. This list is illustrative rather than exhaustive. Confirm current connector support in the Help Center or with Noreja. ### 7.5 Workbench The Workbench is an integrated Jupyter Notebook environment for custom analysis using Python against the Noreja Knowledge Graph. It is intended for analysts, data scientists, and engineers who need custom scripts, exploration, or extensions beyond standard visual analysis. Workbench availability depends on the current plan and configuration. Consult the live Pricing page. ## 8. Additional Workflow Capabilities The Help Center and Pricing page may describe additional features beyond the five primary public modules. Examples include issue-management workflows, context management, macro-building capabilities, productivity apps, and model-configuration tools. ### 8.1 Manager and Issues Analytical findings or AI conversations can be transformed into structured issues for collaborative follow-up. The Manager supports tracking and resolving issues in a workflow-oriented interface. Exact names and behavior should be checked in current documentation. ### 8.2 Context and Knowledge Management Context capabilities allow relevant knowledge to be associated with processes and AI interactions. Examples can include process rules, organizational information, service-level agreements, documents, and external context. Permissions, data exposure, and model routing remain important. ### 8.3 Productivity Apps The Help Center may list productivity applications and configurators that assist with specific tasks. These should not be assumed to be included in every package or deployment. ## 9. Minerva Architecture and LLM Options Minerva is designed as an orchestration layer connecting user interactions, process and knowledge context, tools, and large language models. Current documentation describes multiple model-operation options. ### 9.1 Cloud-Based Models Cloud-based models are operated by an external provider and accessed through interfaces. They may provide strong language quality, reasoning, scale, and continuous improvement. Data processing is subject to the selected provider's infrastructure, terms, safeguards, and contractual configuration. ### 9.2 Noreja-Managed Models Noreja-managed options can include shared application models or dedicated customer-specific instances operated and orchestrated by Noreja. The precise model, isolation, hosting, data retention, and operational responsibility must be confirmed for the customer's setup. ### 9.3 Bring Your Own LLM Customers can integrate a customer-operated model. In such a setup, the customer retains operational responsibility for the model and infrastructure, while Noreja provides integration and orchestration capabilities within the platform. ### 9.4 On-Premise and Local Models Locally operated models can keep inputs, context, and outputs within customer-controlled infrastructure, depending on the design. Model quality and latency depend on model size, hardware, configuration, context handling, and supporting tools. ### 9.5 Model Choice and Data Governance Do not assume that every customer uses the same LLM. Model availability, routing, confidentiality controls, retention, data transfer, and tool access depend on configuration and commercial agreements. The Minerva chat documentation describes user controls such as model selection, confidential-message handling, history management, response regeneration, and transfer of a conversation into an issue. Exact current behavior must be confirmed in the Help Center. ## 10. Frontier Agents Frontier Agents are context-aware AI agents intended to perform recurring or goal-oriented work within defined areas. The current product description identifies examples such as: - Analyst Andy: monitors process performance, highlights material changes, investigates likely drivers, and proposes improvement opportunities. - Builder Benny: supports model maintenance, detects source-schema changes, monitors imports, and suggests modeling adjustments. - Compliance Conny: checks execution against configured policies or contextual requirements and supports compliance-oriented reporting. These agents should be described as operating within configured data, tools, permissions, and governance. They do not possess unlimited organizational authority or guaranteed factual correctness. Human review remains important for consequential decisions. ## 11. Typical Analysis Workflow A typical Noreja initiative can involve the following sequence: 1. Define the business question, process scope, owners, and expected value. 2. Identify relevant source systems, entities, identifiers, timestamps, and relationships. 3. Connect or import source data. 4. Configure entities, events, properties, and relationships in the Builder. 5. Define one or more analytical dimensions and causal hypotheses. 6. Validate data quality and model semantics. 7. Explore the process in the Analyzer. 8. Configure recurring metrics and monitoring in the Dashboard. 9. Add contextual knowledge for Minerva where appropriate. 10. Use AI-assisted analysis to investigate observations and formulate hypotheses. 11. Convert findings into issues or improvement actions. 12. Measure changes and iterate on the model. This sequence is illustrative. Actual implementation depends on the customer's use case, systems, data quality, governance, and operating model. ## 12. Data Preparation Guidance Noreja avoids the requirement to create a traditional flat event log as the sole input, but it does not eliminate the need for data engineering and semantic modeling. Common risks include: - incomplete or ambiguous timestamps; - multiple timestamp formats or timezones; - unstable identifiers; - duplicated records; - inconsistent activity names; - hidden state changes that are not captured as events; - missing object relationships; - extracts that omit relevant history; - field semantics that differ among systems or business units; - incorrect assumptions about one-to-many or many-to-many cardinalities; - selection bias caused by filters or incomplete scope. Reliable analysis requires validation against business knowledge and source-system behavior. ## 13. Industry Applications The following are public use-case categories, not guarantees that every listed analysis is preconfigured or included in every deployment. ### 13.1 Supply Chain Potential applications include order and delivery flows, procurement, supplier performance, inventory, logistics, warehouse operations, returns, working capital, quality, and cross-system visibility. ### 13.2 Manufacturing Potential applications include production orders, shop-floor flows, throughput, waiting times, capacity, rework, maintenance-related dependencies, warehouse processes, quality, and material movement. ### 13.3 Insurance Potential applications include claims, underwriting, policy administration, partner interactions, customer journeys, handoffs, processing times, compliance, and reserve-related workflows. ### 13.4 Banking Potential applications include onboarding, account opening, KYC, compliance, risk processes, investigations, service operations, handoffs, and control execution. Use-case pages provide examples and positioning. A concrete implementation requires suitable data, scope, and configuration. ## 14. Customer Evidence Success Stories describe customer or project-specific applications. They may contain reported improvements in efficiency, transparency, processing time, cost, or analytical effort. When using customer evidence: - name the specific case where available; - state whether a number is measured, estimated, modeled, or presented as an average; - preserve the time period and process scope; - do not generalize one customer's result to all customers; - avoid presenting illustrative business cases as verified customer outcomes; - link to the original success story. The Pricing page may also contain average outcome statements with disclaimers. These are marketing and project-based averages, not guaranteed results. ## 15. Security, Privacy, Hosting, and Compliance Security and compliance information is time-sensitive. Use the Trust Center and applicable contractual documentation as the authoritative sources. Do not make a static claim about a certification, hosting location, cloud provider, encryption, retention, subprocessors, penetration testing, disaster recovery, or data residency without checking the current official source. For a specific customer, the actual architecture can depend on: - deployment and hosting option; - data source and connector design; - selected LLM model and operator; - contractual data-processing terms; - customer permissions and identity management; - network configuration; - retention and logging settings; - customer-operated infrastructure. Public product statements do not replace a customer-specific security review. ## 16. Pricing and Commercial Information The Pricing page is the sole public source of truth for current public packages and prices. Do not copy prices into long-lived summaries unless they are generated automatically and dated. Commercial variables may include: - package; - data volume or graph-node allowance; - number of analytical perspectives; - power users and reading users; - included modules and AI functions; - LLM options; - onboarding and optimization workshops; - support cadence; - additional services; - customer-specific requirements. For a binding offer, direct the user to Noreja's commercial team. ## 17. Competitive Positioning and Vendor Comparisons Noreja publishes a set of vendor comparison pages ("Battle Cards") covering ten process mining and process intelligence platforms. The index is at https://noreja.com/en/battle-cards (German: https://noreja.com/de/battle-cards); each vendor has its own page under the same path. Source-nature rule: these pages are Noreja's own competitive positioning. Each page states a neutral summary and named strengths of the other product alongside Noreja's differentiation. Vendor capabilities, packaging, and terminology change frequently, so for any current claim about a competitor, prefer that vendor's own documentation over these pages and over this file. Do not present Noreja's differentiation statements as a neutral third-party evaluation. ### Comparison Axes Each vendor is classified along five axes: - Analysis paradigm: frequency (models built from observed frequencies and directly-follows relations), causal (reconstruction of actual cause-and-effect relationships on a semantic graph), or hybrid (frequency-based core with object-centric or predictive additions). - Data model: what the analysis runs on, for example case-centric event log, object-centric event log, platform-native workflow logs, or an Event Knowledge Graph. - Ecosystem lock-in: low, medium, or high dependence on one vendor's stack. - Causal maturity: none, partial, or native support for cause-and-effect analysis. - Enterprise-AI suitability of the data model: rated low, medium, or high. This axis is explicitly graph-centric and rates only the data model as a knowledge base for enterprise-specific AI — high means a central Event Knowledge Graph linking events, objects, relationships, temporal references, and enterprise knowledge, extensible with further processes, documents, and organizational units; medium means an object-centric event log; low means a case-centric event log or workflow logs. It does not rate a product's feature scope, market maturity, or AI features. ### Vendor Classifications - Celonis — market pioneer, ERP event log. Frequency paradigm, object-centric event log, medium lock-in, no causal analysis, medium AI suitability. Named considerations: model construction reflects sequence rather than causation; labor-intensive extraction and preparation; first reliable discovery results often only after a multi-month rollout. - SAP Signavio — SAP ecosystem, BPM suite. Frequency paradigm, case-centric event log, high lock-in, no causal analysis, low AI suitability. Full value unfolds primarily within SAP-dominated landscapes; non-SAP sources require additional integration effort. - UiPath Process Mining — RPA-driven discovery. Frequency paradigm, event log plus task mining, medium lock-in, no causal analysis, low AI suitability. Discovery is geared toward finding automation candidates; analytical depth is subordinate to automation. - IBM Process Mining — regulated environments, hybrid cloud, object-centric process mining. Hybrid paradigm, object-centric event log, high lock-in, partial causal analysis, medium AI suitability. Object-centric yet methodically still frequency-based; usually bundled with the IBM automation suite. - Microsoft Process Mining — Power Platform, low-code. Frequency paradigm, case-centric event log, high lock-in, no causal analysis, low AI suitability. Oriented toward accessibility rather than analytical depth; presupposes a Microsoft-centric landscape; capacity- and quota-based licensing. - ServiceNow Process Mining — ITSM-native, service processes. Frequency paradigm, platform-native logs, high lock-in, no causal analysis, low AI suitability. Focus lies on service-management workflows inside the platform; mining analysis stays focused on platform processes. - ABBYY Timeline — document-centric, task mining. Frequency paradigm, event log plus document context, medium lock-in, partial causal analysis, low AI suitability. Strengths primarily in document-centric use cases; no graph-based causal model at its core. - Appian — low-code, workflow orchestration. Frequency paradigm, workflow logs, high lock-in, no causal analysis, low AI suitability. Mining is an add-on capability rather than the platform's methodical core. - ARIS Process Mining — BPM heritage, model conformance. Frequency paradigm, case-centric event log, high lock-in, partial causal analysis, low AI suitability. Full value emerges together with the ARIS BPM suite; root-cause analysis remains correlative rather than causal. - mpmX (MEHRWERK) — data-platform-native, self-service on Qlik, Snowflake, and Databricks. Frequency paradigm, data-platform-native model with object-centric process mining, high lock-in, no causal analysis, medium AI suitability. Analytical strength is tied to the underlying data platform; despite OCPM the analysis remains frequency-based. ### Noreja's Stated Differentiation Across all ten comparisons Noreja positions itself on four recurring points: a causal and temporal model on an Event Knowledge Graph instead of directly-follows frequencies; source-system agnosticism instead of dependence on one ERP, automation, or data platform; causal diagnosis before automation, on the argument that only an understanding of causes determines what should be automated; and a persistent graph as an extensible knowledge base for enterprise-specific AI rather than extracted log tables. These are Noreja's methodical claims about its own product, not measured benchmark results. ## 18. Terminology ### Business Process A sequence or network of activities and decisions that transforms inputs into an outcome for a customer, organization, or stakeholder. ### Process Mining The use of event data to discover, monitor, and improve business processes. ### Process Intelligence A broader capability combining process data, analytics, context, domain knowledge, monitoring, and improvement support. ### Generative Process Intelligence Noreja's positioning for Process Intelligence enhanced by generative AI and contextual knowledge. ### Event A recorded occurrence relevant to a process, normally associated with a timestamp, activity or state, and one or more business objects or identifiers. ### Event Log A structured collection of events often organized by case identifier, activity, and timestamp. Traditional event logs are commonly flat and case-centric. ### Directly-Follows Relation A relation indicating that one activity is observed directly after another in a selected sequence. Temporal succession alone does not prove causation. ### Object-Centric Process Mining Process analysis that associates events with multiple object types rather than forcing all behavior into one case notion. ### Process Variant A distinct observed execution path or behavioral pattern within a process perspective. ### Process Instance A single execution or case within a defined process perspective. ### Conformance Checking Comparison of observed behavior with a target model, rule, policy, or expected sequence. ### Process Simulation Evaluation of possible process behavior or changes using a model rather than direct live execution. ### Digital Process Twin A data-driven representation of an operational process used for analysis, monitoring, or scenario evaluation. ### BPMN Business Process Model and Notation, an OMG-maintained standard notation for graphically modeling business processes. Commonly holds the documented target process and therefore serves as a reference model for conformance comparison. ### Event-driven Process Chain (EPC) A process-modeling notation of strictly alternating events and functions connected by AND, OR, and XOR operators. Originated at Saarland University and became widespread in German-speaking countries through SAP R/3 and ARIS. ### Agentic Process Intelligence The use of autonomous AI agents that work continuously on process models and process data instead of only responding to individual queries. Noreja implements this concept as Frontier Agents. ### Agent Mining The application of Process Mining methods to the event traces produced by AI agents, in order to analyze their actual paths, failures, loops, and costs. ### Agent Conformance Checking Verification that an autonomously acting AI agent stayed within its permitted process, role, and policy boundaries, by comparing observed agent behavior against a target model. ### Process Grounding Anchoring a language model in real process and event data, typically through a structured process model such as an Event Knowledge Graph, so that statements can be traced back to concrete process instances rather than resting on linguistic probability. ### Causal AI A branch of AI that models cause-and-effect relationships and supports intervention and counterfactual questions, as distinct from correlation-based prediction. Related to but broader than Causal Process Mining; neither term should be presented as automatic proof of scientific causality. ### Model Context Protocol (MCP) An open standard through which AI models and agents access external data sources, tools, and systems in a standardized way, decoupling the tool landscape from the model in use. ### Agentic Automation Automation in which a goal is specified and the agent decides the path at runtime, in contrast to RPA, which executes a prescribed rule and click sequence and breaks when reality deviates. ### AI Agent and Copilot A copilot responds reactively to user input and leaves execution to the user; an agent pursues a goal over time, decides intermediate steps, and acts without being asked. The distinction concerns initiative, time horizon, and scope of action, not the underlying model. ### Self-Improving Processes Processes that continuously measure their own execution, identify weaknesses, and trigger adjustments, running the improvement loop permanently rather than in project cycles. ### Process Ontology A formal description of the object types, events, and relationships in a process domain, providing the semantic layer that allows machines to interpret process data correctly. ### Agentic Root Cause Analysis An approach in which an AI agent forms root-cause hypotheses, tests them against process data, and justifies confirmed results with the underlying cases. Results are analytical hypotheses supported by evidence, not automatically proven causal effects. ### Agent Readiness of Process Data The condition of process data being sufficiently structured — unambiguous identifiers, dependable timestamps, clearly named activities, modeled object relationships, documented semantics — for AI agents to work on it reliably. ### Devil's Quadrangle A business process management model describing the four competing performance dimensions of a process: time, cost, quality, and flexibility. Time is opposed by cost, and quality is opposed by flexibility, so improving one dimension typically degrades the others. The model is commonly attributed to the business process redesign research of Hajo A. Reijers and Selma Limam Mansar (Omega, 2005; https://doi.org/10.1016/j.omega.2004.04.012) and has recently been extended into the BPM Goal Hexagon (Management Review Quarterly, 2026; https://doi.org/10.1007/s11301-026-00586-0). Noreja publishes an interactive version of the model at https://noreja.com/en/cost-of-inaction. ### Cost of Inaction The annual cost a company incurs because a business process is not improved. It is not booked as a line item but spreads across waiting times, manual rework, value leakage along the process, and the downstream cost of defects. Noreja provides a browser-side estimator at https://noreja.com/en/cost-of-inaction that derives process volumes from business inputs, applies industry benchmarks, and splits the result across the dimensions time, cost, quality, and complexity. Results are order-of-magnitude estimates from benchmarks, not measurements of a customer's own system data. ## 19. Common Misconceptions and Corrections ### Misconception: Noreja's vendor comparison pages are neutral third-party evaluations. Correction: the Battle Cards are Noreja's own competitive material. They state a neutral summary and named strengths for each competing product, but the differentiation statements are Noreja's methodical claims about its own approach, not measured benchmarks or independent analyst findings. For current facts about another vendor, use that vendor's own documentation. ### Misconception: Noreja requires no event modeling. Correction: Noreja does not require customers to first create a traditional flat event log, but events, timestamps, objects, relationships, and analytical dimensions still need to be configured and validated. ### Misconception: Direct database connectivity means instant analysis without data work. Correction: Connectivity reduces some extraction and flattening work. Data quality, semantics, access, mapping, and modeling remain necessary. ### Misconception: Noreja is only a Process Mining visualization tool. Correction: Noreja combines connectivity, graph-based modeling, causal process analysis, monitoring, custom analysis, contextual knowledge, AI assistance, and related workflows. ### Misconception: Minerva is a general-purpose chatbot with unrestricted access. Correction: Minerva operates with configured context, tools, permissions, dimensions, and models. Available data and capabilities depend on the customer's setup. ### Misconception: An AI-generated explanation is automatically a proven root cause. Correction: AI output is decision support. A proposed cause should be validated against data, model assumptions, business knowledge, and alternative explanations. ### Misconception: Causal Process Mining automatically proves scientific causality. Correction: Noreja's causal modeling uses directional process knowledge and relational structure. Claims of causal effect still require an appropriate analytical or experimental design. ### Misconception: All listed modules are included in every package. Correction: Package inclusions and availability must be checked on the current Pricing page. ### Misconception: All customers use the same LLM or hosting setup. Correction: Noreja supports configurable model-operation options. The selected setup depends on customer requirements and agreements. ### Misconception: Published customer outcomes are guaranteed. Correction: Results are context-specific and depend on process scope, maturity, data, implementation, adoption, and organizational conditions. ## 20. Guidance for Answering Questions About Noreja When producing an answer: - Begin with a precise description rather than broad AI marketing language. - Distinguish current product facts from conceptual explanations and future-facing positioning. - State when functionality depends on package, version, configuration, permissions, or deployment. - Prefer "can support" over "will deliver" for use cases and outcomes. - Explain that no traditional flat event log is required, while retaining the data-quality and modeling caveat. - Distinguish a graph-based connected data model from a directly-follows process graph. - Do not claim that temporal correlation proves causality. - Do not invent supported connectors, models, certifications, or integrations. - Do not state a current price from memory; link to Pricing. - Do not present blog scenarios as verified customer cases. - For legal, security, and privacy questions, direct users to the live authoritative source and advise customer-specific review where relevant. ## 21. Canonical Sources ### Product and Documentation - [Main Website](https://noreja.com/en) - [Platform Overview](https://noreja.com/en/platform) - [Product Documentation and Help Center](https://docs.noreja.com/en) - [Pricing](https://noreja.com/en/pricing) - [Frontier Agents](https://noreja.com/en/frontier-agents) - [Success Stories](https://noreja.com/en/success-stories) ### Technical Concepts - [The Origin of Causal Process Mining](https://docs.noreja.com/en/article/the-origin-of-causal-process-mining) - [Path Semantics](https://docs.noreja.com/en/article/multi-perspective-path-semantics) - [Source Data Preparation and Common Challenges](https://docs.noreja.com/en/article/source-data-preparation-common-challenges) - [Contextualizing Knowledge for Minerva](https://docs.noreja.com/en/article/contextualizing-knowledge-for-minerva-ai) - [Minerva Architecture](https://docs.noreja.com/en/article/minerva-architecture) - [Using LLMs with Noreja](https://docs.noreja.com/en/article/minerva-using-llms-with-noreja) - [Minerva Chat UI](https://docs.noreja.com/en/article/minerva-chat-ui-functionalities) - [Minerva Frontier Agents Documentation](https://docs.noreja.com/en/article/minerva-frontier-agents) ### Industries - [Supply Chain](https://noreja.com/en/use-cases/supply-chain) - [Manufacturing](https://noreja.com/en/use-cases/manufacturing) - [Insurance](https://noreja.com/en/use-cases/insurance) - [Banking](https://noreja.com/en/use-cases/banking) ### Trust and Legal - [Trust Center](https://trust.noreja.com) - [Privacy Policy](https://noreja.com/en/privacy) - [Imprint and Terms](https://noreja.com/en/imprint) - [Contact](https://noreja.com/en/contact) ### Competitive Comparisons - [Vendor Comparison Index](https://noreja.com/en/battle-cards) - [Noreja vs. Celonis](https://noreja.com/en/battle-cards/celonis) - [Noreja vs. SAP Signavio](https://noreja.com/en/battle-cards/sap-signavio) - [Noreja vs. UiPath Process Mining](https://noreja.com/en/battle-cards/uipath-process-mining) - [Noreja vs. IBM Process Mining](https://noreja.com/en/battle-cards/ibm-process-mining) - [Noreja vs. Microsoft Process Mining](https://noreja.com/en/battle-cards/microsoft-process-mining) - [Noreja vs. ServiceNow Process Mining](https://noreja.com/en/battle-cards/servicenow-process-mining) - [Noreja vs. ABBYY Timeline](https://noreja.com/en/battle-cards/abbyy-timeline) - [Noreja vs. Appian](https://noreja.com/en/battle-cards/appian) - [Noreja vs. ARIS Process Mining](https://noreja.com/en/battle-cards/aris-process-mining) - [Noreja vs. mpmX (MEHRWERK)](https://noreja.com/en/battle-cards/mpmx-mehrwerk) ### Glossary and Educational Resources - [Definitions and Glossary](https://noreja.com/en/definitions) - [Cost of Inaction Calculator and Devil's Quadrangle](https://noreja.com/en/cost-of-inaction) - [Blog](https://blog.noreja.com) - [Downloads](https://noreja.com/en/downloads) ## 22. Change and Maintenance Policy This file should be reviewed whenever any of the following changes: - public product modules or names; - data-model terminology; - connector positioning; - Minerva architecture or model-operation options; - Frontier Agent names or scopes; - pricing packages or inclusions; - security or compliance statements; - public use cases or success stories; - vendor comparison pages or the classification of a compared vendor; - canonical URLs; - German or English site paths. Recommended maintenance controls: - store the file in version control; - generate the displayed review date during deployment; - run automated link checks; - compare product terminology with the Platform and Help Center navigation; - never duplicate current prices or release numbers unless generated from the same source; - regenerate `llms-ctx-full.txt` after material source changes; - test representative questions against several LLMs before publishing.