What Semavex Does

Semavex is a reporting and analytics platform that connects directly to your company's SQL Server or PostgreSQL database. Once connected, your teams generate reports by typing plain language requests. Vexon, the embedded AI agent, handles the entire pipeline between request and delivered report: it reads your schema, plans a query strategy, generates optimized SQL, formats the result, and delivers it on schedule via email.

The core loop is straightforward. A user types a request describing the report they need. Vexon inspects the connected database schema, including index metadata, and generates SQL that is both logically correct and operationally efficient. The result is formatted as a structured report and either returned immediately in the interface or queued for scheduled delivery to one or more email recipients.

Three types of people use Semavex. Technical decision-makers who want architecture clarity before signing a contract. Data engineers who configure and maintain the database connection. And analysts or BI team members who generate reports day to day. This documentation is organized to serve all three: architecture explanations for the first group, configuration detail for the second, and practical guidance for the third.

How the Platform Works

The Semavex frontend is built with Next.js 15. It communicates with a .NET 10 backend that serves as the API layer, orchestrating report generation, scheduling, and delivery. The backend connects to the customer's SQL Server or PostgreSQL database for report data, and uses its own PostgreSQL metadata store for platform state: user accounts, saved reports, schedule definitions, and schema snapshots.

Scheduled reports are managed by Hangfire, a background job system embedded in the .NET backend. When a report is due, Hangfire triggers Vexon to generate the report and hand it to Resend for email delivery. The frontend, backend, Hangfire, and Vexon form a closed loop: report requests flow in from the UI, Vexon processes them against the customer's database, and results flow back as formatted reports or scheduled deliveries.

Vexon does not operate through a chat interface. Every action Vexon takes is a structured tool call defined in the Semavex codebase. The backend exposes a specific set of tools, including query execution, schema inspection, email delivery, and job scheduling. Vexon calls these tools in sequence, and every call is logged. This means Vexon's behavior is scoped, deterministic, and auditable. It does not freestyle, and its capabilities are exactly what the Semavex engineering team has built, not the full surface area of a general AI model.

Connecting Your Database

Semavex supports SQL Server and PostgreSQL. The connection setup requires a connection string and a database service account. We recommend using a read-only service account scoped to the schema or schemas you want Vexon to query. Vexon only ever reads data. It does not insert, update, or delete anything. A read-only account enforces this at the database level and eliminates any risk of accidental writes, regardless of what happens at the application layer.

On first connection, Vexon runs a one-time schema inspection. It reads table names, column names and types, foreign key relationships, index definitions (including composite and partial indexes), and basic statistics. This inspection is read-only and lightweight. The queries Vexon runs against the system catalog are the same ones a DBA would run manually, and they complete in seconds even on large databases.

After the initial inspection, Vexon periodically refreshes its schema knowledge. If you add new tables, create new indexes, or change column types after onboarding, Vexon will pick up those changes automatically on its next refresh cycle. You do not need to manually trigger a re-inspection, though the option is available in the platform settings if you want to force an immediate refresh.

Your First Report

Open the report builder from the dashboard and type a plain language request describing the data you need. Be specific about the metric, the entity, the time range, and any grouping or sorting you want. Here are three examples that represent realistic use cases:

After you submit, Vexon processes the request. It parses your intent, inspects the relevant schema, plans and reviews the query against the index topology, generates SQL for your specific database engine, runs it, and returns the formatted result. For a straightforward report, this takes a few seconds. Complex queries involving aggregations across large tables may take longer, depending on database performance and index coverage.

Your first few reports on a freshly connected database are a good way to verify that Vexon has correctly understood the schema. If a result looks wrong, check two things first: the schema refresh status (to make sure Vexon has the latest table and column definitions) and the prompt wording (to make sure the request is specific enough for Vexon to parse unambiguously).

What Vexon Is

Vexon is not a chatbot. It is not a general-purpose AI assistant with a database plugin. Vexon is a structured agent with a specific job: turn a report request into a delivered report. It does not answer general questions, generate creative content, or improvise. Every action it takes is a defined step in a controlled process.

Architecturally, Vexon is built on Claude via tool calling. The Semavex backend exposes a set of tools: query the database, read schema metadata, schedule a delivery job, send an email. Vexon calls these tools in sequence to complete a report request. It cannot call tools that do not exist in the Semavex codebase. This distinction matters: Vexon's capabilities are exactly what the engineering team has built and exposed, not the open-ended surface area of a general AI model.

For enterprise buyers, this architecture provides a concrete guarantee. Every tool call Vexon makes is logged with its inputs and outputs. Every report is traceable to the specific SQL that produced it, the schema metadata that informed the query plan, and the tool calls that orchestrated the workflow. There is no black box. The audit trail is complete.

How Vexon Processes a Request

When a report request arrives, Vexon follows a specific sequence. Each step is a discrete operation with defined inputs and outputs.

1. 1. Intent parsing. Vexon reads the natural language request and extracts structured intent: the tables involved, the filters that apply, the aggregation needed, and the time range specified.
2. 2. Schema inspection. Vexon reads live schema metadata for the identified tables. This includes column names and types, foreign key relationships, and index definitions with column order and filter conditions.
3. 3. Query planning (first pass). The planner drafts an abstract query approach: which tables to join, in what order, with what filter predicates. At this stage the plan is structural, not yet SQL.
4. 4. Index review (second pass). The reviewer checks the draft plan against the actual index topology. It verifies that filter predicates align with composite index prefixes, that join order takes advantage of available indexes, and that no index-defeating patterns are present. If the plan fails review, it is revised before proceeding.
5. 5. SQL generation. The reviewed plan is materialized as SQL, written for the specific database engine connected. SQL Server queries use T-SQL syntax. PostgreSQL queries use standard SQL. The generated query respects engine-specific behavior and catalog references.
6. 6. Execution and formatting. The query runs against the connected database. The result set is formatted as a structured report with appropriate headers, grouping, and numeric formatting.
7. 7. Delivery. The report is returned to the user in the interface, emailed immediately via Resend, or queued as a scheduled job in Hangfire, depending on how the request was configured.

What Vexon Can Do Autonomously

Vexon can execute the following actions without requiring a human step in between. In response to a single report request, it can chain all of these into one coordinated workflow.

It generates and executes SQL queries against the connected database. It reads schema and index metadata from the database system catalog. It schedules recurring delivery jobs via the Hangfire background job system. It sends report emails via Resend to one or more specified recipients. And it coordinates all of these as sequential tool calls within a single report workflow.

Vexon cannot modify data in the connected database. It cannot change platform configuration, user permissions, or billing settings. It cannot access any system outside of the tools the Semavex backend has defined for it. These boundaries are enforced at the tool-calling level. The tools that Vexon can invoke are explicitly registered in the codebase, and no tool exists for data modification, configuration changes, or external access. This is a structural constraint, not a prompt instruction.

Writing Prompts That Work

The difference between a vague prompt and a specific one is the difference between Vexon guessing what you want and Vexon knowing exactly what to generate. A good prompt includes four things: the metric or measure you want (revenue, count, rate), the entity being measured (customers, orders, transactions), a time range, and a grouping or sort order.

Vague vs. Specific

The specific version gives Vexon a time range (Q3 2024), a grouping dimension (product category), a metric (total revenue), and a sort order (descending by revenue). There is no ambiguity about which tables to query, what aggregation to perform, or how to present the result.

Three Patterns That Work Well

Trend over time: Monthly active users for the past 12 months. This gives Vexon a time-series structure with a clear grain (monthly) and a clear lookback period.

Top N by metric: Top 10 products by units sold in Q4 2024. This tells Vexon to rank, limit, and sort, with a specific time scope.

Distribution by category: Order count by payment method for the last 30 days. This requests a categorical breakdown with a time constraint.

Vexon understands common business terminology: MRR, churn, LTV, GMV, and conversion rate. If the connected schema contains the underlying data needed to calculate these metrics, Vexon will map the terminology to the appropriate aggregation. If the schema does not contain the necessary data, Vexon will say so clearly rather than returning an incorrect approximation.

If a report result does not look right, refining the prompt with more specifics is almost always the right first step. The schema refresh status is the second thing to check. In most cases, the issue is that the prompt was ambiguous enough for Vexon to interpret it differently than you intended.

Why Index Awareness Matters

AI-generated SQL tends to be logically correct but operationally expensive. A query that filters on the second column of a composite index, applies a function to an indexed column, or joins tables in an order that forces the optimizer into nested loop scans on the wrong side, will return the right data. It will also take 40 seconds instead of 200 milliseconds on a table with 50 million rows.

This is not a hypothetical edge case. On production databases with tens of millions of rows, the difference between an index-aware query and a naive one compounds with every report every team generates every day. A platform that generates 50 reports a day across an organization, each taking 30 seconds longer than necessary, wastes 25 minutes of database compute daily and degrades the experience for every other workload sharing that database.

Semavex addresses this at the query planning level, not the prompt level. Users do not need to write index-aware prompts. They do not need to know what indexes exist on their database. Vexon reads the index metadata internally during every query planning cycle and generates SQL that aligns with the actual storage and retrieval topology of the database.

How Vexon Reads Your Schema

Vexon reads schema and index metadata from the database system catalog. The specific views depend on the database engine.

SQL Server

sys.tables and sys.columns provide the table and column inventory. sys.indexes and sys.index_columns describe every index: its type (clustered, nonclustered, filtered), the columns it covers, and the column order within composite indexes. sys.foreign_keys maps relationships between tables. sys.stats provides cardinality estimates that inform join order decisions.

PostgreSQL

information_schema.columns and information_schema.table_constraints provide the column inventory and constraint definitions. pg_indexes describes index definitions including partial index predicates. pg_stats provides column-level statistics including distinct value counts and most common values, which Vexon uses for cardinality estimation in join planning.

This inspection runs on first connection and refreshes periodically. The queries against system catalogs are lightweight, read-only, and complete in seconds. They do not lock tables, do not consume significant resources, and do not run on every report request. Vexon caches the schema snapshot and re-reads only on the next scheduled refresh or when you trigger a manual refresh from the platform settings.

Composite and Partial Indexes

Composite Indexes

A composite index on (column_a, column_b, column_c) is only used efficiently when queries filter on a prefix of that column sequence. A filter on column_a alone uses the index. A filter on column_a and column_b uses it more selectively. A filter on column_b alone does not use it at all, because the index B-tree is ordered by column_a first. Vexon reads the column order from the system catalog and constructs filter predicates that match the index prefix. When a query involves multiple columns from a composite index, Vexon orders the predicates to align with the index structure.

Partial Indexes

A partial index covers only rows that match a filter condition. For example, an index on transaction_date WHERE status = 'completed' only indexes rows where the status is 'completed'. A query that does not include status = 'completed' in its WHERE clause cannot use this index. Vexon reads the index filter expression from the catalog and incorporates the matching predicate into the generated SQL when the partial index is relevant to the query.

Covering Indexes

A covering index includes all columns needed to satisfy a query entirely from the index, without touching the base table. On a table with millions of rows, this eliminates key lookups, which are one of the most common causes of slow queries on well-indexed databases. Vexon identifies covering indexes during the review pass and generates queries that select only the columns present in the covering index when possible.

Join order decisions are informed by cardinality estimates from the statistics catalog. When multiple join paths exist, Vexon sequences joins so that high-selectivity indexes on the driving table reduce the row count flowing into subsequent joins. This keeps intermediate result sets small and avoids the performance cliff that occurs when a low-selectivity join floods the next stage with millions of rows.

Query Planning in Practice

Consider a table called transactions with 40 million rows. It has a composite index on (customer_id, transaction_date, status) and a partial index on transaction_date WHERE status = 'settled'. A user requests: “Show me settled transaction volume by customer for last month.”

A naive query generator might produce something like this:

This query wraps transaction_date in MONTH() and YEAR() functions. Those function calls prevent the database from using an index range scan on transaction_date. The composite index cannot be used because the query does not filter on customer_id (the leading column) first. The partial index on settled transactions is available, but the function wrapping on the date column still forces a scan within it.

The index-aware version uses a date range predicate instead of function calls, preserving index eligibility. The status = 'settled' predicate qualifies the query for the partial index on transaction_date WHERE status = 'settled'. The database can now perform an index range scan on the date range within the partial index, touching only the relevant rows. On a 40-million-row table, this is the difference between a sub-second response and a multi-second full scan.

Setting Up a Schedule

The schedule builder is a visual CRON editor. You select a frequency (hourly, daily, weekly, monthly, or custom) and the builder shows the corresponding CRON expression alongside a human-readable label. Selecting “Every Monday at 8:00 AM,” for example, generates the expression 0 8 * * 1. If you need a non-standard schedule, you can enter a custom CRON expression directly and the builder will display the human-readable interpretation.

Schedules are attached to saved reports. Any report that has been generated at least once can be scheduled. You select the report, configure the frequency and time, add recipient email addresses, and activate the schedule. From that point forward, Semavex generates and delivers the report automatically at the specified interval.

Schedules run in the time zone configured for your workspace. The time zone is displayed clearly in the schedule builder so there is no ambiguity about when delivery will happen. If your team spans multiple time zones, set the workspace time zone to whichever zone your stakeholders use for reporting cadences.

Managing Recipients

Recipients are added by typing email addresses into the recipient field on the schedule configuration. Multiple recipients are supported. Recipients do not need to be Semavex users. The report is delivered as a formatted email with the report data embedded directly in the message body, so recipients can read it without logging into any platform.

You can edit the recipient list at any time without recreating the schedule. Adding or removing a recipient takes effect on the next delivery cycle. The schedule itself, its CRON expression, its report selection, and its activation status remain unchanged when you modify recipients.

Delivery and Retry Behavior

On each scheduled trigger, the Hangfire job system runs the full report workflow. Vexon generates the report by executing the saved query against the connected database, and Resend delivers it to the configured recipients. The delivery status, including timestamps and any error messages, is logged in the platform.

If report generation fails because of a query timeout, a connection issue, or a transient database error, the job is retried automatically. The system attempts redelivery a set number of times with increasing delay between attempts before marking the job as failed and logging the error. You can see failed deliveries in the schedule detail view and trigger a manual retry from there.

If the report generates successfully but email delivery fails at the Resend layer, that failure is also logged separately. The platform distinguishes between generation failures and delivery failures so you can diagnose whether the issue is with your database connection or with email routing.

Pausing and Resuming Schedules

Schedules can be manually paused and resumed at any time. A paused schedule does not generate or deliver reports. All configuration, including the CRON expression, recipients, and report selection, is preserved while paused. Resuming a schedule reactivates it from the next scheduled interval.

One automatic behavior is important to know about. If a Semavex subscription lapses or a payment fails, all scheduled report jobs for that workspace are paused automatically. They resume automatically when the subscription is restored. No reports are silently dropped or delivered late during a lapse. Users receive a notification that scheduled deliveries have been paused due to a billing issue, and the schedules pick up where they left off once the subscription is active again.

Supported Databases

Semavex supports SQL Server and PostgreSQL. The platform maintains separate query generation and schema inspection logic for each engine. SQL Server queries use T-SQL syntax and read metadata from sys.* catalog views. PostgreSQL queries use standard SQL and read metadata from pg_* catalog tables and information_schema views. Users do not need to think about this distinction. Vexon handles it based on the database type specified during connection setup.

Connection Requirements

For both engines, you need a connection string and a service account with read access to the target schema. The service account also needs read access to the system catalog views that Vexon uses for schema inspection. On SQL Server, this means SELECT permission on sys.indexes, sys.index_columns, sys.columns, sys.tables, sys.foreign_keys, and sys.stats. On PostgreSQL, the default permissions for a read-only user typically include access to pg_indexes and pg_stats without additional grants.

Pricing and Plans

Semavex offers four tiers: Starter, Growth, Professional, and Enterprise. Every plan uses a hybrid pricing model. You pay a base subscription for platform access, and separately manage an AI credit wallet that funds Vexon's usage for report generation. You can see your credit balance and usage history in the platform at any time. This model means you pay for what you actually use rather than absorbing AI costs into an opaque flat rate.

Starter

For small teams exploring automated reporting. Includes platform access, a single database connection, and the core report generation and scheduling features.

Growth

For growing data teams with higher report volume. Includes multiple database connections and higher scheduling limits.

Professional

Includes a dedicated Azure instance. For fintech companies and other organizations with compliance requirements around data isolation and tenancy, this is a meaningful architectural guarantee. Your data never shares compute or storage resources with other Semavex tenants. The dedicated instance also provides predictable performance characteristics that a shared environment cannot.

Enterprise

Custom contracts, SLA agreements, and a dedicated support contact. Enterprise plans are negotiated individually based on volume, compliance requirements, and integration needs.

All plans are billed annually with a discount versus monthly. Monthly billing is available for teams that need flexibility.

Data Security

Vexon reads data from the connected database and uses it to generate reports. It does not store query result data beyond the scope of the report being generated. Report content is not used to train any AI model. The data flows through the platform for the duration of the report generation process and is not persisted after delivery.

The connection to your database uses the credentials you provide during setup. Semavex stores these credentials encrypted at rest using AES-256-GCM. We recommend a read-only service account scoped to the relevant schema, which limits the blast radius of any credential issue to read access on the tables you have explicitly made available.

The Professional tier's dedicated Azure instance provides full data isolation. Your Semavex deployment runs on its own compute and storage, separate from all other tenants. For organizations subject to SOC 2, PCI DSS, or similar compliance frameworks, this isolation simplifies the audit story and removes the shared-tenancy considerations that complicate compliance on multi-tenant platforms.

Semavex is hosted on Azure. All data in transit is encrypted via TLS. All data at rest, including the metadata database that stores your account, saved reports, and schedule definitions, is encrypted using Azure's storage encryption.