Tech Glossary | Suranku Public

Search terms

Source & contracts

Where data comes from

How producing systems agree on the shape and meaning of the data they publish.

Domain: A source-system area of ownership (e.g. Retail Commerce) that publishes an agreed set of events. Domains keep ownership and responsibility clear as the platform grows.
Data contract: A formal agreement from a producer describing an event: its topic, name, version, primary keys, and schema. Contracts let consumers rely on data without surprises when producers change.
Kafka topic: A named stream that events are published to (e.g. commerce.orders.created). Apache Kafka is a common backbone for moving event data between systems in near real time.
Event: A single record describing something that happened — an order created, a payment captured. Platforms are built by collecting and processing streams of events over time.
Protobuf (Protocol Buffers): A compact, strongly-typed format for defining the structure of an event. A .proto schema acts as the contract's blueprint so producers and consumers agree on every field.
Schema: The defined structure of a record — its fields and their types. Schemas make data predictable and let tools validate it.
Primary key: The field (or fields) that uniquely identify a record, such as order_id. Primary keys are how the platform recognises duplicates and links related data.

Ingestion & process

The steps that turn raw published events into trustworthy, query-ready data.

Marker: A small signal file that says "a batch of data is ready to process." Markers prevent ingestion from starting on half-published data.
Marker-driven ingestion: Ingestion that begins only after a marker appears, rather than on a blind timer. It ensures a complete, consistent batch is processed.
Ingestion run: One execution of the ingestion process for a contract: it reads events, removes duplicates, writes catalog tables, and records what happened as evidence.
Deduplication (dedup): Removing repeated records that share the same primary key, so each real-world thing is counted once. Streams often deliver the same event more than once, so dedup is essential for correct numbers.
Idempotency: The property that running the same operation again produces the same result — re-running an ingestion doesn't create duplicate output. It makes pipelines safe to retry.

Storage & traceability

The historical layers data is written to, and the trails that explain it.

Catalog table: A processed, query-ready table named <layer>.<domain>.<event>. The catalog is where downstream analysts and apps read data.
Catalog layers: Intraday — fresh data as it arrives during the day. End-of-day — the closed, settled historical state for a day. Analytics — reporting-ready data shaped for dashboards and analysis.
Object store: Scalable file storage (e.g. S3, MinIO) where the underlying data files live. The catalog points to data kept in the object store.
Data lineage: The map of where data came from — tracing a catalog table back through its transformations to the original source topic. Answers "where does this number come from?"
Process lineage: The trail of how a batch was processed: marker discovered → records deduplicated → catalogs written. Answers "what happened in this run, and why?"

Operations & AI

How the apps stay healthy, and how AI answers are produced responsibly.

Liveness: A health check that asks "is the service running at all?" If it fails, the service is restarted.
Readiness: A deeper check that asks "is the service ready to do real work?" — its database, storage, and dependencies are all available. A service can be live but not yet ready.
Backend vs static mode: Backend mode persists data in a real API/database. Static mode runs the same UI entirely in your browser (using local storage) for the public demo — no server required.
AI provider: The service that produces AI answers. The portal prefers native Claude/Anthropic, falls back to any OpenAI-compatible endpoint, and finally to a deterministic local responder — so it always works, with or without an API key.
Deterministic answer: A built-in response generated from local metadata using fixed rules (no external AI). It's predictable and runs offline, which is why it's the always-available fallback.

Keep reading

These terms come to life in the full articles and reference designs.