One instance per customer
No two customers' data ever share a database.
Platform
The layer that gives your data business context.
Dixtra turns what your experts know into rules linked to your tables and documents. They are recorded, can be audited, and are consulted by people and AI agents, each with their own permissions.
People and AI agents
Validated knowledge
Your data and documents
It connects to your systems without moving or changing the data.
PostgreSQL
SQL Server- BigQuery
- Excel
Parquet
SharePoint- Azure Blob Storage
- Azure Files
If there are several databases, agents query them as a single schema.
Knowledge base
Every rule links to its data.
Definitions, rules and exceptions don't live in a separate document: they are linked to the tables, columns and documents they explain.
- Starting point
- Once connected, Dixtra analyzes tables, columns, relationships and values, and proposes the first business rules.
- Validation
- A power user reviews, edits, approves or rejects each proposal. Only what is approved grounds answers.
- Audit
- Every change is recorded and can be audited.
Each rule is validated once and serves every answer that uses it.
dixtraKnowledge
PaymentsValidated
Operational closure of an incident
Definition
A case is operationally closed when its technical status is C, the payment is settled, the reconciliation balances and it has not been reopened.
Linked to
- cases.technical_status
- payments.settlement_status
- reconciliation.delta
- Operations procedure.pdf
PUValidated byOperations power user
Continuous review
Knowledge gets reviewed without anyone asking.
Dixtra combines lightweight agents, which act in every conversation, with heavier processes that run in the background on more powerful models.
- Detection
- It cross-checks data, documents, knowledge and conversations to find gaps, contradictions and recurring questions.
- Revalidation
- When a new rule comes in, it is checked against what was already there. If it clashes with one, Dixtra asks which one prevails.
The platform never approves its own proposals.
dixtraProposals
- Recurring question
6 people have asked this week what counts as a resolved incident.
Sent to Payment operations.
- Contradiction
The new closure rule doesn't match Operations procedure v2. Which one prevails?
Awaiting the Operations power user.
- Gap
No document explains when a case is reopened.
Sent to Payment operations.
Role-based access
Everyone sees only what is theirs to see.
Permissions are set by groups and by datasets, not with an all-or-nothing switch. Dixtra only queries what the person asking is allowed to see.
- Three roles
- Admin sets up sources and permissions. Power user validates the knowledge of their area. Viewer consults what their permissions allow.
- By groups and datasets
- Each group accesses the datasets it is entitled to, with rules that include or exclude specific tables.
- Knowledge, by area too
- Each power user validates only the rules in their own scope. Finance doesn't approve what belongs to Operations.
- With your identity provider
- Sign in with Microsoft Entra ID or Google Workspace, with no parallel directory to maintain.
- People and agents
- Validated knowledge is also available through a read-only API and MCP, with the same permissions.
Permissions apply before querying, not after answering.
dixtraPermissions
Users
- AFAlfonso FernándezAdmin
- PFPep FerreroPower user
- MRMarta RuizViewer
GroupFinance leadership
- finance · monthly_closeAllowed
- sales · region_marginAllowed
- hr · payrollNo access
Queries
Every query goes through checks before it runs.
Natural-language questions are translated into queries, and each one is reviewed before it reaches your systems.
- 01
Classification
Every question is classified before it is answered (definition, structure, data or document) and only the tools it needs are switched on.
- 02
Pre-validation
Each query is analyzed before it runs: allowed functions, maximum number of rows and maximum time.
- 03
Read-only
Queries run in read-only transactions. Nothing in your databases is changed.
- 04
False premises
If a request starts from a wrong fact, Dixtra doesn't just run it: it points out the contradiction with validated knowledge and explains why.
dixtraQueries
Incident manager
Take the 80 cases with status C off the queue. They are already resolved.
I wouldn't recommend it. Technical status C doesn't mean operational closure. According to the rule validated by Operations, only 55 meet the conditions. I suggest removing those 55.
Deployment
You decide where it is deployed and which model it uses.
Where
In a Dixtra environment with private access, or in your company's private cloud.
Models
Different AI providers. With BYOK, each workspace uses its own keys, stored encrypted.
No training
Your data is not used to train our models or anyone else's.
FAQ
What your technical team needs to know.
Does Dixtra train models on our data?
No. Neither its own models nor third-party ones.
Can the AI change our databases?
No. Every query is read-only and is reviewed before it runs.
Where is our data?
Your databases stay where they are: Dixtra queries them without replacing or changing them. The platform runs on an instance dedicated to your company.
Can we use our own AI provider?
Yes, with your own keys.
Who decides what goes into the knowledge base?
A power user in each area. Dixtra proposes, and only what is approved is used to answer.
We already have a data catalog. Why Dixtra?
A catalog describes what data you have. Dixtra captures how it is interpreted in your business (rules, exceptions, criteria) and uses it to answer.
Let's review how it fits your architecture.
Sources, access, models, deployment and a first knowledge scope. We'll go through them against your company's requirements.