Skip to main content
A Corvic Table defines what entity, object, or operational unit you want to work with across your data. Rather than being tied to a single source or format, it composes multiple contributing inputs — structured, unstructured, or multimodal — into one unified, addressable representation. Corvic Tables are the backbone of distributed data processing. They let you declaratively specify how complex data is joined, enriched, and normalized at scale — without hard-coding brittle pipelines — so teams can build reusable, composable intelligence.
A Corvic Table specifies what needs to be embedded, but not how it should be embedded. That’s the role of a Space.

​
Key ideas

​
Table shapes

  • Single entity — one entity file and one space key; the simplest structure.
  • Multi-entity — multiple entity types and keys with richer relationships.
  • Graph-based — entity and relation files combined to capture complex relationships for relational embeddings.

​
Example: financial accounts

Suppose you have accounts.parquet (with account_id) and transactions.parquet (transactions between accounts). A Corvic Table for accounts might use:
  • Input sources: accounts.parquet, transactions.parquet
  • Entity: Account
  • Space key: Account.account_id
  • Relationships: transactions link accounts together
This defines accounts as the entities to embed, using both account attributes and transaction relationships.

​
Building Corvic Tables

You create and configure Corvic Tables as actions on the workflow canvas — for example with Extract Tables to derive clean tables, and Graph Builder to relate them. When you change a table’s inputs or definition, dependent spaces may need to be regenerated.

Spaces

Turn Corvic Tables into embeddings.

Data Sources

The inputs that feed Corvic Tables.

Extract Tables

Derive tables from your sources.

Graph Builder

Relate tables for graph embeddings.