Enterprise
Your infrastructure, your models, your keys.
Edtek Chat is software you run, not a tenancy you rent — in your own cloud account, wired into the systems you already have. Documents, passages and vectors live in databases you operate, and the models it calls are the ones you point it at.
What a deployment includes
Not a licence and a login. A system wired into yours.
Every deployment is delivered as an integration project, and that work is part of the standard package rather than a change request after signature.
Your sign-in
Connected to the identity your people already use, so nobody is issued another password to forget.
Your content pipeline
Documents and metadata synchronised from the system of record you already publish out of, rather than uploaded twice.
Your reporting
Usage exported in the shape your finance or rights team needs — including per-document reporting for royalty calculation.
Your infrastructure
Provisioned into your own cloud account with infrastructure-as-code, and handed over with it.
Where things live
Content stays where you put it.
The whole system ships as containers. There is no step where your library has to pass through infrastructure of ours.
A private deployment in your own cloud account
Edtek Chat runs as containers on Microsoft Azure,AWS,DigitalOcean or your own hardware. We ship it as Terraform and Kubernetes manifests, so the whole environment is provisioned as code in an account you own and can be handed to your platform team on day one.
On Azure the language model can run inside that boundary too, through your own Azure OpenAI resource — in which case questions, passages and answers never leave your tenant. Elsewhere, the same applies to any model you host yourself or reach through your own gateway.
The files
Object storage you control — S3, or an S3-compatible store inside your own network.
The passages
Your PostgreSQL, with the extracted text and its embeddings in a pgvector index you can inspect, back up and rebuild.
The conversations
Your database again — questions, answers, citations and the audit trail over all of it.
The models
Whichever endpoints you configure — a public API, your cloud provider’s deployment, or a model running on your own hardware.
Models
A catalog you own, not a list we compile.
Which model answers, which one embeds, which one reranks and which one moderates are four separate decisions, and all four are yours.
Providers
Built-in providers, or anything that speaks their API
OpenAI, Azure OpenAI and OpenRouter are wired in. Beyond them, any OpenAI-compatible endpoint joins the catalog by URL — which is how a self-hosted or in-network model becomes a first-class option rather than a special case.
- Four capabilities, configured separatelyAnswering, embedding, reranking and moderation each have their own default and their own fallback, swapped atomically.
- Cost and context per modelInput and output price and context window are recorded on each row, which is what makes per-deployment cost reporting real numbers rather than estimates.
- Reasoning effort per modelWhere a model supports it, the effort level is part of its catalog row and resolves live — no redeploy to dial it up for one deployment.
- Proven before it is usedA one-token connectivity probe confirms a newly configured model actually responds, before a reader finds out it does not.
Credentials
Your accounts, changed whenever you like
Each model in the catalog carries its own credentials and its own endpoint, so one deployment can answer on your enterprise contract while another runs on something cheaper — and either can be switched without a release.
- Add, replace or clear a key from the console at any time
- Point a model at your own endpoint instead of a public one
- Move a single deployment to a different provider without touching the others
- Send a one-token probe to confirm new credentials work before anyone relies on them
Tenancy and access
Many deployments, one installation.
Instances are how a publisher runs a chatbot per imprint, a firm runs one per practice group, and an association runs a public one alongside a members-only one.
Library boundaries
A deployment can only search the collections it has been granted. The allowlist is applied before a query reaches the library, and a deployment with no grants retrieves nothing — rather than quietly seeing everything.
Membership
Conversations belong to a deployment and to the person who started them. Reaching a deployment requires membership of it unless you have deliberately opened it up.
Sign-in
Email or username with a password, one-time codes by email, or Google. An email allowlist gates sign-up and sign-in, and fails closed when it is empty.
Members carry an owner, admin or member label. It is not a broad permission system — the boundary that really matters is the deployment and the library it may search — but the label is not decorative either: per-answer operational detail, including the model used, latency, token counts and cost, is visible only to owners and admins.
Reporting
Who asked what, of which book.
For a publisher this is not analytics, it is accounting. The usage export gives you a row per retrieval: the document, its collections, the deployment, the timestamp and the question — filterable by date range, deployment and collection, and ready for whoever calculates the royalty.
Alongside it the console tracks spend, latency, reader feedback and the share of questions your library could not answer — the last of which is usually a content gap, not a bug.
The library service
What happens to a document before anyone can ask about it.
Ingestion is not a black box. Each stage is configurable, inspectable, and re-runnable over an existing library.
- Formats
- PDF, Word, Markdown and plain text, read and chunked with their structure intact.
- Chunking
- Sentence-aware by default — passages never break mid-sentence — with paragraph-aware and fixed-size strategies available per library.
- Metadata extraction
- Optional structured extraction on ingest, against a schema chosen for the kind of document.
- Embeddings
- Your embedding model, from any supported provider. An unrecognised provider fails loudly rather than silently embedding into the wrong space.
- Vector index
- Stored in your own Postgres with pgvector, on an HNSW index whose build parameters and recall floor you control.
- Index maintenance
- Rebuild without downtime after a bulk change — search keeps working throughout — on demand or on a schedule.
- Collections
- Nested collections, with per-deployment allowlists and per-collection control over document-level picking.
- Reranking
- Any endpoint speaking the Cohere rerank API — the hosted service, a cloud-provider deployment, or your own.
Operations
What is recorded, and what you can get out.
- Audit trail
- Sign-ins, questions asked, library searches, configuration changes, model catalog edits, instance lifecycle and user invitations — with actor, target, address and agent.
- Model call log
- Every call recorded with provider, model, token counts, latency and estimated cost. Whether full message text is kept is a setting.
- Cost reporting
- Spend by deployment and by model over 7, 30 or 90 days.
- Answer quality reporting
- The share of answers that came back confident, low-confidence or unanswered — and whether the unanswered rate is trending up.
- Reader feedback
- Thumbs up and down on answers, aggregated per deployment.
- Latency
- Average, median and 95th percentile on answering calls.
- Usage export
- A CSV of which documents were retrieved for which questions, when and in which deployment — filterable by date, deployment and collection.
- Rate limiting
- Fixed-window limits on the answering endpoint and the heavier administrative operations, as defence in depth.
Security review
We will show your security team the open items too.
The codebase has been through a structured internal security review covering tenancy boundaries, credential handling, access control and the ingestion path. Findings were tracked and the significant ones fixed. We are not SOC 2 certified and do not claim to be. What we will do is walk your team through the review, the remediations and the items still open, under NDA — which is a more useful conversation than a badge.
Frequently asked questions
Can we run this on our own infrastructure?
Yes — that is the normal way it is delivered. Every part of the system is a container you run: the chat application, the admin console, the library service, PostgreSQL with pgvector for documents and embeddings, object storage for the files, and Redis. We provision it into your own Azure, AWS or DigitalOcean account with Terraform and Kubernetes, or onto your own hardware. Nothing about the architecture requires a hosted service of ours.
Which model providers are supported?
OpenAI, Azure OpenAI and OpenRouter are built in, and any endpoint that speaks the OpenAI API can be added by URL — a gateway, a vLLM server, or a model running inside your own network. The same goes for embeddings. Reranking is the exception: it speaks Cohere’s rerank API rather than OpenAI’s, so it needs the hosted service, a cloud-provider deployment of it, or your own implementation of that endpoint. Models are rows in a catalog you edit, not a list we compile.
Whose model accounts does it use?
Yours. Each model in the catalog carries its own credentials and endpoint, entered in the admin console and changeable at any time — so you can put one deployment on your enterprise contract, another on a cheaper model, and a third on something running inside your own network, without a release in between.
How are deployments kept separate?
Each instance carries an explicit allowlist of the collections it may search, enforced before any query reaches the library — a deployment with no grants retrieves nothing rather than falling through to everything. Conversations belong to an instance and require membership of it. Settings that shape answers are held server-side and are never sent to a reader’s browser.
What identity providers do you support?
Email or username with a password, one-time codes by email, and Google sign-in, with an email allowlist that gates both sign-up and sign-in and fails closed when empty. SAML and directory provisioning are not supported today — if your rollout depends on them, tell us early and we will be straight with you about timing.
Are you SOC 2 certified?
No, and we would rather say so than imply otherwise. The codebase has been through a structured internal security review, with the findings tracked and the significant ones remediated, and we will walk your security team through it — including what is still open — under NDA.
Further reading
Send us your deployment constraints.
Data residency, an approved model list, an air-gapped network, a procurement questionnaire — tell us the hard part first and we will tell you whether it fits.