Identity before retrieval
Map users and groups to the original access rules. Apply authorisation before retrieving evidence, then verify that generated responses do not expose restricted material.
Technology & delivery
Private by design.
Practical by engineering.
We choose the smallest maintainable architecture that solves the problem. Deployment, data access, evaluation and operational ownership are part of the design from the beginning.
A reference architecture
Your information,
inside your
chosen boundary.
For local deployments, documents, indexes, embeddings and model inference can stay on customer-managed infrastructure. Internet access and any external services must be explicitly scoped.
A private-cloud option is also possible when that matches your requirements. “Private” depends on the complete data flow, not just where one database runs.
Customer-controlled environmentReference design
Authorised business sourcesDocuments · procedures · tickets · selected work records
↓
Permissions + retrieval layerParsing · search index · source metadata · access filters
↓
Local model runtimeGrounded answers
Workflow engineRules + approval gates
↓
Employee tools + review recordsSource references · decisions · knowledge handover
The details that make it usable
Control is a system property.
Evidence before confidence
Keep source references, document versions and retrieval records. Evaluate answers against an agreed question set and let the system say when it has insufficient evidence.
Approval before action
Separate proposed actions from completed work. Use explicit approval, bounded permissions, idempotency and verification for business-system updates.
Purpose-limited work records
Agree which business records may be collected and why. Provide staff transparency, minimise personal information and define review access and retention.
Human-reviewed knowledge
Treat generated summaries as drafts. Link factual statements to records, mark uncertainty and require review before publishing a company procedure.
Operations and recovery
Document configuration, backups, monitoring and recovery steps. Define what the customer operates and what the support engagement covers.
Open-source ecosystem
Build on good foundations.
We evaluate established projects as components and design references. The final stack depends on project requirements, licensing and operational fit.
| Project | Relevant capability | What we evaluate |
|---|---|---|
| Onyx ↗Official GitHub repository | Enterprise search and knowledge assistants | Connectors, source permissions, retrieval behaviour and deployment footprint. |
| RAGFlow ↗Official GitHub repository | Document parsing and retrieval pipelines | Parsing quality on your documents, traceable references and indexing requirements. |
| Dify ↗Official GitHub repository | Visual AI applications and workflows | Approval design, tool permissions, integration boundaries and licence fit. |
| Langfuse ↗Official GitHub repository | LLM tracing and evaluation | Trace content, sensitive-data handling, retention and evaluation workflows. |
| Ollama ↗Official GitHub repository | Local model serving | Model licence, hardware needs, inference quality and network behaviour. |
| Qdrant ↗Official GitHub repository | Vector retrieval and metadata filtering | Retrieval quality, filtering, backup design and operational requirements. |
These are independent third-party projects. References do not imply partnership, endorsement or that every project is included in a VORX TECH implementation. Features and licences vary by edition and version. The public demos are original browser-based simulations and do not run these projects.
How an engagement works
One useful pilot.
A clear path
to operation.
We agree deliverables, responsibilities and acceptance criteria in a written scope. Expansion follows what the pilot demonstrates.
Discuss a projectDiscover & define
Identify one workflow, its users, data sources and operational constraints. Map risks and define the outcome.
Output: scope, data-flow map and acceptance criteriaBuild & integrate
Implement the selected use case, connect approved sources and configure the deployment environment.
Output: working pilot and integration documentationEvaluate & harden
Test realistic questions, permission boundaries, failures and review steps with the people who will use the system.
Output: evaluation results and agreed remediationHandover & support
Provide operating documentation, training and agreed support. Review changes before widening the scope.
Output: handover package and support responsibilitiesCommon questions
A few practical answers.
Does all company data have to stay on premises?
We can design for a local deployment, including model inference and embeddings. The required boundary is agreed during discovery and checked across connectors, logs, telemetry and updates. Private-cloud deployments can be considered when you permit them.
Do we need to replace our existing software?
Usually the starting point is an integration with selected existing systems. We assess APIs, permissions and data quality first, then define where custom software is useful.
Is work intelligence a way to score employees?
Our focus is task evidence, decision review and reusable knowledge. We design around authorised business records and transparent collection. We do not propose covert device monitoring or automated employee rankings as part of this offering.
Are the website demos connected to a real AI model?
No. They run in your browser with fictional sample documents and deterministic rules. They demonstrate the interaction and control points; a production system needs a separately scoped model, integration, access-control and evaluation layer.
How are services priced?
We prepare a project-specific quotation after understanding the scope, integrations and deployment needs. Development milestones, infrastructure costs and any ongoing support are agreed before work begins.
Start with one useful problem
What could your team do
with knowledge that works?
Tell us about your documents, systems and day-to-day bottlenecks.