Glossary
Key terms used throughout the Carta Knowledge Center, listed alphabetically.
Admin Tools The web interface where users manage the resources they own within Carta. Any user can create projects, manage groups, and grant access to their data and services based on the permissions they hold. See Admin Tools →.
Carta The core platform developed by Contextualize. Carta is the umbrella name for the full suite of components that together provide identity-aware, permission-gated infrastructure for scientific and operational data coordination.
Carta Gateway The network entry point for all Carta requests. The Gateway authenticates callers and routes traffic to internal Carta services. Every request — from a browser, a Python script, or an automated system — passes through the Gateway before reaching any Carta component.
Carta Permissions Carta's authorization engine. Determines what an authenticated user, group, or service is allowed to do. Uses a graph-based model in which relationships between entities define access rights. Distinct from authentication (the Gateway confirms who you are; Permissions determines what you can do).
Carta Portal The single sign-on (SSO) entry point for human users accessing Carta through a web browser. Handles login using your organization's identity provider.
CartaFS (Carta File System) A file reference registry and access broker. CartaFS holds metadata and pointers to files stored in external systems — it does not store file contents directly. Access is mediated via permission-controlled presigned URLs.
Collections The user-facing application for submitting and browsing structured data in Carta. Researchers use Collections to fill out forms, view their project's data, and navigate the relationships between records. See Collections →.
Contextualize The company that builds and maintains the Carta platform.
DEXR (Data Exchange Registry) A neutral coordination layer for delivering information between independent systems without requiring shared infrastructure. DEXR stores only encrypted references to data; actual files remain in the sender's storage. Handles the "Deliver" stage of the Carta workflow pattern.
Dispatcher A type of Carta service built with Scaffold. Dispatchers are commonly used as post-submit targets that trigger when a form is submitted — translating form content into an action such as generating a run-control file, routing data to a downstream system, or writing instructions to DEXR for an edge device to act on.
Form A structured data entry template in Carta. Forms are defined in Form Builder and filled out by users in Collections or Workflow Manager. Each submitted form creates a traceable record in Carta's data layer.
Form Builder The tool for designing and publishing form schemas. Project administrators use Form Builder to define what information gets captured and how it is validated. See Form Builder →.
FormsDB Carta's optional, out-of-the-box form storage layer. Persists form schemas and submissions, storing both the structure (schemas) and the content (form data) with parent-child relationships linking related records. Designed so new customers can get started on day one without additional setup. Organizations with existing data backends can connect those to Carta instead. See Your Data →.
Post Submit Target The automated action a Dispatcher performs immediately after a form is submitted in Collections. Post submit targets can generate files, trigger downstream processes, or interact with external systems.
Presigned URL A temporary, pre-authenticated URL that grants direct access to a file in cloud or institutional storage. CartaFS returns presigned URLs so clients can upload or download files directly without exposing permanent credentials.
Project The top-level organizational unit in Carta. Projects contain users, forms, data submissions, and file references. Access control is scoped at the project level.
PyCarta The official Python client library for Carta. Provides a programmatic interface to Collections, CartaFS, FormsDB, the Carta graph, and admin operations. Used by data scientists and engineers to build pipelines and integrate external systems with Carta.
Scaffold The standard boilerplate for building a Carta service. Scientists, researchers, and developers use Scaffold to wrap a Python function — a model, a data transformation, an analysis routine, or an automation handler — into a permission-gated service registered in Carta. Dispatchers are a common example of services built with Scaffold.
Schema A structured definition of a form's fields, types, validation rules, and layout. Schemas are authored in Form Builder and stored in Carta's data layer. A schema defines what a form looks like; submissions are instances of a schema.
Service A registered, permission-gated function or process within Carta. Services are registered via Service Manager and can be invoked by authorized users, Dispatchers, or automated systems.
Service Manager The Carta component responsible for registering and managing the lifecycle of services. Services built with Scaffold — including Dispatchers — are registered through Service Manager, making them discoverable and invocable by authorized users and systems.
SSO (Single Sign-On) An authentication mechanism that allows users to log in once using their organization's identity provider and gain access to multiple connected systems without re-entering credentials for each one.
Workflow Manager A visual editor for designing multi-step workflows in Carta that span data capture, structure, and process coordination. Users can fill out and submit forms, link records, and connect processes into directed sequences. Workflow definitions are reusable across multiple runs.
WorkflowDB The database that stores workflow definitions created in Workflow Manager. Stores each workflow as a list of nodes (form references) and edges (dependencies between them).