Deployment
Four placements.
The same software in all of them.
The differences are secrets and tenant rows — not code branches.
Where Citorum runs is a procurement decision, not an engineering fork. The images, the manifests, the retrieval pipeline, the models and the adjudication layer are identical in every topology below.
Where Citorum runs
Four topologies are in production use. They differ in who owns the hardware and who operates the runtime. They do not differ in how the system works, because they are the same build.
Topologies
Pick the boundary that matches your policy
Citorum-hosted, multi-tenant
An isolated tenant on a cluster we operate. Your users, data, branding, retention setting and plan are yours; the inference workers are shared. The fastest way to start, and the right fit when your corpus is not itself the sensitive asset.
Dedicated hosted instance
The same software on a cluster reserved for you, with its own database and its own signing secret. No other customer's workload shares it. Provisioned by our engineering team rather than self-serve.
Your cloud
You bring the nodes in your own account or virtual private cloud; one interactive script maps them and builds the full stack. Your infrastructure, your secrets, your network policy. Operational ownership shifts to your team with our support.
On-premises
Citorum on hardware you own, in your data center, behind your firewall. This is also how Citorum runs its own production — the on-premises path is the one we operate daily, not a variant we test occasionally.
What is identical, and what changes
Identical in all four: the container images and Kubernetes manifests, the frontend bundle, the ingestion and retrieval pipeline, the models, the adjudication layer, the role model and the evidence record. Every model that touches your content runs inside the deployment in all four.
What changes: who owns the hardware, who operates the runtime, and whether the database and signing secrets are dedicated to you. Data residency follows from the topology you pick rather than from a setting in the product.
Running it
Citorum is Kubernetes-native: raw manifests and a deploy script per directory, with no Helm dependency to reconcile against your platform team's conventions. Workloads are placed by node selector, and worker roles are pinned to specific graphics cards so document ingestion can never starve question answering. Conversion workers scale on queue depth and drop to zero when idle. Every schema change ships as an idempotent, reviewable SQL file.
Hardware
The reference architecture is roughly three 24–32 GB graphics cards — one answering, one converting, one indexing and answer-checking — with a measured video memory envelope per card. Sizing beyond that reference depends on corpus and concurrency; we would rather scope it with you than publish a table that misleads.
Zero-egress operation
Retrieval, embedding, conversion, inference, adjudication and transcription all run locally, so the question and the labelled response are the only things that need to move. Two things still want an outbound path in a fully isolated installation: certificate renewal, and delivery of model weights and container images. If you need a genuinely air-gapped install, raise it early — it is a conversation about those two paths, and we do not yet publish a guide for it.
The Citorum Commitment
Citorum is built for organizations that operate under constraints — Sarbanes-Oxley (SOX), the Health Insurance Portability and Accountability Act (HIPAA), the General Data Protection Regulation (GDPR), state privacy statutes, professional privilege. Those constraints are the design input, not something accommodated later. Four commitments follow from that, and they hold in every deployment topology we offer.
- Your corpus and your inference stay in your environment. As deployed, Citorum makes no outbound AI calls. Retrieval, embedding, document conversion, inference, answer-checking and transcription all run on hardware you control.
- Access is enforced where it cannot be bypassed. Tenant, Lens, corpus, tag, group and document scope are applied inside the retrieval query itself, so a passage the user may not see never reaches the model. It is not filtered out afterwards.
- The model that checks the answer is not the model that wrote it. Every answer is scored by independent models against its own cited sources and carries one of three labels: Verified — Cite Source, Review Recommended, or Do Not Rely — Consult Expert.
- We are specific about what we do and do not do. Where a control is not in the product yet, we say so in writing — before your procurement team has to ask twice.
Which topology fits your policy?
Tell us the constraint you have to satisfy — where data may live, who may operate the runtime, what your network team will allow — and we will tell you which of the four fits.