Civic data is the wrong thing to hand to a public inference API. Civiq.plus runs its model workloads on dedicated GPU capacity in its own AI datacenter, so tenant data stays inside infrastructure we control, throughput is predictable under load, and a model version never changes underneath a deployment without someone deciding it should.
Dedicated
GPU capacity, not shared
Pinned
Model version per deployment
Zero
Third-party training on your data
Full
Audit of every inference run
Why it matters
These are not abstract benefits. Each one closes a gap that opens the moment inference happens on somebody else's shared infrastructure.
Inference happens on hardware we operate. Citizen feedback, field reports and community signals are never handed to a third-party model provider to process.
Dedicated capacity means a queue depth you control. A national broadcast or a surge of voice reports does not sit behind someone else's traffic.
A public endpoint can change the model underneath you. Here a version is pinned per deployment and only moves when you decide it should.
Because we operate the inference layer, the audit record can include what the platform actually asked the model and what came back.
Workloads
The AI layer is not one model answering questions. It is a set of registered, permissioned agents doing specific jobs — transcribing a field report in Telugu, collapsing four hundred complaints into one issue, tracking how a narrative moved across channels. Those have very different latency and throughput profiles, which is why they run on separate paths.
Prioritised. Never queued behind batch.
Yields to real-time under surge.
Workload profile
| Workload | What it does | Path |
|---|---|---|
| Speech recognition | Field workers record in their own language; audio is transcribed and language-detected before anything else runs | Real-time |
| Translation & localisation | Regional-language content and feedback moved between languages for analysis and response | Real-time |
| Issue classification | Free text and transcripts mapped onto the canonical issue taxonomy | Real-time |
| Deduplication & clustering | Hundreds of reports about one broken line collapsed into a single operational issue | Streaming |
| Narrative clustering | Semantically related narratives grouped, with velocity and drift tracked over time | Batch |
| Embeddings & retrieval | Vector indexing for semantic search across feedback, media and documents | Batch |
| Summarisation & briefs | Daily and breaking briefs generated from evidence the platform already holds | Scheduled |
| Simulation & impact | Counterfactual scenarios and before/after estimates for the measurement layer | Batch |
Pipeline
The calling agent's data scope, geographic scope and policy are resolved before any work is queued.
Real-time paths (speech, classification) and batch paths (clustering, embeddings) use separate queues so one cannot starve the other.
Execution happens on reserved capacity, on the model version pinned for that deployment.
Inputs, model and version, tool calls, output, confidence and assumptions are written to the audit log.
Anything high-impact stops at a human approval, with the evidence attached.
The recommendation is linked to what was actually done and whether the condition improved.
Governance
The inference layer inherits the platform's security model rather than sitting beside it. Same tenant isolation, same audit, same approval gates.
Inference workloads are scoped to a tenant. Nothing from one deployment is visible to another, at the queue, the cache or the storage layer.
Encrypted in transit to the inference layer and at rest in any staging store. Keys are held in the same managed vault as the rest of the platform.
Each registered agent carries its own data scopes, geographic scope, cost ceiling and latency ceiling. It cannot reach a district it was not scoped for.
Prompts and outputs follow the data class of their inputs. Nothing is kept longer than the policy for that class allows.
High-impact generated material does not publish on model output alone. A person sees the evidence, the assumptions and the confidence first.
Sized for surge rather than steady state, because civic demand is spiky — an incident, a broadcast or a deadline all arrive at once.
Owning the hardware only matters if the policy around it is clear. These are architectural constraints, not settings someone can toggle under pressure.
Questions
Three reasons that matter for civic data specifically. Tenant data would be processed by a third party, which is difficult to justify for citizen feedback containing personal information. Throughput would sit behind shared rate limits at exactly the moments demand spikes. And the model can change underneath you, which quietly invalidates the version pinning that makes an audit record meaningful.
No. Tenant data is used to serve that tenant's requests and nothing else. It is not used to train or fine-tune models, and it is not shared with a third-party model provider for processing.
Yes, on the National tier. Where a deployment requires it, the inference layer can run in your environment rather than ours, under the same agent registry and audit model.
Real-time paths are prioritised over batch, so speech recognition and classification keep working while clustering and embedding jobs queue. Dashboards degrade to last-known state and label it as stale rather than showing a gap as a result.
New versions run side by side against the pinned version on the same inputs, and the difference is reviewed before anything is promoted. Because runs are recorded with their model version, a regression can be traced to a specific promotion.
No. Agents cluster, summarise, detect anomalies and propose options. Broadcasts, sensitive messages and high-impact recommendations all pass through an explicit human approval, and the approver sees the evidence and confidence rather than just the output.
Capacity, hardware and residency specifics are covered in the security package, available under NDA.
