# Data-Centre Ops KG

**The first Cithorum Knowledge Graph product. Runs Cithorum's own 1 PB sovereign cloud and ships as part of the Cithorum Cloud managed service.**

## What it is

A queryable operating graph over Jam telemetry. Every customer, bucket, workload, drive, restore, incident, and invoice that touches the Cithorum 1 PB pod is a typed node in the graph; every relationship between them — *this restore verified that backup, this invoice was based on this telemetry export, this incident was caused by that drive* — is a typed edge with provenance.

It is the operating intelligence layer for a sovereign cloud. Hyperscalers expose the same primitives as four separate products with four separate bills (CloudWatch + Cost Explorer + AWS Audit Trail + Neptune for the graph) and an egress fee on top. Cithorum bundles them into one in-platform query surface with no egress, no separate vendor row, and one operational team.

## Why it exists

Running storage at scale produces enormous amounts of operational signal. Most operators discard or fragment it across vendors. Cithorum's thesis: the most valuable thing inside a sovereign cloud is not the bytes — it is the structured operating reality of running them. That reality is what regulated buyers actually need (audit trails, restore proof, cost-per-TB, capacity forecast, incident genealogy), what investors need to underwrite (unit economics, conversion proof, customer cohorts), and what the AI layer of the future will sit on.

Jam emits the telemetry. The Ops KG turns it into a graph. The graph powers everything downstream.

## What it graphs

Entities the Ops KG types and tracks:

- **Customer** — tenant, contract, billing basis, support tier, primary contact
- **Bucket** — per-tenant storage namespace, isolation policy, encryption key, compliance class
- **Dataset** — logical workload (e.g. "VM snapshots", "FASTQ archive", "log retention")
- **Object** — individual stored item with raw size, compressed size, ratio, hash, age
- **Node** — physical storage or control node (the 5-node pod plus the GPU node)
- **Drive** — individual NVMe, with health, age, write-amp, S.M.A.R.T. state
- **Workload run** — ingest or restore event with throughput, CPU, RAM, duration
- **Restore proof** — verification event, hash check, sample selection, timestamp
- **Incident** — degraded-mode event, root cause, recovery, customer impact
- **Invoice** — billing-period export linked to the workload runs that produced its line items
- **Pilot** — design-partner engagement, success criteria, conversion gate
- **Evidence artefact** — benchmark file, source-truth document, partner email

Relationships (typed edges) include: *belongs-to*, *stored-on*, *measured-by*, *verified-by*, *invoiced-as*, *caused-by*, *resolved-by*, *cited-in*, *converted-from*, *replaced-by*. Each edge carries provenance — when it was created, by which Jam event, with which evidence artefact attached.

## What it answers

Operations questions:

- *Which customers are consuming the most raw capacity, and what's their projected 12-month growth?*
- *Which workloads produce the strongest Jam savings, and which are diluting the average ratio?*
- *Which datasets haven't had a recent restore proof? When is each tenant's next scheduled drill?*
- *Which node, drive, queue, or customer bucket caused last week's incident, and what did the recovery touch?*
- *Which capacity threshold are we tracking against the next pod expansion?*

Commercial questions:

- *Which benchmark report supports this invoice? Where is its source data?*
- *Which customer proof can be shown publicly, privately, or under NDA, and to whom?*
- *Which partner route created which lead, and which leads converted?*
- *Which pilots have hit their conversion criteria and should be moved to a paid contract this quarter?*

Compliance questions:

- *Where is the chain-of-custody for this customer's restore over the last 12 months?*
- *Which DPDP / CERT-In / SOC 2 controls is this audit event evidencing?*
- *Which Jam telemetry events would I need to produce to a regulator on 24-hour notice?*

## How it ships

To Cithorum (internal):

- Operating dashboards: capacity, energy, customer growth, conversion funnel
- Restore-proof drill scheduling and verification
- Billing exports per tenant, sourced verbatim from the graph
- Incident review with full graph context
- Investor-pack data slices on demand

To customers (per-tenant slices):

- Personal benchmark dashboard: TB stored, TB saved, compression ratio, restore audit log
- Self-serve billing exports (the same export Cithorum uses internally, scoped to the tenant)
- API access to the customer's own slice of the graph for downstream tooling
- Monthly automated benchmark report email

To regulated buyers (audit slices):

- Chain-of-custody export per workload, signed and timestamped
- DPDP / CERT-In / SOC 2 evidence pack on demand
- Restore-drill verification certificate per audit period

## Architecture

The Ops KG runs on the same 1 PB pod it observes. Telemetry is emitted by Jam, ingested by the KG Core, indexed against the typed schema, and exposed through (a) read-only customer dashboards over HTTPS, (b) a REST/GraphQL query layer for internal tooling and exports, and (c) AI-accessible summaries that ground the Cithorum chatbot and any future agent surfaces. The graph is itself stored under Jam — the same compression that economises customer data also economises the operating graph.

## Why this is the first KG, not a vertical KG

Cithorum runs a 1 PB sovereign cloud today. That cloud already produces every signal the Ops KG needs. There is no design-partner gating step, no schema scoping question, no "if you build it they will come" risk. The first user is Cithorum itself; the second is every Cithorum tenant who logs into their dashboard. The vertical KGs (Workspace, Law, Medical-Sequencing) are real product directions but they require external design-partner work; Data-Centre Ops KG is live in production the day Cithorum's own pod is.

This is also the canonical proof point of the substrate. When investors and customers ask "does the KG actually work?", the answer is "look at what's running our own infrastructure." Once the substrate is proven on the operator's own data, every vertical KG is a configuration of the same engine — not a new science project.

## How it sits in the product

| Layer | What it does | Where it ships |
| --- | --- | --- |
| Jam codec | Compresses bytes, emits telemetry | Cithorum Cloud + licensed to other operators |
| Data-Centre Ops KG | Indexes the operating reality | Bundled into the Cithorum Cloud managed service; first KG product |
| Vertical KGs (Workspace, Law, Medical-Sequencing) | Re-aim the same core at non-data-centre domains | Design-partner-led, sequenced, one at a time |

The Ops KG is the seed crystal. Every architectural choice it makes — typed entities, provenance-on-every-edge, permission filters at query time, AI-accessible summaries, in-platform graph storage with no egress fee — is reused unchanged when the same engine is pointed at a vertical domain. The verticals do not require a different product; they require a different schema.

---

*Cithorum / Strata India Pvt Ltd · May 2026*