In the first part of this blog post, Bridging the Language Gap: Evaluating Text-to-SQL Performance, we explored the importance of being able to measure text-to-sql performance in a consistent way. In this second part, we will double down on that idea and dive into a benchmark framework to understand the current state of the art in AI BI, and introduce Trust3 IQ as solution that is better positioned to provide with the levels of accuracy required in the enterprise.
While text-to-SQL systems have shown remarkable progress in translating natural language queries into executable code, their deployment in enterprise environments faces a fundamental challenge: the vast gulf between technical data models and business context. Most organizations struggle not with the mechanics of SQL generation, but with providing AI systems the rich semantic understanding necessary to deliver meaningful business insights.
The Enterprise Context Challenge
In modern enterprises, business-critical information exists in fragmented silos scattered across data warehouses, semantic models, documentation systems, and the minds of domain experts. This fragmentation creates a cascade of problems that undermines AI initiatives:
Information Trapped in Silos: Technical data models in systems like Snowflake, Databricks, or BigQuery contain tables, columns, and relationships, but lack the business semantics that give data meaning. A column named “rev_rec_amt” tells an AI system nothing about revenue recognition policies, seasonality adjustments, or the difference between bookings and recognized revenue.
Tribal Knowledge: Much of the critical context for interpreting data exists as institutional knowledge held by subject matter experts. Business rules, metric definitions, data quality considerations, and domain-specific constraints rarely exist in machine-readable formats that AI systems can consume.
Semantic Inconsistencies: Different teams often define the same business concepts differently. “Customer” might mean active subscribers in one system, total registrations in another, and billable accounts in a third. Without unified semantic definitions, AI agents produce inconsistent and conflicting results.
Governance Gaps: Security policies, privacy classifications, and compliance constraints are typically enforced at the infrastructure level but not semantically. An AI system might have technical access to personal data but lack the business context to understand when that access violates privacy policies or regulatory requirements.
These challenges compound when organizations attempt to deploy AI-powered business intelligence at scale. To make AI usable across the enterprise, teams must undertake several labor-intensive steps:
- Map technical data models to business semantics for each domain, translating database schemas into business-meaningful concepts, entities, and metrics
- Define and reconcile semantic relationships between siloed datasets, establishing how concepts relate across different systems and business units
- Apply comprehensive governance policies including access controls, privacy classifications, and compliance constraints to ensure AI outputs meet regulatory requirements
- Validate and evaluate outputs against both business logic and policy constraints before deployment, ensuring results are not just technically correct but business-appropriate
- Repeat this entire process for each business domain, dataset, or AI application
Today, this work is predominantly manual, heavily dependent on scarce subject matter experts, and duplicated across projects. Governance and security enforcement often become afterthoughts, added late in the development process and requiring costly rework while introducing operational risk.
The consequences are profound:
- Extended time-to-value: AI initiatives that should deliver insights in days stretch to weeks or months as teams struggle to build adequate context
- Inconsistent outputs: AI systems produce conflicting results because context is rebuilt differently for each project, undermining trust in AI-driven insights
- Reactive governance: Compliance and security become last-minute concerns rather than foundational design principles, creating both legal risk and technical debt
What’s fundamentally missing is a shared, reusable enterprise context layer—a unified source of business semantics and governance rules that can be consistently applied across all AI agents and applications.
Introducing Trust3 IQ: The Universal Enterprise Context Engine
Trust3 IQ addresses this challenge by serving as a universal Enterprise Context Engine that unifies business and technical knowledge across the organization. Rather than requiring teams to rebuild context for each AI project, IQ creates a centralized, continuously updated repository of:
Business Semantics: Comprehensive mappings between technical data structures and business concepts, including metric definitions, calculation logic, and domain-specific terminology
Relationships and Hierarchies: Semantic connections between entities across different systems, enabling AI agents to understand how concepts relate even when data spans multiple platforms.
Governance Rules: Embedded security, privacy, and compliance policies that are automatically applied to AI interactions, ensuring consistent policy enforcement.
Metadata and Lineage: Complete visibility into data provenance, transformation logic, and quality metrics that inform AI decision-making.
How does it work?
Trust3 IQ is the result of extensive research in the areas of semantic modelling and business intelligence combined with NLP, semantic/pragmatic analysis and language model based augmentation. At its core, Trust3 IQ employs a hybrid architecture combining knowledge graphs, vector databases, and fine-tuned large language models to create a comprehensive semantic layer that bridges the gap between natural language queries and complex SQL operations across enterprise data warehouses like Snowflake and Databricks.
The platform’s context engine operates through a sophisticated multi-agent architecture where specialized AI agents collaborate to resolve user queries. The IQ Agent acts as the orchestration layer, coordinating between the data engine specific agents (responsible for natural language to SQL translation and query execution) and others that specialize in semantic analysis, entity identification, analytical insights and visualizations. This agent-based approach enables Trust3 IQ to decompose complex analytical requests into specialized tasks, each handled by domain-specific expertise while maintaining contextual coherence throughout the query resolution process.
Trust3 IQ’s semantic optimization techniques represent a significant advancement in query understanding and expansion. The system employs different techniques that enable the user query to be broken down into business concepts, metrics, relations and other key semantic components. The query is then semantically augmented and enriched to ensure the system can understand not just explicit terms but also implicit business intent, synonyms, and conceptual relationships within the enterprise data model.
The knowledge graph foundation of Trust3 IQ maps complex relationships between data sources, databases, schemas, tables, columns, business entities, business concepts, and business metrics. It also continuously processes and updates the semantic relationships of the business entities and reacts to changes on data definitions and resource utilization.
IQ integrates directly with modern data platforms, like Snowflake or Databricks, automatically discovering and understanding existing databases, semantic models, and business logic. This enriched context is then exposed to AI agents, RAG workflows, and analytics applications through both APIs and Model Context Protocol (MCP) servers, enabling seamless integration with existing AI infrastructure.
BIRD: A Comprehensive Text-to-SQL Benchmark
To properly evaluate enterprise text-to-SQL systems like IQ, we need benchmarks that reflect real-world complexity. The Big Bench for Large-Language Models on Relational Database (BIRD) represents a significant advancement in text-to-SQL benchmarking, addressing several limitations of previous evaluation frameworks. For full details, please see the BIRD page here: https://bird-bench.github.io/
Key Features of BIRD
BIRD distinguishes itself from earlier benchmarks through several important characteristics:
Diverse Database Coverage: Unlike previous benchmarks that focused on a limited number of databases, BIRD’s training dataset encompasses 95 databases spanning 37 domains including finance, healthcare, education, and e-commerce. This diversity better represents the heterogeneity of real-world database environments that enterprise AI systems must navigate. The BIRD dev dataset is smaller, with 11 databases and 75 tables in total.
Complex Query Composition: BIRD includes 12,751 text-to-SQL pairs with emphasis on sophisticated queries. Approximately 41% involve multi-turn interactions where follow-up questions depend on previous queries and results, mirroring real-world scenarios where business users refine their information needs iteratively.
Realistic Database Scale: BIRD databases contain over 10,000 cells on average, compared to much smaller databases in previous benchmarks. This scale enables more meaningful evaluation of query efficiency and performance characteristics.
Human-Crafted Content: All BIRD databases and queries are manually created by SQL experts rather than auto-generated, ensuring higher quality and realism in both database design and question formulation.
BIRD Evaluation Methodology
BIRD’s evaluation approach focuses primarily on execution accuracy while incorporating validity checks:
def bird_evaluate(prediction, reference, db_connection): try: pred_result = execute_query(db_connection, prediction) ref_result = execute_query(db_connection, reference) # Normalize results for comparison normalized_pred = normalize_result(pred_result) normalized_ref = normalize_result(ref_result) # Set-based comparison execution_match = set(normalized_pred) == set(normalized_ref) validity = 1.0 if pred_result is not None else 0.0 return { "execution_accuracy": 1.0 if execution_match else 0.0, "validity": validity } except Exception as e: return {"execution_accuracy": 0.0, "validity": 0.0}
While BIRD provides valuable standardization for text-to-SQL evaluation, it has limitations that highlight the need for more comprehensive assessment frameworks—particularly around efficiency evaluation and graduated scoring that reflects the nuanced requirements of enterprise deployments.
Benchmarking Considerations
While our evaluation provides valuable insights into the relative performance of enterprise text-to-SQL systems, several important caveats and limitations must be acknowledged to properly interpret the results.
Platform-Imposed Limitations
From a scalability perspective, Trust3 IQ does not have any constraints or limitations in the number of tables, columns (or data sources in general) that can be added onto a single Trust3 Space. This enables users to not have to revisit their entire semantic posture for every single use case that touches any number of domains or sub-domains, but rather deals with enterprise context holistically.
However, to be able to run a benchmark and baseline comparison with other products in the market (such as Snowflake Intelligence and Databricks Genie) it has been necessary to limit the size and number of data source tables and columns in the benchmark to simulate like-for-like conditions as much as possible on a best effort basis. This is due to the constraints that those other platforms have, which are the following:
Snowflake Intelligence Context Constraints: The 32,000 token limit effectively restricts Snowflake Intelligence to approximately 12 schemas from the BIRD dataset when including necessary semantic model definitions, relationship mappings, and business rules. This constraint forced us to use the BIRD development dataset (11 schemas) to ensure fair comparison, though this limitation itself represents a significant real-world constraint for enterprise deployments.
Databricks Genie Table Limitations: The hard limit of 25 tables per Genie Space required selective question curation. We connected the first 25 tables from the development dataset and manually identified questions that could be answered using only these tables, ensuring minimum representation thresholds:
- Simple difficulty: minimum 15 questions
- Moderate difficulty: minimum 15 questions
- Challenging difficulty: minimum 15 questions
This curation process may have introduced selection bias, as questions involving tables beyond the first 25 were necessarily excluded regardless of their representativeness or importance.
Semantic Model Configuration
Fresh Installation Approach: All platforms were evaluated using fresh installations with automatically generated semantic models to simulate real-world deployment scenarios. This approach provides more realistic performance expectations than highly optimized demonstration environments, but may not reflect the performance achievable after extensive manual tuning.
Automated vs. Manual Optimization: While this approach ensures fair comparison, it potentially understates the performance of platforms like Snowflake Intelligence and Databricks Genie that benefit significantly from manual semantic model optimization. Conversely, it may understate IQ’s advantages in environments where manual optimization resources are limited. In any case, evaluating how the 3 platforms benefit from manual optimization would warrant a separate benchmark. Admittedly, a big part of the purpose of this exercise is to demonstrate the capabilities of the 3 platforms out of the box, making emphasis on the time to market component.
Schema Complexity Normalization: The BIRD development dataset schemas vary significantly in complexity, with some containing simple star schemas while others involve complex many-to-many relationships. This variation, while representative of real-world diversity, introduces additional variables that may affect platform performance differently.
Query Complexity Categorization
BIRD Difficulty Classification: The simple/moderate/challenging categorization is based on BIRD’s assessment of SQL complexity, syntactic requirements, and logical reasoning demands. However, these categories may not perfectly align with the semantic complexity or business logic requirements that distinguish enterprise AI systems.
Business Context Requirements: Some queries classified as “simple” from a SQL perspective may require sophisticated business understanding, while others labeled “challenging” may be syntactically complex but semantically straightforward. This mismatch between SQL complexity and semantic requirements may affect how different platforms perform across categories.
Benchmark Results: IQ vs. Databricks Genie vs. Snowflake Intelligence
Our evaluation compared Trust3 IQ against Snowflake Intelligence and Databricks Genie using the BIRD dataset, with all systems configured fresh installations and automatically generated semantic models (in the case of Snowflake Intelligence and IQ) to ensure fair comparison.
Accuracy Analysis by Query Complexity
The accuracy rate heatmap reveals significant performance differences across query complexity levels:
Simple Queries: Genie and IQ performed well on straightforward queries, with the former achieving 55.56% and the latter getting to 62.50%. Snowflake Intelligence scored 37.5%. Even at the basic level, IQ’s enhanced semantic understanding provided meaningful advantages.
Some of the queries in this category require simple JOIN conditions, such as for the question: “How many posts does the user csgillespie own?”. Snowflake Intelligence, while it generates valid SQL, it is not able to perform any inference on columns to join by and hence will not be able to resolve this kind of query, while Genie also struggles, especially when JOIN columns on different tables have different names. IQ performs deeper semantic reasoning and can easily identify those JOIN columns regardless of whether the names differ or if they change over time, as it performs the appropriate analysis dynamically through semantic augmentation and graph exploration.
Ground truth SQL:
SELECT COUNT(T1.id) FROM posts AS T1 INNER JOIN users AS T2 ON T1.OwnerUserId = T2.Id WHERE T2.DisplayName = 'csgillespie'
Moderate Complexity: The gap widened for moderate queries, with IQ reaching 61.25% accuracy while Snowflake Intelligence achieved 25.0% and Genie a 28.57%. This suggests that IQ’s context engine provides particular value as query complexity increases.
An example of a question of moderate complexity that both Snowflake Intelligence and Genie struggled with was: “What is the free rate for students between the ages of 5 and 17 at the school run by Kacey Gibson?”. Looking at the reasons behind why they both failed it seemed to be largely down to lack of semantic understanding of some of the key columns to resolve the query: AdmFName1 and AdmLName1, which are necessary to filter schools by the right person’s name. IQ on the other hand, performs in depth analysis of what those columns may represent, enhancing column descriptions, and it is able to use them appropriately.
Ground truth SQL:
SELECT CAST(T2.`Free Meal Count (Ages 5-17)` AS REAL) / T2.`Enrollment (Ages 5-17)` FROM schools AS T1 INNER JOIN frpm AS T2 ON T1.CDSCode = T2.CDSCode WHERE T1.AdmFName1 = 'Kacey' AND T1.AdmLName1 = 'Gibson'
Challenging Queries: For the most complex queries, IQ maintained 50.0% accuracy while Genie held up a 35.71% and Snowflake Intelligence dropped to 20.0%. This substantial difference highlights IQ’s ability to handle sophisticated business logic and multi-step reasoning.
In this category we can find queries with a higher level of complexity, mainly reflected as nested queries, or a combination of JOIN conditions and nested queries. An example of this is “For the customer who paid 634.8 in 2012/8/25, what was the consumption decrease rate from Year 2012 to 2013?”. Both Genie and Snowflake Intelligence could not resolve this kind of question due to not having the required JOIN conditions pre-defined in their models. However, IQ applies semantic augmentation and query expansion techniques to establish the kind of data it requires and is able to dynamically find those required JOIN conditions even if they have not been predefined beforehand.
Ground truth SQL:
SELECT CAST(SUM(IIF(SUBSTR(Date, 1, 4) = '2012', Consumption, 0)) - SUM(IIF(SUBSTR(Date, 1, 4) = '2013', Consumption, 0)) AS FLOAT) / SUM(IIF(SUBSTR(Date, 1, 4) = '2012', Consumption, 0)) FROM yearmonth WHERE CustomerID = ( SELECT T1.CustomerID FROM transactions_1k AS T1 INNER JOIN gasstations AS T2 ON T1.GasStationID = T2.GasStationID WHERE T1.Date = '2012-08-25' AND T1.Price = 634.8 )
The consistent performance advantage across all complexity levels demonstrates that IQ’s unified context approach provides robust benefits regardless of query sophistication.
SQL Validity Comparison
SQL validity scores represent a percentage of valid queries produced by the platform on the basis of producing a result within the required schema. When an empty response is provided, or the wrong schema is targeted then the score will be 0. On that basis, this metric has a significantly lower representative value and it is only provided as guidance for the type of behavior different platforms provide.
IQ Performance: Achieved consistently high validity (98.0-99.2%) across all difficulty levels, indicating robust SQL generation capabilities.
Snowflake Intelligence: Showed more variation (77.8-82.2%) with particular challenges on complex queries, suggesting less consistent SQL synthesis under demanding conditions. Failures usually come as an apology for not producing the right answer due to lack of context.
Databricks Genie: Achieved a relatively high validity score for simple queries (almost 85%), and then dropped to 80% on more complex queries.
Response Time Analysis
Response time distributions reveal important performance and architectural differences:
Databricks Genie runs significantly faster than IQ and Snowflake Intelligence as it is much more limited in the number of tables it can connect to at once, showing that all the metadata from the Unity catalog for those tables is likely pushed to an LLM for it to fully resolve the query.
Both IQ and Snowflake Intelligence on the other hand leverage internal semantic models to rewrite the query (in the case of the latter), or perform advanced analysis on the query (in the case of IQ).
Despite IQ’s enhanced context processing, response times remained competitive, indicating that IQ’s semantic processing overhead is minimal while providing substantial accuracy benefits.
Implications for Enterprise AI
These benchmark results illuminate several critical factors for enterprise text-to-SQL deployment:
Context Completeness Matters: The performance gap between IQ and Snowflake Intelligence demonstrates that comprehensive business context significantly improves query accuracy, particularly for complex business questions.
Consistency Across Complexity: IQ’s maintained performance across difficulty levels suggests that a unified context approach scales better than platform-specific semantic models for diverse enterprise use cases.
Fresh Installation Reality: Testing with newly configured systems provides realistic performance expectations for enterprise deployments, where highly optimized demonstration configurations are not representative of production environments.
Beyond Technical Correctness: The focus on business semantics and governance integration in IQ addresses enterprise requirements that extend beyond pure SQL generation accuracy.
The Path Forward
As enterprises increasingly rely on AI-powered business intelligence, the importance of comprehensive context engines becomes clear. While traditional text-to-SQL systems focus on technical query generation, enterprise success requires systems that understand business semantics, enforce governance policies, and provide consistent results across diverse use cases.
The benchmark results demonstrate that investing in comprehensive context infrastructure—rather than relying solely on platform-specific solutions—delivers measurable improvements in AI system performance. Moreover, the open-source evaluation framework ensures that these assessments remain transparent and reproducible, enabling informed decision-making across the enterprise AI community.
The future of enterprise AI lies not just in more powerful language models, but in more sophisticated context engines that bridge the gap between technical capabilities and business requirements. Trust3 IQ represents a significant step toward that future, providing the semantic foundation that enables AI systems to truly understand and serve enterprise business needs.
Platform-Specific Limitations: The Scalability Challenge
While Snowflake Intelligence and Databricks Genie represent significant advances in bringing AI capabilities to modern data platforms, their architectural approaches reveal fundamental limitations that constrain enterprise scalability. Some of these limitations stem from their platform-centric design philosophy, which prioritizes deep integration within a single ecosystem at the expense of broader enterprise flexibility. Others just come from a less sophisticated design that delegates most of the heavy lifting to an LLM, hence running into the data sizing limitations detailed in the Benchmarking Considerations section, due to LLM context constraints.
Manual Semantic Model Construction
Both Snowflake Intelligence and Databricks Genie require extensive manual effort to construct effective semantic models. This process involves:
Manual Join Definition: Data engineers must explicitly define relationships between tables, specifying join conditions, cardinality rules, and relationship semantics. For complex enterprise schemas with hundreds of tables, this becomes a significant undertaking requiring deep understanding of both technical data structures and business relationships.
Relationship Mapping: Beyond simple joins, teams must manually encode business relationships—how customers relate to orders, how products connect to categories, how time dimensions interact with fact tables. Each relationship requires careful consideration of business rules, data quality implications, and semantic meaning.
Iterative Refinement: As business requirements evolve or new data sources are added, these semantic models require continuous maintenance. What begins as a manageable modeling exercise for a pilot project becomes an ongoing operational burden as the system scales.
This manual approach creates several problematic dependencies:
- Subject Matter Expert Bottlenecks: Semantic model creation requires scarce resources who understand both the technical data landscape and business semantics
- Project-Specific Duplication: Similar semantic concepts must be redefined for each new use case or department, leading to inconsistent definitions across the organization
- Maintenance Overhead: As schemas evolve, semantic models require constant updates to remain accurate and useful
Context Window Limitations
Perhaps more critically, both platforms face fundamental architectural constraints around context size that limit their scalability:
Token Limit: Snowflake Intelligence operates within a 32,000 token context window, which includes all semantic model definitions, schema information, and query context sent to the underlying LLM for each request. Databricks Genie, on the other hand, has got a limit of 25 tables per Genie Space, which is the reason why it was not possible to run the benchmark on it.
Complete Context Transmission: For every query, the entire semantic model context must be transmitted to the LLM, regardless of relevance to the specific question being asked. This “broadcast everything” approach quickly exhausts available context space.
Scaling Mathematics: With typical schema representations requiring 150-200 tokens per table and additional tokens for relationships and business rules, organizations can quickly hit context limits:
Example calculation for a mid-size enterprise:
- 200 tables × 200 tokens per table = 40,000 tokens - 1000 relationships × 25 tokens per relationship = 25,000 tokens - Business rules and metadata = 35,000 tokens Total: 100,000 tokens (exceeding limits)
This limitation manifests in several ways:
Table Count Restrictions: Organizations must artificially limit the number of tables included in semantic models, often forcing them to create multiple fragmented models rather than comprehensive enterprise-wide representations.
Simplified Relationships: Complex business relationships must be simplified or omitted entirely to conserve context space, reducing the semantic richness available to AI agents.
Model Fragmentation: Large enterprises are forced to create numerous smaller semantic models, each covering limited domains, which prevents AI agents from understanding cross-functional business relationships.
Performance Degradation: As context windows fill up, query processing becomes slower and less reliable, creating user experience issues that undermine adoption.
Single-Platform Constraints
Both Snowflake Intelligence and Databricks Genie are fundamentally constrained by their single-platform architecture:
Ecosystem Lock-in: These solutions only work within their respective platforms: Snowflake Intelligence cannot access data in Databricks, BigQuery, or on-premises systems, while Databricks Genie is similarly limited to the Databricks ecosystem.
Fragmented Enterprise Data: Modern enterprises typically use multiple data platforms:
- Snowflake for analytics workloads
- Databricks for machine learning and advanced analytics
- BigQuery for specific Google Cloud integrations
- Legacy on-premises systems for operational data
- SaaS applications with their own data stores
Isolated Semantic Models: Each platform requires its own semantic model, leading to:
- Inconsistent Definitions: The same business concept (like “customer” or “revenue”) may be defined differently across platforms
- Duplicated Effort: Semantic modeling work must be repeated for each platform
- Fragmented Insights: AI agents cannot provide holistic business views that span multiple data sources
Integration Complexity: Attempts to create unified views across platforms require complex ETL processes or data federation approaches that introduce latency, complexity, and potential data consistency issues.
IQ’s Architectural Advantage
Trust3 IQ addresses these limitations through fundamentally different architectural choices:
Intelligent Context Selection
Rather than transmitting complete semantic models for every query, IQ employs intelligent context selection:
Dynamic Context Assembly: IQ analyzes each query to identify only the relevant semantic concepts, relationships, and governance rules needed for accurate response generation.
Contextual Relevance Scoring: Machine learning models determine which portions of the semantic graph are most relevant to each specific query, ensuring optimal use of available context space.
Incremental Context Loading: For complex queries requiring extensive context, IQ can dynamically load additional semantic information as needed rather than front-loading everything.
Horizontal Scalability
IQ’s architecture enables unlimited horizontal scaling:
Distributed Semantic Graph: Rather than storing semantic models as monolithic structures, IQ maintains a distributed semantic graph that can scale across multiple nodes and storage systems.
Elastic Context Capacity: As enterprise semantic complexity grows, IQ can seamlessly scale its context capacity without architectural constraints or performance degradation.
Unlimited Entity Support: There are no practical limits on the number of tables, relationships, or business rules that IQ can incorporate into its semantic understanding.
Universal Platform Integration
IQ operates as a platform-agnostic context engine:
Multi-Platform Connectivity: IQ connects natively to Snowflake, Databricks, BigQuery, PostgreSQL, and other data platforms through unified APIs.
Semantic Unification: Business concepts are defined once in IQ and automatically mapped across multiple platforms, ensuring consistent understanding regardless of where data physically resides.
Cross-Platform Query Generation: IQ can generate queries that span multiple platforms, automatically handling dialect differences and optimization considerations for each target system.
Federated Governance: Security policies, privacy classifications, and compliance rules are consistently applied across all connected platforms from a single governance framework.
Agent-Agnostic Architecture
IQ serves as a universal context provider:
API-Driven Integration: Any AI agent, RAG system, or analytics application can access IQ’s semantic understanding through standardized APIs.
MCP Server Support: IQ implements Model Context Protocol servers, enabling seamless integration with LLM applications and frameworks.
Context Portability: Semantic models and governance rules defined in IQ can be used by any AI system, preventing vendor lock-in and maximizing return on semantic modeling investments.
This architectural approach transforms semantic modeling from a platform-specific, manually intensive process into a scalable, reusable enterprise capability that grows more valuable as it incorporates additional data sources and business knowledge.
The fundamental difference lies in treating semantic understanding as a shared enterprise asset rather than a platform-specific feature—an approach that scales with enterprise complexity rather than being constrained by it.
Want to try it? Get access to Trust3 IQ here: https://trust3.ai/trust3iq/
