# Create a new action Source: https://docs.gable.ai/api-reference/action/create-a-new-action /api-reference/bundled.yaml post /v0/action Create a new action # Delete an existing action Source: https://docs.gable.ai/api-reference/action/delete-an-existing-action /api-reference/bundled.yaml delete /v0/action Delete an existing action # Get all actions Source: https://docs.gable.ai/api-reference/action/get-all-actions /api-reference/bundled.yaml get /v0/actions Get all actions # This is a fake path added just so the schemas are generated into code. It will be removed from the OAS after type generation, before documentation generation. Source: https://docs.gable.ai/api-reference/action/this-is-a-fake-path-added-just-so-the-schemas-are-generated-into-code-it-will-be-removed-from-the-oas-after-type-generation-before-documentation-generation /api-reference/bundled.yaml get /fake-path-for-type-generation This is a fake path added just so the schemas are generated into code. It will be removed from the OAS after type generation, before documentation generation. # Update an existing action Source: https://docs.gable.ai/api-reference/action/update-an-existing-action /api-reference/bundled.yaml put /v0/action Update an existing action # Get all api keys Source: https://docs.gable.ai/api-reference/api-keys/get-all-api-keys /api-reference/bundled.yaml get /v0/api-keys Get all api keys # Get SCA Prime S3 URL Source: https://docs.gable.ai/api-reference/auth/get-sca-prime-s3-url /api-reference/bundled.yaml get /v0/auth/sca-prime-artifact-bucket Get presigned S3 URL to SCA Prime artifact bucket containing the symbol artifact for the given library and scaPrimeHash # Gets temporary aws code artfact creditial for pip Source: https://docs.gable.ai/api-reference/auth/gets-temporary-aws-code-artfact-creditial-for-pip /api-reference/bundled.yaml post /v0/auth/pip Gets temporary aws code artfact creditial for pip # Gets temporary npm credentials Source: https://docs.gable.ai/api-reference/auth/gets-temporary-npm-credentials /api-reference/bundled.yaml post /v0/auth/npm Gets temporary npm credentials # Create a new changelog event Source: https://docs.gable.ai/api-reference/changelog/create-a-new-changelog-event /api-reference/bundled.yaml post /v0/changelog Create a new changelog event # Get changelog count Source: https://docs.gable.ai/api-reference/changelog/get-changelog-count /api-reference/bundled.yaml get /v0/changelog/count Get changelog count # Get changelog filters available Source: https://docs.gable.ai/api-reference/changelog/get-changelog-filters-available /api-reference/bundled.yaml get /v0/changelog/filters Get changelog filters available # Get the changelog Source: https://docs.gable.ai/api-reference/changelog/get-the-changelog /api-reference/bundled.yaml get /v0/changelog Get the changelog # Delete a component by id Source: https://docs.gable.ai/api-reference/component/delete-a-component-by-id /api-reference/bundled.yaml delete /v0/component/{id} Delete a component by id # Get a component by id Source: https://docs.gable.ai/api-reference/component/get-a-component-by-id /api-reference/bundled.yaml get /v0/component/{id} Get a component by id # Get all components Source: https://docs.gable.ai/api-reference/component/get-all-components /api-reference/bundled.yaml get /v0/components Get all components # Get all versions of a component Source: https://docs.gable.ai/api-reference/component/get-all-versions-of-a-component /api-reference/bundled.yaml get /v0/component/versions/{id} Get all versions of a component # Get component diff between two versions Source: https://docs.gable.ai/api-reference/component/get-component-diff-between-two-versions /api-reference/bundled.yaml get /v0/component/diff/{id} Compare two versions of a component's lineage. Returns a high-level summary of all path-level changes. # Get component merge history Source: https://docs.gable.ai/api-reference/component/get-component-merge-history /api-reference/bundled.yaml get /v0/component/merge-history/{id} Get a component's MERGE_TO_MAIN version history with per-version diff metrics and downstream breakage indicators, ordered newest-first. # Get path diff between two versions Source: https://docs.gable.ai/api-reference/component/get-path-diff-between-two-versions /api-reference/bundled.yaml get /v0/component/path-diff/{id} Compare a single path between two versions of a component. Returns field-level and code-flow detail. # Update component metadata Source: https://docs.gable.ai/api-reference/component/update-component-metadata /api-reference/bundled.yaml patch /v0/component/{id} Update a component's metadata # Get components history Source: https://docs.gable.ai/api-reference/components/get-components-history /api-reference/bundled.yaml get /v0/components/history Get components run history entries, optionally filtered by trigger, branch, commit, namespace, and time range. # Get components history filters Source: https://docs.gable.ai/api-reference/components/get-components-history-filters /api-reference/bundled.yaml get /v0/components/history/filters Get components history filters # Get v0config Source: https://docs.gable.ai/api-reference/config/get-v0config /api-reference/bundled.yaml get /v0/config Get config by type, language, repo and optional version. Returns the latest config if version is not specified. # Get contract Constraints Source: https://docs.gable.ai/api-reference/constraints/get-contract-constraints /api-reference/bundled.yaml get /v0/contract_constraints Get contract Constraints # Create a contract Source: https://docs.gable.ai/api-reference/contract/create-a-contract /api-reference/bundled.yaml post /v0/contract Create a contract # Create a contract enforcement level Source: https://docs.gable.ai/api-reference/contract/create-a-contract-enforcement-level /api-reference/bundled.yaml post /v0/contract/enforcement-level create a contract enforcement level # Create a new subscription for a contract Source: https://docs.gable.ai/api-reference/contract/create-a-new-subscription-for-a-contract /api-reference/bundled.yaml post /v0/contract-subscription Create a new subscription for a contract # Delete a contract by ID Source: https://docs.gable.ai/api-reference/contract/delete-a-contract-by-id /api-reference/bundled.yaml delete /v0/contract/delete/{id} Delete a contract by ID # Delete a subscription for a contract Source: https://docs.gable.ai/api-reference/contract/delete-a-subscription-for-a-contract /api-reference/bundled.yaml delete /v0/contract-subscription/{id} Delete a subscription for a contract # Get a contract by id Source: https://docs.gable.ai/api-reference/contract/get-a-contract-by-id /api-reference/bundled.yaml get /v0/contract/{id} Get a contract by id # Get a contract enforcement level by id Source: https://docs.gable.ai/api-reference/contract/get-a-contract-enforcement-level-by-id /api-reference/bundled.yaml get /v0/contract/enforcement-level/{id} Get a contract enforcement level by id # Get a contract subscription by id Source: https://docs.gable.ai/api-reference/contract/get-a-contract-subscription-by-id /api-reference/bundled.yaml get /v0/contract-subscription/{id} Get a contract subscription by id # Get all available contract namespaces Source: https://docs.gable.ai/api-reference/contract/get-all-available-contract-namespaces /api-reference/bundled.yaml get /v0/contract-namespaces Get all available contract namespaces # Get all contract subscriptions Source: https://docs.gable.ai/api-reference/contract/get-all-contract-subscriptions /api-reference/bundled.yaml get /v0/contract-subscriptions Get all contract subscriptions # Get all contracts Source: https://docs.gable.ai/api-reference/contract/get-all-contracts /api-reference/bundled.yaml get /v0/contracts Get all contracts # Get contracts count Source: https://docs.gable.ai/api-reference/contract/get-contracts-count /api-reference/bundled.yaml get /v0/contracts/count Get contracts count # Get the activity events for a contract Source: https://docs.gable.ai/api-reference/contract/get-the-activity-events-for-a-contract /api-reference/bundled.yaml get /v0/contract/{id}/activity Get the activity events for a contract # Get the contract by darn Source: https://docs.gable.ai/api-reference/contract/get-the-contract-by-darn /api-reference/bundled.yaml get /v0/contracts/data-asset/{id} Get the contract by darn # Get the contract by data asset name Source: https://docs.gable.ai/api-reference/contract/get-the-contract-by-data-asset-name /api-reference/bundled.yaml get /v0/contract/data-asset/{id} Get the contract by data asset name # Get the violation status of a contract by id Source: https://docs.gable.ai/api-reference/contract/get-the-violation-status-of-a-contract-by-id /api-reference/bundled.yaml get /v0/contract/{id}/violation-status Get the violation status of a contract by id # Update a contract enforcement level by id Source: https://docs.gable.ai/api-reference/contract/update-a-contract-enforcement-level-by-id /api-reference/bundled.yaml put /v0/contract/enforcement-level/{id} Update a contract enforcement level by id # Update a contract subscription Source: https://docs.gable.ai/api-reference/contract/update-a-contract-subscription /api-reference/bundled.yaml put /v0/contract-subscription/{id} Update a contract subscription # Update a contract's stage Source: https://docs.gable.ai/api-reference/contract/update-a-contracts-stage /api-reference/bundled.yaml put /v0/contract/{id}/stage Update a contract's stage # Validate a contract Source: https://docs.gable.ai/api-reference/contract/validate-a-contract /api-reference/bundled.yaml post /v0/contract/validate Validate a contract # Get all components Source: https://docs.gable.ai/api-reference/cross-service-components/get-all-components /api-reference/bundled.yaml get /v0/cross-service-components Get all components # Check if the asset associated with the contract is compliant Source: https://docs.gable.ai/api-reference/data-asset/check-if-the-asset-associated-with-the-contract-is-compliant /api-reference/bundled.yaml post /v0/contract/check-compliance Check if the asset associated with the contract is compliant # Check list of data assets for contract violations Source: https://docs.gable.ai/api-reference/data-asset/check-list-of-data-assets-for-contract-violations /api-reference/bundled.yaml post /v0/data-assets/check Check list of data assets for contract violations # Check list of data assets for contract violations Source: https://docs.gable.ai/api-reference/data-asset/check-list-of-data-assets-for-contract-violations-1 /api-reference/bundled.yaml post /v0/data-assets/check-compliance Check list of data assets for contract violations # Check list of S3 data assets for contract violations Source: https://docs.gable.ai/api-reference/data-asset/check-list-of-s3-data-assets-for-contract-violations /api-reference/bundled.yaml post /v0/data-assets/check-compliance/s3 Check list of S3 data assets for contract violations # Check multiple assets for contract compliance Source: https://docs.gable.ai/api-reference/data-asset/check-multiple-assets-for-contract-compliance /api-reference/bundled.yaml post /v0/contract/bulk-check-compliance Check if multiple assets associated with a contract are compliant # Create a data asset Source: https://docs.gable.ai/api-reference/data-asset/create-a-data-asset /api-reference/bundled.yaml post /v0/data-asset Create a data asset # Create profile for a data asset Source: https://docs.gable.ai/api-reference/data-asset/create-profile-for-a-data-asset /api-reference/bundled.yaml post /v0/data-asset/{id}/profile Create profile for a data asset # Creates or updates data assets Source: https://docs.gable.ai/api-reference/data-asset/creates-or-updates-data-assets /api-reference/bundled.yaml post /v0/data-assets Creates or updates data assets # Delete a data asset by id Source: https://docs.gable.ai/api-reference/data-asset/delete-a-data-asset-by-id /api-reference/bundled.yaml delete /v0/data-asset/{id} Delete a data asset by id # Deletes data assets Source: https://docs.gable.ai/api-reference/data-asset/deletes-data-assets /api-reference/bundled.yaml delete /v0/data-assets Deletes data assets # Get a data asset by id Source: https://docs.gable.ai/api-reference/data-asset/get-a-data-asset-by-id /api-reference/bundled.yaml get /v0/data-asset/{id} Get a data asset by id # Get all data assets Source: https://docs.gable.ai/api-reference/data-asset/get-all-data-assets /api-reference/bundled.yaml get /v0/data-assets Get all data assets # Get data assets by a list of DARNs Source: https://docs.gable.ai/api-reference/data-asset/get-data-assets-by-a-list-of-darns /api-reference/bundled.yaml get /v0/data-assets/bulk Get data assets by a list of DARNs # Get data assets count Source: https://docs.gable.ai/api-reference/data-asset/get-data-assets-count /api-reference/bundled.yaml get /v0/data-assets/count Get data assets count # Infer a contract from a data asset Source: https://docs.gable.ai/api-reference/data-asset/infer-a-contract-from-a-data-asset /api-reference/bundled.yaml get /v0/data-asset/{id}/infer-contract Infer a contract from a data asset # Ingest a data asset from a schema Source: https://docs.gable.ai/api-reference/data-asset/ingest-a-data-asset-from-a-schema /api-reference/bundled.yaml post /v0/data-asset/ingest Ingest a data asset from a schema # Register an S3 data asset Source: https://docs.gable.ai/api-reference/data-asset/register-an-s3-data-asset /api-reference/bundled.yaml post /v0/data-asset/register/s3 Register an S3 data asset # Register data assets Source: https://docs.gable.ai/api-reference/data-asset/register-data-assets /api-reference/bundled.yaml post /v0/data-assets/register Register data assets # Register sca metadata for a data asset version Source: https://docs.gable.ai/api-reference/data-asset/register-sca-metadata-for-a-data-asset-version /api-reference/bundled.yaml post /v0/sca-metadata/ingest Register sca metadata for a data asset version # Gable version endpoint Source: https://docs.gable.ai/api-reference/debug/gable-version-endpoint /api-reference/bundled.yaml get /v0/_version Gable version endpoint # Ping Gable Source: https://docs.gable.ai/api-reference/debug/ping-gable /api-reference/bundled.yaml get /v0/ping Ping Gable # Submit a defect report Source: https://docs.gable.ai/api-reference/defect-report/submit-a-defect-report /api-reference/bundled.yaml post /v0/defect-report Submit a defect report from the product UI # Create Lineage Events Source: https://docs.gable.ai/api-reference/events/create-lineage-events /api-reference/bundled.yaml post /v0/events Create Lineage Events # Add path to component. Source: https://docs.gable.ai/api-reference/experimental/add-path-to-component /api-reference/bundled.yaml post /v0/experimental/components/{id}/paths Add a new path to a CODE component. # Create a new cross-service edge. Source: https://docs.gable.ai/api-reference/experimental/create-a-new-cross-service-edge /api-reference/bundled.yaml post /v0/experimental/edges Create a new cross-service edge. # Delete a cross-service edge. Source: https://docs.gable.ai/api-reference/experimental/delete-a-cross-service-edge /api-reference/bundled.yaml delete /v0/experimental/edges/{id} Delete a cross-service edge by ID. # Delete a path from a component. Source: https://docs.gable.ai/api-reference/experimental/delete-a-path-from-a-component /api-reference/bundled.yaml delete /v0/experimental/components/{id}/paths/{pathId} Delete a path from a CODE component. # Get a cross-service edge by ID. Source: https://docs.gable.ai/api-reference/experimental/get-a-cross-service-edge-by-id /api-reference/bundled.yaml get /v0/experimental/edges/{id} Get a cross-service edge by ID. # Get component detail. Source: https://docs.gable.ai/api-reference/experimental/get-component-detail /api-reference/bundled.yaml get /v0/experimental/components/{id} Get full component detail. For CODE components, paths include inline ingress/egress boundary data for round-trip editing. For DATA_STORE components, the schema field list is returned. # Get component versions. Source: https://docs.gable.ai/api-reference/experimental/get-component-versions /api-reference/bundled.yaml get /v0/experimental/components/{id}/versions Get version history for a component. # List components. Source: https://docs.gable.ai/api-reference/experimental/list-components /api-reference/bundled.yaml get /v0/experimental/components List components with optional search and type filtering. # List cross-service edges. Source: https://docs.gable.ai/api-reference/experimental/list-cross-service-edges /api-reference/bundled.yaml get /v0/experimental/edges List cross-service edges. # List field pairs for a component. Source: https://docs.gable.ai/api-reference/experimental/list-field-pairs-for-a-component /api-reference/bundled.yaml get /v0/experimental/component/{id}/field-pairs List field pairs on a component for the field-level focused views. # Update a cross-service edge. Source: https://docs.gable.ai/api-reference/experimental/update-a-cross-service-edge /api-reference/bundled.yaml put /v0/experimental/edges/{id} Update a cross-service edge by ID. Replaces the entire edge definition. # Update a path on a component. Source: https://docs.gable.ai/api-reference/experimental/update-a-path-on-a-component /api-reference/bundled.yaml put /v0/experimental/components/{id}/paths/{pathId} Update a path on a CODE component. Internally creates a BYO_PATH_DELETED event for the old path and a BYO_PATH_ADDED event for the new path, preserving the projection engine's overlay model. # Introduction Source: https://docs.gable.ai/api-reference/introduction ## Welcome Download OpenAPI 3.1 specification: [Download](./bundled.yaml) API to interact with the Gable platform # Export lineage Source: https://docs.gable.ai/api-reference/lineage/export-lineage /api-reference/bundled.yaml get /v0/lineage/export Export lineage # Compute a measurement report on the fly Source: https://docs.gable.ai/api-reference/measurements/compute-a-measurement-report-on-the-fly /api-reference/bundled.yaml get /v0/measurements/generate Fetches lineage data for the specified component versions, runs the measurement comparison, and returns the result without persisting. # Create a filter set Source: https://docs.gable.ai/api-reference/measurements/create-a-filter-set /api-reference/bundled.yaml post /v0/components/{componentId}/filter-sets Create a measurement-report filter set for a ground-truth component. # Delete a filter set Source: https://docs.gable.ai/api-reference/measurements/delete-a-filter-set /api-reference/bundled.yaml delete /v0/components/{componentId}/filter-sets/{filterSetId} Delete a measurement-report filter set. # List filter sets Source: https://docs.gable.ai/api-reference/measurements/list-filter-sets /api-reference/bundled.yaml get /v0/components/{componentId}/filter-sets List measurement-report filter sets for a ground-truth component. # Update a filter set Source: https://docs.gable.ai/api-reference/measurements/update-a-filter-set /api-reference/bundled.yaml put /v0/components/{componentId}/filter-sets/{filterSetId} Update a measurement-report filter set. # Get notifications Source: https://docs.gable.ai/api-reference/notifications/get-notifications /api-reference/bundled.yaml get /v0/notifications Get notifications # Get notifications count Source: https://docs.gable.ai/api-reference/notifications/get-notifications-count /api-reference/bundled.yaml get /v0/notifications/count Get notifications count # Post v0config Source: https://docs.gable.ai/api-reference/post-v0config /api-reference/bundled.yaml post /v0/config Create a config - config # Get status of a sca run Source: https://docs.gable.ai/api-reference/sca/get-status-of-a-sca-run /api-reference/bundled.yaml get /v0/sca/status/{id} Get status of a sca run # Post SCA results Source: https://docs.gable.ai/api-reference/sca/post-sca-results /api-reference/bundled.yaml post /v0/sca/results Post SCA results # Resolve SCA config and run ID Source: https://docs.gable.ai/api-reference/sca/resolve-sca-config-and-run-id /api-reference/bundled.yaml post /v0/sca/start-run Resolve SCA config and a canonical run ID for a future upload # Configure (create or update) an SSO integration in Gable Source: https://docs.gable.ai/api-reference/settings/configure-create-or-update-an-sso-integration-in-gable /api-reference/bundled.yaml put /v0/settings/sso Configure (create or update) an SSO integration in Gable # Deletes a user Source: https://docs.gable.ai/api-reference/settings/deletes-a-user /api-reference/bundled.yaml delete /v0/settings/users Deletes a user from Gable # Get the SAML integration details Source: https://docs.gable.ai/api-reference/settings/get-the-saml-integration-details /api-reference/bundled.yaml get /v0/settings/sso-saml-setup-details Get the details required to create a SAML integration for Gable in an IdP # Gets the configuration of the existing SSO integration Source: https://docs.gable.ai/api-reference/settings/gets-the-configuration-of-the-existing-sso-integration /api-reference/bundled.yaml get /v0/settings/sso Gets the configuration of the existing SSO integration, returns 404 if SSO is not currently configured # Gets the details of a Gable user Source: https://docs.gable.ai/api-reference/settings/gets-the-details-of-a-gable-user /api-reference/bundled.yaml post /v0/settings/user Gets the details of a Gable user by their email address. Users are automatically created in Gable the first time they log in. Use PATCH /v0/settings/user to update a user's details. # Gets the list of Gable users Source: https://docs.gable.ai/api-reference/settings/gets-the-list-of-gable-users /api-reference/bundled.yaml get /v0/settings/users Gets the list of Gable users # Invites a user Source: https://docs.gable.ai/api-reference/settings/invites-a-user /api-reference/bundled.yaml post /v0/settings/users Invites a user to Gable # Remove the existing SSO integration in Gable Source: https://docs.gable.ai/api-reference/settings/remove-the-existing-sso-integration-in-gable /api-reference/bundled.yaml delete /v0/settings/sso Remove the existing SSO integration in Gable # Update a user Source: https://docs.gable.ai/api-reference/settings/update-a-user /api-reference/bundled.yaml patch /v0/settings/user Update a user # Delete Slack integration Source: https://docs.gable.ai/api-reference/slack/delete-slack-integration /api-reference/bundled.yaml delete /v0/slack/delete Delete Slack integration # Get Slack channels for workspace Source: https://docs.gable.ai/api-reference/slack/get-slack-channels-for-workspace /api-reference/bundled.yaml get /v0/slack/channels Get Slack channels for workspace # Get the generated Slack install URL Source: https://docs.gable.ai/api-reference/slack/get-the-generated-slack-install-url /api-reference/bundled.yaml get /v0/slack/install Get the generated Slack install URL # Post a test message to the slack channel Source: https://docs.gable.ai/api-reference/slack/post-a-test-message-to-the-slack-channel /api-reference/bundled.yaml post /v0/slack/test Post a test message to the slack channel # Create a telemetry data point Source: https://docs.gable.ai/api-reference/telemetry/create-a-telemetry-data-point /api-reference/bundled.yaml post /v0/telemetry/ingest Create a telemetry data point for long term storage in the telemetry table # Create a webhook endpoint Source: https://docs.gable.ai/api-reference/webhook/create-a-webhook-endpoint /api-reference/bundled.yaml post /v0/webhooks Create a webhook endpoint # Delete the existing webhook Source: https://docs.gable.ai/api-reference/webhook/delete-the-existing-webhook /api-reference/bundled.yaml delete /v0/webhooks/{id} Delete the existing webhook # Get webhooks endpoints Source: https://docs.gable.ai/api-reference/webhook/get-webhooks-endpoints /api-reference/bundled.yaml get /v0/webhooks Get webhooks endpoints # Post a test message to the webhook Source: https://docs.gable.ai/api-reference/webhook/post-a-test-message-to-the-webhook /api-reference/bundled.yaml post /v0/webhooks/test Post a test message to the webhook # Update a webhook Source: https://docs.gable.ai/api-reference/webhook/update-a-webhook /api-reference/bundled.yaml put /v0/webhooks/{id} Update a webhook # Data Access Source: https://docs.gable.ai/docs/availability_security_compliance/data_access ## Summary * **Git Repositories**: The Gable CLI runs as part of the CI/CD process and relies on access to a local git repository that’s checked out on a CI/CD runner. Gable processes only the files it's explicitly configured to read, extracting code-level metadata used to derive data lineage. ## Scanning Code for Lineage Gable derives data lineage by statically analyzing your application code in your git repositories via the Gable CLI or provided GitHub Actions. This requires a local instance of the git repository to be available in either a development or CI/CD environment. Gable’s CLI only processes the files provided to the lineage command. Code-level metadata is sent to the Gable platform by the CLI via authenticated REST API. # High Availability & Disaster Recovery Source: https://docs.gable.ai/docs/availability_security_compliance/high_availability_disaster_recovery ## Multi-Region Replication Every Gable customer is assigned a primary and secondary region. Gable stores customer data in a serverless global Aurora RDS database, with a read & write instance in the primary region, and a read instance in the secondary region. In the event a region goes offline, Gable will promote the secondary region with little to no data loss, and minimal downtime. Moving to an automated active/passive failover using [Route 53 RNS failover](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html) is planned for future product iterations. Gable Architecture ## Multi-AZ Deployment Gable deploys resources, such as NAT Gateways, across three availability zones in each customer region. The primary Aurora RDS cluster is configured with a multi-AZ writer and reader instance for high availability, and Aurora performs an automatic failover in case of an issue that affects the writer instance. Gable Architecture ## Serverless Architecture Gable does not maintain any physical servers or virtual machines, relying entirely on serverless and managed cloud products. Processing and storage is conducted on servers hosted on and managed by Amazon Web Services. Gables serverless architecture has the following benefits: ### Availability * High availability: Gable's serverless architecture automatically handles the scaling and distribution of resources, ensuring Gable remains available even during spikes in traffic or failures of individual components. * Fault tolerance: Serverless architectures are designed to automatically recover from failures by dynamically provisioning new instances to replace failed ones, reducing downtime and improving overall system reliability. ### Scaling * Automatic scaling: Gable automatically scales customer instances based on demand, handling traffic spikes and load fluctuations without the need for manual intervention. * Granular scaling: Serverless platforms can scale individual functions independently, enabling Gable to allocate more resources to critical functions and optimize the performance of our application. * Scalability without architectural changes: Gable's serverless architecture allows each product instance to scale horizontally, reducing the risk of needing to make significant architectural changes due to scale issues. # Role Based Access Control Source: https://docs.gable.ai/docs/availability_security_compliance/role_based_access_control Gable provides enterprises with Role Based Access Control(RBAC) over all your data with Gable. RBAC ensures secure, scalable, and auditable access management by assigning permissions based on organizational roles instead of individuals. Each user is provided with a role that defines what actions they are able to perform within Gable. These limitations apply to UI and API based access. ## Roles There are three roles that can be attributed to any user. Only one role may be assigned to each user. You can assign any role to an user when they are invited but the default will be Viewer. The roles of an existing user can be changed at any time. ### Viewer Users with the Viewer Role are only able to read the various assets within Gable. This role should be the default role applied to all users. ### Editor Users with the Editor Role are able to read and write various assets within Gable. This role should be provided to members within your team who will be actively editing assets and creating contracts. ### Admin Users with the Admin Role are able to read, write and delete all assets within Gable. Admins are also responsible for the majority of the team setup such as SSO configuration and managing users. ## Permissions Table | Category | Action | Viewer | Editor | Admin | | ------------- | ------------------------- | ------ | ------ | ----- | | Assets | Read | Yes | Yes | Yes | | | Write | No | Yes | Yes | | | Delete | No | No | Yes | | Contracts | Read | Yes | Yes | Yes | | | Write | No | Yes | Yes | | | Delete | No | No | Yes | | Changelog | Read | Yes | Yes | Yes | | Actions | Read | Yes | Yes | Yes | | | Write | No | Yes | Yes | | | Delete | No | No | Yes | | Lineage | Read | Yes | Yes | Yes | | Team Settings | Profile Updates | Yes | Yes | Yes | | | Inviting New Users | No | No | Yes | | | Deleting Existing Users | No | No | Yes | | | API Keys Values | No | No | Yes | | | Enabling or modifying SSO | No | No | Yes | | | Slack Connection | No | Yes | Yes | ## Questions If you have any questions regarding RBAC support within Gable please reach out to [security@gable.ai](mailto:security@gable.ai) # Security and Compliance Source: https://docs.gable.ai/docs/availability_security_compliance/security_and_compliance Designed by data industry veterans, Gable was built with security and privacy in mind from day one. ## Resource Isolation Gable employs a single tenant architecture using AWS Organizations, meaning each customer is provisioned their own AWS Account, which serves as the fundamental security boundary in AWS. Gable follows the latest [best practices](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html#multi-account-strategy-best-practices-and-recommendations) for structuring a secure AWS Organization. Separating internal and customer resources into isolated AWS accounts provides the following benefits: * *Uniform Policy Enforcement*: Gable uses AWS Organizations policies to uniformly enforce security and compliance requirements for all AWS accounts managed by Gable. * *Security Controls*: AWS accounts act as an identity and access management isolation boundary. Customer accounts have specific role based control policies and mechanisms, enforced at the AWS Organization level, which limits access to a customer’s infrastructure and data. * *Network & Data Isolation*: In addition to acting as an access boundary, AWS accounts provide network and storage isolation by default. * *Many Teams*: Separating customer infrastructure from internal infrastructure allows only specific roles within Gable, like the incident response team, controlled access to customer infrastructure. * *Auditability*: Following AWS Organizations best practices, Gable maintains an isolated and restricted Security Logs account that stores the AWS CloudTrail logs enabled at the Organization level. ## Compliance SOC2 Badge * Gable completed our most recent annual SOC 2 Type 2 audit in June of 2025, you can request access to the report at [https://trust.gable.ai/](https://trust.gable.ai/). * Gable collects metadata, logs, and metrics for the purpose of identifying data reliability issues. However, we acknowledge that the service may collect and process personal data as part of query logs or through other functionality that you initiate within the Gable platform. If any such data is passed to Gable, it is used for the sole purpose of identifying data reliability issues. See our privacy policy for more details. ## Privacy ### [Privacy Policy](https://www.gable.ai/privacy-policy) Gable's team implements industry best practices across the board to protect the security of its infrastructure & services, and the data privacy of its customers. The following are only some of the elements of our security program and system architecture: * Gable will only collect metadata, logs, and metrics for the sole purpose of identifying data reliability issues. Your information will only be used to generate your own reports and will not be shared with any external parties. * Access to production systems is tightly controlled, and routinely audited. In cases where debugging or maintenance work is required, a minimal number of on-call engineers will be permitted to access the data necessary for this purpose. All data stored at rest, including on engineers laptops for debugging purposes, is encrypted. Should you have any questions about our privacy practices or this Privacy Policy, please email us at [privacy@gable.ai](mailto:privacy@gable.ai). ## Security * Gable does not maintain any physical servers or virtual machines. Processing and storage is conducted on servers hosted on and managed by Amazon Web Services. * All data is encrypted both at rest (AES-256) and in transit (TLS). * Following AWS Organizations [best practices](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/log-archive.html), organization wide CloudTrail audit logs are stored in a central log archive account with highly restricted access. * Gable leverages AWS Organization Service Control Policies to enforce best practices for all accounts created in the organization. * Access to all critical systems and production environments is centrally managed by our Identity Provider (Okta), which enforces multi-factor authentication. Accounts are automatically provisioned and decommissioned by our identity provider. Gable does not allow user/password auth for any critical systems, or production environments. Access to all systems is routinely audited. For any questions, or to report an issue, contact [security@gable.ai](mailto:security@gable.ai). # gable auth Source: https://docs.gable.ai/docs/cli/auth View configured Gable authentication information ## Usage ```bash theme={null} gable auth COMMAND [ARGS]... ``` ## Subcommands * **[`key`](key)** — Print the API Key gable is currently configured to use. * **[`npm`](npm)** — Retrieve temporary credentials for Gable's NPM repository. * **[`pip`](pip)** — Retrieve temporary credentials for Gable's Python package repository. # gable auth key Source: https://docs.gable.ai/docs/cli/auth/key Print the API Key gable is currently configured to use ## Usage ```bash theme={null} gable auth key [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------ | ---- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | # gable auth npm Source: https://docs.gable.ai/docs/cli/auth/npm Retrieve temporary credentials for Gable's NPM repository ## Usage ```bash theme={null} gable auth npm [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | | ---------------- | ------- | -------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | `-o`, `--output` | `npmrc` | `json` | | npmrc | Format of the output. Options are: npmrc (default), which you can echo directly into your .npmrc file, or json | | `-w`, `--write` | boolean | | false | If specified, adds entry to an existing .npmrc file, default is \~/.npmrc. If the file already contains a Gable NPM entry, it will be updated. If not, a new entry will be added. | | | `-f`, `--file` | text | | \~/.npmrc | The .npmrc file to write to if --write flag is set. Default is \~/.npmrc. The file must exist, or an error will be thrown. | | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | # gable auth pip Source: https://docs.gable.ai/docs/cli/auth/pip Retrieve temporary credentials for Gable's Python package repository ## Usage ```bash theme={null} gable auth pip [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | | ---------------- | ------- | -------- | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | `-o`, `--output` | `conf` | `json` | | conf | Format of the output. Options are: conf (default), which you can echo directly into your pip.conf file, or json | | `-w`, `--write` | boolean | | true | If specified, writes credentials to \~/.gable/.env file. Default is True. | | | `-f`, `--file` | text | | \~/.gable/.env | The file to write credentials to if --write flag is set. Default is \~/.gable/.env. | | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | # gable contract Source: https://docs.gable.ai/docs/cli/contract Commands for contracts ## Usage ```bash theme={null} gable contract COMMAND [ARGS]... ``` ## Subcommands * **[`bulk-update-enforcement-levels`](bulk-update-enforcement-levels)** — Updates the enforcement level of all contracts to the given enforcement level. * **[`publish`](publish)** — Publishes data contracts to Gable. * **[`validate`](validate)** — Validates the configuration of the data contract files. # gable contract bulk-update-enforcement-levels Source: https://docs.gable.ai/docs/cli/contract/bulk-update-enforcement-levels Updates the enforcement level of all contracts to the given enforcement level. If a data asset id pattern is provided, only the contracts that have associated data assets that match the provided data asset id pattern will be updated. ## Usage ```bash theme={null} gable contract bulk-update-enforcement-levels [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | | | | | ------------------------- | -------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | - | - | ----------------------------------------------- | | `--enforcement-level` | `RECORD` | `NOTIFY` | `ALERT` | `BLOCK` | `INACTIVE` | ✓ | | The enforcement level to set for all contracts. | | `--data-asset-id-pattern` | text | | | Regex pattern to match data asset IDs. Only the contracts that have associated data assets that match the provided data asset id pattern will be updated. | | | | | | `--dry-run` | boolean | | false | Show what would be updated without actually making changes. | | | | | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | | | | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | | | | ## Example ```bash theme={null}  gable contract bulk-update-enforcement-levels BLOCK gable contract bulk-update-enforcement-levels ALERT data-asset-id-pattern 'postgres://*' gable contract bulk-update-enforcement-levels BLOCK --dry-run ``` # gable contract publish Source: https://docs.gable.ai/docs/cli/contract/publish Publishes data contracts to Gable ## Usage ```bash theme={null} gable contract publish [CONTRACT_FILES] [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------ | ---- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | ## Arguments **`CONTRACT_FILES`** — Optional ## Example ```bash theme={null} gable contract publish contract1.yaml gable contract publish **/*.yaml ``` # gable contract validate Source: https://docs.gable.ai/docs/cli/contract/validate Validates the configuration of the data contract files ## Usage ```bash theme={null} gable contract validate [CONTRACT_FILES] [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------ | ---- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | ## Arguments **`CONTRACT_FILES`** — Optional ## Example ```bash theme={null}  gable contract validate contract1.yaml gable contract validate **/*.yaml ``` # gable data-asset Source: https://docs.gable.ai/docs/cli/data-asset Commands for data assets ## Usage ```bash theme={null} gable data-asset COMMAND [ARGS]... ``` ## Subcommands * **[`check`](check)** — Checks data asset(s) against a contract. * **[`create-contract`](create-contract)** — Creates the YAML contract specification for a list of data assets. * **[`delete`](delete)** — Delete a data asset by its resource name. * **[`list`](list)** — List all data assets. * **[`register`](register)** — Registers a data asset with Gable. * **[`show`](show)** — Shows the details of the requested data asset. # gable data-asset check Source: https://docs.gable.ai/docs/cli/data-asset/check Checks data asset(s) against a contract ## Usage ```bash theme={null} gable data-asset check [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | | | | | | | | | | | | | | | | ------------------------------- | ------------ | --------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | --------- | ------------ | ------ | ---- | ----------- | -------- | ------- | ----- | -------- | - | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--source-type` | `postgres` | `mysql` | `mssql` | `json_schema` | `avro` | `protobuf` | `python` | `pyspark` | `typescript` | `java` | `s3` | `dataframe` | `kotlin` | `swift` | `php` | `golang` | ✓ | | The type of data asset. For databases (postgres, mysql, mssql) the check will be performed for all tables within the database. For protobuf/avro the check will be performed for all file(s) | | `--include-unchanged-assets` | boolean | | false | Include assets that are the same as Gable's registered version of the asset. This is useful for checking the current state of an asset but should not be used for automated checks on branches. | | | | | | | | | | | | | | | | | `-o`, `--output` | `text` | `json` | `markdown` | | text | Format of the output. Options are: text (default), json, or markdown which is intended to be used as a PR comment | | | | | | | | | | | | | | | `--host`, `-h` | text | | | The host name of the production database, for example 'service-one.xxxxxxxxxxxx.us-east-1.rds.amazonaws.com'. Despite not needing to connect to the production database, the host is still needed to generate the unique resource name for the real database tables (data assets). | | | | | | | | | | | | | | | | | `--port`, `-p` | integer | | | The port of the production database. Despite not needing to connect to the production database, the port is still needed to generate the unique resource name for the real database tables (data assets). | | | | | | | | | | | | | | | | | `--db` | text | | | The name of the production database. Despite not needing to connect to the production database, the database name is still needed to generate the unique resource name for the real database tables (data assets). Database naming convention frequently includes the environment (production/development/test/staging) in the database name, so this value may not match the name of the database in the proxy database instance. If this is the case, you can set the --proxy-db value to the name of the database in the proxy instance, but we'll use the value of --db to generate the unique resource name for the data asset. For example, if your production database is 'prod\_service\_one', but your test database is 'test\_service\_one', you would set --db to 'prod\_service\_one' and --proxy-db to 'test\_service\_one'. | | | | | | | | | | | | | | | | | `--schema`, `-s` | text | | | The schema of the production database containing the table(s) to check. Despite not needing to connect to the production database, the schema is still needed to generate the unique resource name for the real database tables (data assets). Database naming convention frequently includes the environment (production/development/test/staging) in the schema name, so this value may not match the name of the schema in the proxy database instance. If this is the case, you can set the --proxy-schema value to the name of the schema in the proxy instance, but we'll use the value of --schema to generate the unique resource name for the data asset. For example, if your production schema is 'production', but your test database is 'test', you would set --schema to 'production' and --proxy-schema to 'test'. | | | | | | | | | | | | | | | | | `--table`, `--tables`, `-t` | text | | | A comma delimited list of the table(s) to check. If no table(s) are specified, all tables within the provided schema will be checked. Table names in the proxy database instance must match the table names in the production database instance, even if the database or schema names are different. | | | | | | | | | | | | | | | | | `--proxy-host`, `-ph` | text | | | The host string of the database instance that serves as the proxy for the production database. This is the database that Gable will connect to when checking tables in the CI/CD workflow. | | | | | | | | | | | | | | | | | `--proxy-port`, `-pp` | integer | | | The port of the database instance that serves as the proxy for the production database. This is the database that Gable will connect to when checking tables in the CI/CD workflow. | | | | | | | | | | | | | | | | | `--proxy-db`, `-pdb` | text | | | Only needed if the name of the database in the proxy instance is different than the name of the production database. If not specified, the value of --db will be used to generate the unique resource name for the data asset. For example, if your production database is 'prod\_service\_one', but your test database is 'test\_service\_one', you would set --db to 'prod\_service\_one' and --proxy-db to 'test\_service\_one'. | | | | | | | | | | | | | | | | | `--proxy-schema`, `-ps` | text | | | Only needed if the name of the schema in the proxy instance is different than the name of the schema in the production database. If not specified, the value of --schema will be used to generate the unique resource name for the data asset. For example, if your production schema is 'production', but your test database is 'test', you would set --schema to 'production' and --proxy-schema to 'test'. | | | | | | | | | | | | | | | | | `--proxy-user`, `-pu` | text | | | The user that will be used to connect to the proxy database instance that serves as the proxy for the production database. This is the database that Gable will connect to when checking tables in the CI/CD workflow. | | | | | | | | | | | | | | | | | `--proxy-password`, `-ppw` | text | | | If specified, the password that will be used to connect to the proxy database instance that serves as the proxy for the production database. This is the database that Gable will connect to when checking tables in the CI/CD workflow. | | | | | | | | | | | | | | | | | `--files` | tuple | | | Space delimited path(s) to the assets to check, with support for glob patterns. | | | | | | | | | | | | | | | | | `--project-root` | text | | | This should be the directory location of the Python project that will be analyzed. | | | | | | | | | | | | | | | | | `--emitter-function` | text | | | Name of the emitter function | | | | | | | | | | | | | | | | | `--emitter-payload-parameter` | text | | | Name of the parameter representing the event payload | | | | | | | | | | | | | | | | | `--event-name-key` | text | | | Input must be a "." delimited list of field property access directives or array indexes to the event name key field. The field property access directive is a valid dictionary key, or the wildcard character \*. The array index is square brackets\[] with either a digit in it (targeting a specific element of the array), or \* (targeting all elements in the array). Example: "fieldName.\[0].eventName" describes the access pay to the event name in: \{'fieldName': \[\{'eventName': 'event\_one'}]}. | | | | | | | | | | | | | | | | | `--emitter-file-path` | text | | | Relative path from the root of the project to the file that contains the emitter function | | | | | | | | | | | | | | | | | `--exclude` | text | | | Comma separated list of paths to be excluded from the analysis, with support for glob patterns. Gable automatically excludes '\*\*/node\_modules, \*\*/**pycache**, **/.\*'. Example: '**/tests,docs/\*' | | | | | | | | | | | | | | | | | `--project-root` | text | | | This should be the directory location of the Typescript project that will be analyzed. | | | | | | | | | | | | | | | | | `--library` | `brandviews` | `segment` | `amplitude` | `udf` | | | This should indicate the library emitting the events you want detected as data assets. | | | | | | | | | | | | | | `--rules-file` | text | | | File containing match rules for egress points. Can be used in conjunction with --library, but takes precedence over --emitter-\* args. | | | | | | | | | | | | | | | | | `--node-modules-include` | text | | | Comma delimited list of filenames or patterns of node modules to include in the analysis. | | | | | | | | | | | | | | | | | `--emitter-file-path` | text | | | DEPRECATED: Use --emitter-location instead. | | | | | | | | | | | | | | | | | `--emitter-location` | text | | | NPM package name, or relative path from the root of the project to the file that contains the emitter function | | | | | | | | | | | | | | | | | `--emitter-function` | text | | | Name of the emitter function. This can be a standalone function like 'trackEvent' or a class method like 'AnalyticsClient.track' | | | | | | | | | | | | | | | | | `--emitter-payload-parameter` | text | | | Name of the parameter representing the event payload | | | | | | | | | | | | | | | | | `--emitter-name-parameter` | text | | | Name of the emitter function parameter that contains the event name. Either this option, or the --event-name-key option must be provided when using --emitter-function. | | | | | | | | | | | | | | | | | `--event-name-key` | text | | | Name of the event property that contains the event name. Either this option, or the --emitter-name-parameter option must be provided when using --emitter-function. | | | | | | | | | | | | | | | | | `--exclude` | text | | | Comma delimited list of filenames or extended globbing patterns of node modules to include in the analysis. Defaults toexclude common test patterns like \*.test.js, \*.spec.js, etc. | | | | | | | | | | | | | | | | | `--project-root` | text | | | This should be the directory location of the project containing the Pyspark job that will analyzed. | | | | | | | | | | | | | | | | | `--spark-job-entrypoint` | text | | | Entrypoint to execute spark job, starting with python file and including any arguments. Example: "main.py --arg1 value1 --arg2 value2" | | | | | | | | | | | | | | | | | `--connection-string` | text | | | Connection string to Hive cluster used to pull schemas of input tables | | | | | | | | | | | | | | | | | `--metastore-connection-string` | text | | | Connection string to the Hive metastore used to pull S3 to table mappings | | | | | | | | | | | | | | | | | `--csv-schema-file` | text | | | Path to the CSV schema file | | | | | | | | | | | | | | | | | `--csv-path-to-table-file` | text | | | Path to a CSV schema file containing a mapping of Delta table paths to table names | | | | | | | | | | | | | | | | | `--config-file` | file | | | Path to YAML configuration file containing the necessary configurations for the Pyspark job. | | | | | | | | | | | | | | | | | `--config-entrypoint-path` | text | | | The path to the property of the YAML config file containing the spark job entrypoint, which is the main Python script for the job. For example: 'spec.mainApplicationFile' | | | | | | | | | | | | | | | | | `--config-args-path` | text | | | The path to the property of the YAML config file containing the spark job arguments. For example: 'spec.arguments' | | | | | | | | | | | | | | | | | `--bucket` | text | | | This should indicate the S3 bucket containing the files to be analyzed. | | | | | | | | | | | | | | | | | `--include-prefix` | text | | | This optional parameter allows you to specify what to include in your S3 bucket. If not specified, all files in the bucket will be analyzed. | | | | | | | | | | | | | | | | | `--exclude-prefix` | text | | | This optional parameter allows you to specify what to exclude in your S3 bucket. If --include-prefix is specified, this parameter must be a subset of include to be considered. | | | | | | | | | | | | | | | | | `--lookback-days` | integer | | 2 | Number of days to look back from the latest day in the list of paths, defaults to 2. For example if the latest path is 2024/01/02, and lookback\_days is 3, then the paths return will have 2024/01/02, 2024/01/01, and 2023/12/31 | | | | | | | | | | | | | | | | | `--history` | boolean | | false | This optional parameter allows you to do a historical analysis between 2 dates. | | | | | | | | | | | | | | | | | `--skip-profiling` | boolean | | false | This optional parameter allows you to turn off data profiling. | | | | | | | | | | | | | | | | | `--row-sample-count` | integer | | 1000 | Number of rows of data per file to sample for schema detection and data profiling. Default is 1000. Accuracy increases with larger sample size, but processing time and AWS costs also increases. | | | | | | | | | | | | | | | | | `--recent-file-count` | integer (≥1) | | 3 | Specifies the number of most recent files whose schema will be used for inference per data asset. Default is 3. For example, if the latest file is 2024/01/10 and `--recent-file-count` is 2, then only files 2024/01/10 and 2024/01/09 will be used for schema inference, even if --lookback-days is greater than 2. Increase this value to improve schema accuracy over more schema history, at the cost of increased runtime. Must be at least 1. | | | | | | | | | | | | | | | | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | | | | | | | | | | | | | | | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | | | | | | | | | | | | | | | ## Example ```bash theme={null} gable data-asset check --source-type protobuf --files ./**/*.proto ``` # gable data-asset create-contract Source: https://docs.gable.ai/docs/cli/data-asset/create-contract Creates the YAML contract specification for a list of data assets. If a regex pattern (`--data-asset-id-pattern`) is provided, the command will create contracts for all data assets that match the pattern as well as the data assets provided in. The specification that is produced is based off the registered data asset but the user will need to fill in places marked with 'PLACEHOLDER:' such as field descriptions and ownership information. ## Usage ```bash theme={null} gable data-asset create-contract [DATA_ASSET_IDS] [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------------------- | ---- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------- | | `--data-asset-id-pattern` | text | | | Regex pattern to match data asset IDs. Contracts will be created for all data asset IDs that match this pattern. | | `--output-dir` | path | | | Directory to output contracts. This directory must exist | ## Arguments **`DATA_ASSET_IDS`** — Optional ## Example ```bash theme={null} gable data-asset create-contract postgres://sample.host:5432:db.public.table --output-dir contracts gable data-asset create-contract --data-asset-id-pattern "postgres://*" --output-dir contracts ``` # gable data-asset delete Source: https://docs.gable.ai/docs/cli/data-asset/delete Delete a data asset by its resource name. ## Usage ```bash theme={null} gable data-asset delete DATA_ASSET_RESOURCE_NAME [OPTIONS] ``` ## Arguments **`DATA_ASSET_RESOURCE_NAME`** — Required ## Example ```bash theme={null} gable data-asset delete postgres://sample.host:5432:db.public.table ``` # gable data-asset list Source: https://docs.gable.ai/docs/cli/data-asset/list List all data assets ## Usage ```bash theme={null} gable data-asset list [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | | ---------------- | ------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | | `-o`, `--output` | `table` | `json` | | table | Format of the output. Options are: table (default) or json | | `--full` | boolean | | false | Return full data asset details including domain and path | | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | # gable data-asset register Source: https://docs.gable.ai/docs/cli/data-asset/register Registers a data asset with Gable ## Usage ```bash theme={null} gable data-asset register [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | | | | | | | | | | | | | | | | ------------------------------- | ------------ | --------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | ---------- | -------------------------------------------------------------------------------------- | --------- | ------------ | ------ | ---- | ----------- | -------- | ------- | ----- | -------- | - | - | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--source-type` | `postgres` | `mysql` | `mssql` | `json_schema` | `avro` | `protobuf` | `python` | `pyspark` | `typescript` | `java` | `s3` | `dataframe` | `kotlin` | `swift` | `php` | `golang` | | | The type of data asset. For databases (mysql, mssql) a data asset is a table within the database. For protobuf/avro a data asset is message/schema within a file. | | `--dry-run` | boolean | | false | Perform a dry run without actually registering the data asset. | | | | | | | | | | | | | | | | | `--host`, `-h` | text | | | The host name of the production database, for example 'service-one.xxxxxxxxxxxx.us-east-1.rds.amazonaws.com'. Despite not needing to connect to the production database, the host is still needed to generate the unique resource name for the real database tables (data assets). | | | | | | | | | | | | | | | | | `--port`, `-p` | integer | | | The port of the production database. Despite not needing to connect to the production database, the port is still needed to generate the unique resource name for the real database tables (data assets). | | | | | | | | | | | | | | | | | `--db` | text | | | The name of the production database. Despite not needing to connect to the production database, the database name is still needed to generate the unique resource name for the real database tables (data assets). Database naming convention frequently includes the environment (production/development/test/staging) in the database name, so this value may not match the name of the database in the proxy database instance. If this is the case, you can set the --proxy-db value to the name of the database in the proxy instance, but we'll use the value of --db to generate the unique resource name for the data asset. For example, if your production database is 'prod\_service\_one', but your test database is 'test\_service\_one', you would set --db to 'prod\_service\_one' and --proxy-db to 'test\_service\_one'. | | | | | | | | | | | | | | | | | `--schema`, `-s` | text | | | The schema of the production database containing the table(s) to register. Despite not needing to connect to the production database, the schema is still needed to generate the unique resource name for the real database tables (data assets). Database naming convention frequently includes the environment (production/development/test/staging) in the schema name, so this value may not match the name of the schema in the proxy database instance. If this is the case, you can set the --proxy-schema value to the name of the schema in the proxy instance, but we'll use the value of --schema to generate the unique resource name for the data asset. For example, if your production schema is 'production', but your test database is 'test', you would set --schema to 'production' and --proxy-schema to 'test'. | | | | | | | | | | | | | | | | | `--table`, `--tables`, `-t` | text | | | A comma delimited list of the table(s) to register. If no table(s) are specified, all tables within the provided schema will be registered. Table names in the proxy database instance must match the table names in the production database instance, even if the database or schema names are different. | | | | | | | | | | | | | | | | | `--proxy-host`, `-ph` | text | | | The host string of the database instance that serves as the proxy for the production database. This is the database that Gable will connect to when registering tables in the CI/CD workflow. | | | | | | | | | | | | | | | | | `--proxy-port`, `-pp` | integer | | | The port of the database instance that serves as the proxy for the production database. This is the database that Gable will connect to when registering tables in the CI/CD workflow. | | | | | | | | | | | | | | | | | `--proxy-db`, `-pdb` | text | | | Only needed if the name of the database in the proxy instance is different than the name of the production database. If not specified, the value of --db will be used to generate the unique resource name for the data asset. For example, if your production database is 'prod\_service\_one', but your test database is 'test\_service\_one', you would set --db to 'prod\_service\_one' and --proxy-db to 'test\_service\_one'. | | | | | | | | | | | | | | | | | `--proxy-schema`, `-ps` | text | | | Only needed if the name of the schema in the proxy instance is different than the name of the schema in the production database. If not specified, the value of --schema will be used to generate the unique resource name for the data asset. For example, if your production schema is 'production', but your test database is 'test', you would set --schema to 'production' and --proxy-schema to 'test'. | | | | | | | | | | | | | | | | | `--proxy-user`, `-pu` | text | | | The user that will be used to connect to the proxy database instance that serves as the proxy for the production database. This is the database that Gable will connect to when registering tables in the CI/CD workflow. | | | | | | | | | | | | | | | | | `--proxy-password`, `-ppw` | text | | | If specified, the password that will be used to connect to the proxy database instance that serves as the proxy for the production database. This is the database that Gable will connect to when registering tables in the CI/CD workflow. | | | | | | | | | | | | | | | | | `--files` | tuple | | | Space delimited path(s) to the assets to register, with support for glob patterns. | | | | | | | | | | | | | | | | | `--project-root` | text | | | This should be the directory location of the Python project that will be analyzed. | | | | | | | | | | | | | | | | | `--emitter-function` | text | | | Name of the emitter function | | | | | | | | | | | | | | | | | `--emitter-payload-parameter` | text | | | Name of the parameter representing the event payload | | | | | | | | | | | | | | | | | `--event-name-key` | text | | | Input must be a "." delimited list of field property access directives or array indexes to the event name key field. The field property access directive is a valid dictionary key, or the wildcard character \*. The array index is square brackets\[] with either a digit in it (targeting a specific element of the array), or \* (targeting all elements in the array). Example: "fieldName.\[0].eventName" describes the access pay to the event name in: \{'fieldName': \[\{'eventName': 'event\_one'}]}. | | | | | | | | | | | | | | | | | `--emitter-file-path` | text | | | Relative path from the root of the project to the file that contains the emitter function | | | | | | | | | | | | | | | | | `--exclude` | text | | | Comma separated list of paths to be excluded from the analysis, with support for glob patterns. Gable automatically excludes '\*\*/node\_modules, \*\*/**pycache**, **/.\*'. Example: '**/tests,docs/\*' | | | | | | | | | | | | | | | | | `--project-root` | text | | | This should be the directory location of the project containing the Pyspark job that will analyzed. | | | | | | | | | | | | | | | | | `--spark-job-entrypoint` | text | | | Entrypoint to execute spark job, starting with python file and including any arguments. Example: "main.py --arg1 value1 --arg2 value2" | | | | | | | | | | | | | | | | | `--connection-string` | text | | | Connection string to Hive cluster used to pull schemas of input tables | | | | | | | | | | | | | | | | | `--metastore-connection-string` | text | | | Connection string to the Hive metastore used to pull S3 to table mappings | | | | | | | | | | | | | | | | | `--csv-schema-file` | text | | | Path to the CSV schema file | | | | | | | | | | | | | | | | | `--csv-path-to-table-file` | text | | | Path to a CSV schema file containing a mapping of Delta table paths to table names | | | | | | | | | | | | | | | | | `--config-file` | file | | | Path to YAML configuration file containing the necessary configurations for the Pyspark job. | | | | | | | | | | | | | | | | | `--config-entrypoint-path` | text | | | The path to the property of the YAML config file containing the spark job entrypoint, which is the main Python script for the job. For example: 'spec.mainApplicationFile' | | | | | | | | | | | | | | | | | `--config-args-path` | text | | | The path to the property of the YAML config file containing the spark job arguments. For example: 'spec.arguments' | | | | | | | | | | | | | | | | | `--project-root` | text | | | This should be the directory location of the Typescript project that will be analyzed. | | | | | | | | | | | | | | | | | `--library` | `brandviews` | `segment` | `amplitude` | `udf` | | | This should indicate the library emitting the events you want detected as data assets. | | | | | | | | | | | | | | `--rules-file` | text | | | File containing match rules for egress points. Can be used in conjunction with --library, but takes precedence over --emitter-\* args. | | | | | | | | | | | | | | | | | `--node-modules-include` | text | | | Comma delimited list of filenames or patterns of node modules to include in the analysis. | | | | | | | | | | | | | | | | | `--emitter-file-path` | text | | | DEPRECATED: Use --emitter-location instead. | | | | | | | | | | | | | | | | | `--emitter-location` | text | | | NPM package name, or relative path from the root of the project to the file that contains the emitter function | | | | | | | | | | | | | | | | | `--emitter-function` | text | | | Name of the emitter function. This can be a standalone function like 'trackEvent' or a class method like 'AnalyticsClient.track' | | | | | | | | | | | | | | | | | `--emitter-payload-parameter` | text | | | Name of the parameter representing the event payload | | | | | | | | | | | | | | | | | `--emitter-name-parameter` | text | | | Name of the emitter function parameter that contains the event name. Either this option, or the --event-name-key option must be provided when using --emitter-function. | | | | | | | | | | | | | | | | | `--event-name-key` | text | | | Name of the event property that contains the event name. Either this option, or the --emitter-name-parameter option must be provided when using --emitter-function. | | | | | | | | | | | | | | | | | `--exclude` | text | | | Comma delimited list of filenames or extended globbing patterns of node modules to include in the analysis. Defaults toexclude common test patterns like \*.test.js, \*.spec.js, etc. | | | | | | | | | | | | | | | | | `--inventory-dir` | text | | | Local directory or S3 URI where inventory .csv.gz files are stored. Used when --use-inventory is enabled. | | | | | | | | | | | | | | | | | `--use-inventory` | boolean | | false | Enable S3 Inventory-based discovery instead of listing files live from S3. | | | | | | | | | | | | | | | | | `--bucket` | text | | | This should indicate the S3 bucket containing the files to be analyzed. | | | | | | | | | | | | | | | | | `--include-prefix` | text | | | This optional parameter allows you to specify what to include in your S3 bucket. If not specified, all files in the bucket will be analyzed. | | | | | | | | | | | | | | | | | `--exclude-prefix` | text | | | This optional parameter allows you to specify what to exclude in your S3 bucket. If --include-prefix is specified, this parameter must be a subset of include to be considered. | | | | | | | | | | | | | | | | | `--lookback-days` | integer | | 2 | Number of days to look back from the latest day in the list of paths, defaults to 2. For example if the latest path is 2024/01/02, and lookback\_days is 3, then the paths return will have 2024/01/02, 2024/01/01, and 2023/12/31 | | | | | | | | | | | | | | | | | `--history` | boolean | | false | This optional parameter allows you to do a historical analysis between 2 dates. | | | | | | | | | | | | | | | | | `--skip-profiling` | boolean | | false | This optional parameter allows you to turn off data profiling. | | | | | | | | | | | | | | | | | `--row-sample-count` | integer | | 1000 | Number of rows of data per file to sample for schema detection and data profiling. Default is 1000. Accuracy increases with larger sample size, but processing time and AWS costs also increases. | | | | | | | | | | | | | | | | | `--recent-file-count` | integer (≥1) | | 3 | Specifies the number of most recent files whose schema will be used for inference per data asset. Default is 3. For example, if the latest file is 2024/01/10 and `--recent-file-count` is 2, then only files 2024/01/10 and 2024/01/09 will be used for schema inference, even if --lookback-days is greater than 2. Increase this value to improve schema accuracy over more schema history, at the cost of increased runtime. Must be at least 1. | | | | | | | | | | | | | | | | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | | | | | | | | | | | | | | | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | | | | | | | | | | | | | | | ## Example ```bash theme={null} gable data-asset register --source-type mysql \ --host prod.pg.db.host --port 5432 --db transit --schema public --table routes \ --proxy-host localhost --proxy-port 5432 --proxy-user root --proxy-password password ``` # gable data-asset show Source: https://docs.gable.ai/docs/cli/data-asset/show Shows the details of the requested data asset. ## Usage ```bash theme={null} gable data-asset show DATA_ASSET_RESOURCE_NAME [OPTIONS] ``` ## Arguments **`DATA_ASSET_RESOURCE_NAME`** — Required ## Example ```bash theme={null} gable data-asset show "postgres://sample.host:5432:db.public.table" ``` # CLI Reference Source: https://docs.gable.ai/docs/cli/introduction The Gable CLI provides commands for registering and checking data assets, managing data contracts, and running lineage analysis. ## Installation ```bash theme={null} pip install gable ``` ## Authentication All commands that communicate with the Gable API require `--api-key` and `--endpoint`, which can also be provided via environment variables: ```bash theme={null} export GABLE_API_KEY=your-api-key export GABLE_API_ENDPOINT=https://api-yourorg.gable.ai ``` ## Global Options | Option | Description | | ------------ | ------------------------------------------------ | | `--api-key` | API key for Gable. Env: `GABLE_API_KEY` | | `--endpoint` | Customer API endpoint. Env: `GABLE_API_ENDPOINT` | | `--debug` | Enable debug logging | | `--trace` | Enable trace (verbose) logging | | `--version` | Show the CLI version and exit | | `--help` | Show help and exit | # gable lineage Source: https://docs.gable.ai/docs/cli/lineage Commands for data lineage analysis using static code analysis (SCA) ## Usage ```bash theme={null} gable lineage COMMAND [ARGS]... ``` ## Subcommands * **[`compare`](compare)** — Compare two lineage result files and print a diff. * **[`component`](component)** — Manage CODE lineage components. * **[`datastore`](datastore)** — Manage DATA\_STORE lineage components. * **[`edge`](edge)** — Manage cross-service lineage edges. * **[`export`](export)** — Export lineage data from Gable. * **[`scan`](scan)** — Scan a project for data lineage using static code analysis (SCA). * **[`upload`](upload)** — Upload lineage data to Gable. # gable lineage compare Source: https://docs.gable.ai/docs/cli/lineage/compare Compare two lineage result files and print a diff. ## Usage ```bash theme={null} gable lineage compare [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | | ---------- | ------ | -------- | ------- | ---------------------------------- | ------------------------------ | | `--left` | path | ✓ | | The baseline lineage results file. | | | `--right` | path | ✓ | | The updated lineage results file. | | | `--format` | `text` | `json` | | text | Output format for the compare. | ## Example ```bash theme={null} gable lineage compare --left ./old-results.json --right ./new-results.json ``` # gable lineage component Source: https://docs.gable.ai/docs/cli/lineage/component Manage CODE lineage components. ## Usage ```bash theme={null} gable lineage component COMMAND [ARGS]... ``` ## Subcommands * **[`get`](get)** — Inspect a CODE component. * **[`list`](list)** — List CODE components. * **[`path`](path)** — Manage paths on CODE components. * **[`versions`](versions)** — List version history for a CODE component. # gable lineage component get Source: https://docs.gable.ai/docs/cli/lineage/component/get Inspect a CODE component. Use `component path list` to see its paths. ## Usage ```bash theme={null} gable lineage component get NAME_OR_ID [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | --------------- | ---- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--version` | text | | | Fetch a specific historical version. | | `--output-path` | text | | | Write the component to a file instead of stdout. | ## Arguments **`NAME_OR_ID`** — Required # gable lineage component list Source: https://docs.gable.ai/docs/cli/lineage/component/list List CODE components. ## Usage ```bash theme={null} gable lineage component list [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------- | ------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--search` | text | | | Filter components by name prefix. | | `--namespace` | text | | | Filter by namespace. | | `--pager` | boolean | | false | Have output sent to a pager for viewing, e.g. less. | # gable lineage component path Source: https://docs.gable.ai/docs/cli/lineage/component/path Manage paths on CODE components. ## Usage ```bash theme={null} gable lineage component path COMMAND [ARGS]... ``` ## Subcommands * **[`add`](add)** — Add a new path to a CODE component. * **[`generate`](generate)** — Generate an empty template for adding a path. * **[`get`](get)** — Get a path and optionally write it to a file for editing. * **[`list`](list)** — List paths on a component (CODE components only). * **[`remove`](remove)** — Remove a path from a CODE component. * **[`update`](update)** — Update a path on a CODE component. # gable lineage component path add Source: https://docs.gable.ai/docs/cli/lineage/component/path/add Add a new path to a CODE component. ## Usage ```bash theme={null} gable lineage component path add [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------------- | ------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--component` | text | ✓ | | Component name or UUID. | | `--from-file` | text | | | Path to JSON file containing path definition, or pipe JSON to stdin. | | `--dry-run` | boolean | | false | Preview changes without applying. | | `--effective-since` | text | | | Pin mutation to a specific commit SHA. | # gable lineage component path generate Source: https://docs.gable.ai/docs/cli/lineage/component/path/generate Generate an empty template for adding a path. Used in tandem with path add --from-file. ## Usage ```bash theme={null} gable lineage component path generate [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | --------------- | ---- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--output-path` | text | | | Where to write the empty JSON path template file. | # gable lineage component path get Source: https://docs.gable.ai/docs/cli/lineage/component/path/get Get a path and optionally write it to a file for editing. Outputs editable JSON (excluding read-only fields) for use with path update --from-file. ## Usage ```bash theme={null} gable lineage component path get [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | --------------- | ---- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--component` | text | ✓ | | Component name or UUID. | | `--path-id` | text | ✓ | | Path ID. | | `--output-path` | text | | | Write the path to a file instead of stdout. | # gable lineage component path list Source: https://docs.gable.ai/docs/cli/lineage/component/path/list List paths on a component (CODE components only). ## Usage ```bash theme={null} gable lineage component path list [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | | ------------- | ----------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | | `--component` | text | ✓ | | Component name or UUID. | | | `--mode` | `collapsed` | `all` | | | Path projection mode (collapsed=effective state, all=scan+BYO). | | `--pager` | boolean | | false | Have output sent to a pager for viewing, e.g. less. | | # gable lineage component path remove Source: https://docs.gable.ai/docs/cli/lineage/component/path/remove Remove a path from a CODE component. ## Usage ```bash theme={null} gable lineage component path remove [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------------- | ------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--component` | text | ✓ | | Component name or UUID. | | `--path-id` | text | ✓ | | Path ID. | | `--dry-run` | boolean | | false | Preview changes without applying. | | `--effective-since` | text | | | Pin mutation to a specific commit SHA. | # gable lineage component path update Source: https://docs.gable.ai/docs/cli/lineage/component/path/update Update a path on a CODE component. Compares the path in --from-file against the remote state and applies the changes (or previews them with --dry-run). Use path get --output-path to export a path for editing first. ## Usage ```bash theme={null} gable lineage component path update [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------------- | ------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--component` | text | ✓ | | Component name or UUID. | | `--path-id` | text | ✓ | | Path ID. | | `--from-file` | text | | | Path to JSON file containing path definition, or pipe JSON to stdin. | | `--dry-run` | boolean | | false | Preview changes without applying. | | `--effective-since` | text | | | Pin mutation to a specific commit SHA. | # gable lineage component versions Source: https://docs.gable.ai/docs/cli/lineage/component/versions List version history for a CODE component. ## Usage ```bash theme={null} gable lineage component versions NAME_OR_ID [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------ | ------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--pager` | boolean | | false | Have output sent to a pager for viewing, e.g. less. | ## Arguments **`NAME_OR_ID`** — Required # gable lineage datastore Source: https://docs.gable.ai/docs/cli/lineage/datastore Manage DATA\_STORE lineage components. ## Usage ```bash theme={null} gable lineage datastore COMMAND [ARGS]... ``` ## Subcommands * **[`add`](add)** — Create a new DATA\_STORE component. * **[`generate`](generate)** — Generate an empty DATA\_STORE template, used with `datastore add`. * **[`get`](get)** — Get a DATA\_STORE component as editable JSON for round-trip updates. * **[`list`](list)** — List DATA\_STORE components. * **[`update`](update)** — Update a DATA\_STORE component (full replacement of editable fields). # gable lineage datastore add Source: https://docs.gable.ai/docs/cli/lineage/datastore/add Create a new DATA\_STORE component. ## Usage ```bash theme={null} gable lineage datastore add [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------- | ------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--from-file` | text | | | Path to JSON file containing the component, or pipe JSON to stdin. | | `--dry-run` | boolean | | false | Preview the component that would be created without applying. | # gable lineage datastore generate Source: https://docs.gable.ai/docs/cli/lineage/datastore/generate Generate an empty DATA\_STORE template, used with `datastore add`. ## Usage ```bash theme={null} gable lineage datastore generate [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | --------------- | ---- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--output-path` | text | | | Where to write the empty JSON component template file. | # gable lineage datastore get Source: https://docs.gable.ai/docs/cli/lineage/datastore/get Get a DATA\_STORE component as editable JSON for round-trip updates. ## Usage ```bash theme={null} gable lineage datastore get NAME_OR_ID [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | --------------- | ---- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--output-path` | text | | | Write the component to a file instead of stdout. | ## Arguments **`NAME_OR_ID`** — Required # gable lineage datastore list Source: https://docs.gable.ai/docs/cli/lineage/datastore/list List DATA\_STORE components. ## Usage ```bash theme={null} gable lineage datastore list [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------- | ------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--search` | text | | | Filter components by name prefix. | | `--namespace` | text | | | Filter by namespace. | | `--pager` | boolean | | false | Have output sent to a pager for viewing, e.g. less. | # gable lineage datastore update Source: https://docs.gable.ai/docs/cli/lineage/datastore/update Update a DATA\_STORE component (full replacement of editable fields). ## Usage ```bash theme={null} gable lineage datastore update NAME_OR_ID [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------- | ------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--from-file` | text | | | Path to JSON file containing the component, or pipe JSON to stdin. | | `--dry-run` | boolean | | false | Preview changes without applying. | ## Arguments **`NAME_OR_ID`** — Required # gable lineage edge Source: https://docs.gable.ai/docs/cli/lineage/edge Manage cross-service lineage edges. ## Usage ```bash theme={null} gable lineage edge COMMAND [ARGS]... ``` ## Subcommands * **[`add`](add)** — Create a new cross-service edge. * **[`generate`](generate)** — Generate an empty template for adding an edge, used in tandem with gable lineage edge add --from-file. * **[`get`](get)** — Get a cross-service edge and optionally write it to a file for editing. * **[`list`](list)** — List all cross-service edges. * **[`remove`](remove)** — Remove a cross-service edge. * **[`update`](update)** — Update a cross-service edge. # gable lineage edge add Source: https://docs.gable.ai/docs/cli/lineage/edge/add Create a new cross-service edge. ## Usage ```bash theme={null} gable lineage edge add [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------- | ------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--from-file` | text | | | Path to JSON file containing edge definition, or pipe JSON to stdin. | | `--dry-run` | boolean | | false | Preview changes without applying. | # gable lineage edge generate Source: https://docs.gable.ai/docs/cli/lineage/edge/generate Generate an empty template for adding an edge, used in tandem with gable lineage edge add --from-file. Optionally provide a file path of where to write and what to name the file. ## Usage ```bash theme={null} gable lineage edge generate [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | --------------- | ---- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--output-path` | text | | | Where to write the empty JSON edge template file. | # gable lineage edge get Source: https://docs.gable.ai/docs/cli/lineage/edge/get Get a cross-service edge and optionally write it to a file for editing. ## Usage ```bash theme={null} gable lineage edge get EDGE_ID [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | --------------- | ---- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--output-path` | text | | | Write the edge to a file instead of stdout. | ## Arguments **`EDGE_ID`** — Required # gable lineage edge list Source: https://docs.gable.ai/docs/cli/lineage/edge/list List all cross-service edges. ## Usage ```bash theme={null} gable lineage edge list [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------- | ------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--namespace` | text | | | Filter edges by namespace. | | `--source` | text | | | Filter edges by source component name. | | `--sink` | text | | | Filter edges by destination component name. | | `--pager` | boolean | | false | Have output sent to a pager for viewing, e.g. less. | # gable lineage edge remove Source: https://docs.gable.ai/docs/cli/lineage/edge/remove Remove a cross-service edge. ## Usage ```bash theme={null} gable lineage edge remove EDGE_ID [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------ | ------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--dry-run` | boolean | | false | Preview changes without applying. | ## Arguments **`EDGE_ID`** — Required # gable lineage edge update Source: https://docs.gable.ai/docs/cli/lineage/edge/update Update a cross-service edge. Compares the edge in --from-file against the remote state and applies the changes (or previews them with --dry-run). Use edge get --output-path to export an edge for editing first. ## Usage ```bash theme={null} gable lineage edge update EDGE_ID [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------- | ------- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | | `--from-file` | text | | | Path to JSON file containing edge definition, or pipe JSON to stdin. | | `--dry-run` | boolean | | false | Preview changes without applying. | ## Arguments **`EDGE_ID`** — Required # gable lineage export Source: https://docs.gable.ai/docs/cli/lineage/export Export lineage data from Gable. ## Usage ```bash theme={null} gable lineage export [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ---------- | ---- | -------- | ------- | ------------------------------------------------------------------- | | `--run-id` | text | ✓ | | Get the cross-service components for a given run-id (now event-id). | ## Example ```bash theme={null} gable lineage export ``` # gable lineage scan Source: https://docs.gable.ai/docs/cli/lineage/scan Scan a project for data lineage using static code analysis (SCA). ## Usage ```bash theme={null} gable lineage scan [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | | ------------------------------ | ---------------- | ------------ | ------- | ----------------------------------------------------------------------------- | -------------------------------------------- | | `--project-root` | path | ✓ | | The root directory of the project that will be analyzed. | | | `--language` | `java` | `typescript` | | java | The programming language of the project. | | `--build-command` | text | | | The build command used to build the project (e.g. mvn clean install). | | | `--java-version` | text | | 17 | The version of Java used to build the project. | | | `--dataflow-config-file` | path | | | The path to the dataflow config JSON file. | | | `--dataflow-config-files` | text | | | Multi option for dataflow config files. Overridden by --dataflow-config-file. | | | `--schema-depth` | integer | | | The max depth of the schemas to be extracted. | | | `--output` | path | | | File path to output results. | | | `--sca-mode` | `asset-detector` | `prime` | | asset-detector | Select which sca backend to use for the scan | | `--prime-annotation` | text | | | Prime annotation used for analysis. Can be repeated. | | | `--prime-exclude-pattern` | text | | | Prime exclusion pattern. Repeat the flag for multiple patterns. | | | `--prime-rules-file` | path | | | Prime rules file path. | | | `--prime-analysis-config-file` | path | | | Prime analysis config file path. | | | `--prime-debug` | boolean | | false | Enable prime debug mode. | | | `--memopt-compress-program` | boolean | | false | Enable prime memory optimization | | | `--gable-data-encryption-key` | text | | | Encryption key for Gable data. | | ## Example ```bash theme={null} gable lineage scan --project-root ./path/to/project --language java --build-command "mvn clean install" --java-version 17 ``` # gable lineage upload Source: https://docs.gable.ai/docs/cli/lineage/upload Upload lineage data to Gable. ## Usage ```bash theme={null} gable lineage upload [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ----------------- | ---- | -------- | ------- | ---------------------------------------------------------------------------------------------------------- | | `--project-root` | path | ✓ | | The root directory of the project that will be analyzed. | | `--results-file` | path | ✓ | | The path to the results file. | | `--override-file` | path | | | Optional LineageDataFile JSON used to replace/add selected payload paths in the result file before upload. | | `--namespace` | text | ✓ | | INTERNAL: select the namespace you want lineage results to be associated with. | ## Example ```bash theme={null} gable lineage upload --project-root ./path/to/project ``` # gable ping Source: https://docs.gable.ai/docs/cli/ping Pings the Gable API to check for connectivity ## Usage ```bash theme={null} gable ping [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------ | ---- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | # gable ui Source: https://docs.gable.ai/docs/cli/ui Opens the Gable UI in a web browser ## Usage ```bash theme={null} gable ui [OPTIONS] ``` ## Options | Option | Type | Required | Default | Description | | ------------ | ---- | -------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--endpoint` | text | | | Customer API endpoint for Gable, in the format [https://api.company.gable.ai/](https://api.company.gable.ai/). Can also be set with the GABLE\_API\_ENDPOINT environment variable. | | `--api-key` | text | | | API Key for Gable. Can also be set with the GABLE\_API\_KEY environment variable. | # Approvals Source: https://docs.gable.ai/docs/impact/approvals Approve a component's lineage version to establish a trusted, published baseline Approvals let a reviewer sign off on a component's **lineage version** — the result of a single analysis run — establishing it as the trusted baseline for that component. Approving a version makes it eligible for export, and Gable tracks any changes made afterward so reviewers can see at a glance whether the current lineage still matches what was signed off. ## Approve a version Approvals are managed from the header of the **Component Details** page, for the version currently selected in the version selector. 1. Open **Component Details** for the component and select the version you want to review. 2. Select **Review changes** to step through what changed in this version. Once you've reviewed, the control advances to the approve step. 3. Select **Approve version**. 4. In the **Approve lineage version for publish** dialog, optionally add an **approval note** summarizing what you reviewed and why you're approving, then confirm. The review and approve control on the Component Details header The Approve lineage version dialog Approving records who approved the version, when, and any note, and marks the version as eligible for export. ## Approval states A version's approval state is shown on the Component Details header, in the version selector, and on the Lineage quality tab: * **Approved** — the version has been reviewed and approved. It is eligible for export. * **Changes since approval** — the version was approved, but the lineage has changed since (for example, a new override). The version may need to be re-approved. * **Unapproved** — the version has not been approved. The version selector shows an approval badge next to each version, so you can tell at a glance which versions are approved. Approval badges in the version selector ## Re-approving after changes Because an approval applies to a specific version, edits made after approval — such as adding an override — create pending changes that must be reviewed again. When a version shows **Changes since approval**, use **Re-approve version** to review the new changes and sign off again. Approving establishes the baseline that exported lineage is drawn from. To understand exactly what changed between two versions before approving, see [Reviewing Version Changes](/docs/impact/version-changes). # Merge / Impact Reports Source: https://docs.gable.ai/docs/impact/merge-impact-reports Per-merge reports showing what changed and which upstream and downstream dependencies are affected **Coming soon.** Merge / impact reports are under active development and not yet generally available. Contact your Gable representative to learn more. Merge reports summarize the lineage impact of a code change at merge time: what changed in the component's data behavior, which upstream inputs are involved, and which downstream consumers are affected. Integrated into CI/CD, they give reviewers the information needed to make a confident safe-to-release call before a change is deployed. # Reviewing Version Changes Source: https://docs.gable.ai/docs/impact/version-changes See what changed in a component's lineage version compared to the previous one, before you approve Every time Gable analyzes a component it records a new **version**. The **Changes this version** tab on the Component Details page shows what changed in the selected version compared to the previous one — which fields and paths were added, modified, or removed, and how significant those changes are — so you can review the impact before approving. ## Open the Changes this version tab On a component's **Component Details** page, select the **Changes this version** tab. The badge on the tab shows how many changes are in the selected version. The Changes this version tab showing the version comparison, severity summary, and payload changes ## Versions being compared The tab compares the selected version against the previous **merge-to-main** version. If the component has no earlier merge-to-main version, it compares against the immediately-preceding version instead and shows a note saying so. The **Comparing versions** header shows both sides of the comparison — the **base** version on the left and the **compare** (selected) version on the right — each with its short version ID and scan time. ## What changed The **What changed** summary classifies the changes by how much they affect downstream consumers: * **Breaking** — a change that can break downstream consumers, such as a removed or restructured output field. * **Behavior change** — a change to how a field is produced that isn't strictly breaking. * **Safe addition** — new lineage that doesn't affect existing consumers. ## Payload changes Below the summary, **Payload changes** lists each payload that changed, marked **Added**, **Modified**, or **Removed**, with a count of added and removed fields and any change to its code steps. Expand a payload to see the field-level diff. Each row shows the **Source Field**, the **Target Field**, and a **Status** of **Added**, **Modified**, **Removed**, or **Unchanged**, so you can see exactly which field mappings changed. Changes accumulate against the last approved version. Once you've reviewed them here, approve the version to publish it — see [Approvals](/docs/impact/approvals). Versions can also be compared from the command line with [`gable lineage compare`](/docs/cli/lineage/compare). # Coverage & Completeness Source: https://docs.gable.ai/docs/onboarding/coverage-and-completeness Where lineage gaps come from, how to close them, and how Gable monitors coverage Lineage derived from static code analysis is an approximation of your system's real behavior. Rather than presenting a partial graph as if it were complete, Gable makes gaps explicit — so you always know which parts of the graph you can rely on and which parts still need attention. ## Where gaps come from When lineage is missing or incomplete, the cause is usually one of the following: * **A service hasn't been scanned yet**, or is written in a language Gable doesn't analyze yet. Static code analysis currently supports Java and TypeScript services. * **A detection pattern is missing.** Gable's analysis looks for declared patterns of data entering and leaving a service. If a service uses an access pattern or abstraction the analysis hasn't been configured to recognize, the corresponding lineage won't be detected. See [Understanding the Source of Lineage Issues](/docs/troubleshooting/lineage-issues). * **A data store isn't represented.** Tables, streams, and files that aren't created automatically need to be added as data store components — see [Services & Data Components](/docs/onboarding/services-and-data-components). * **A cross-service connection hasn't been made.** In-service lineage only chains into end-to-end lineage when cross-service edges connect the components — see [Dependencies (Cross-Service Edges)](/docs/onboarding/dependencies). ## Closing gaps To improve coverage: 1. **Add missing components.** Register data stores that participate in lineage but weren't discovered automatically. 2. **Connect the graph.** Create cross-service edges between components so field lineage flows end to end. 3. **Override incorrect or missing paths.** When scanned lineage within a service is incomplete or wrong, suppress the incorrect path and create a path override — see [Field Mappings & Overrides](/docs/onboarding/field-mappings-and-overrides). 4. **Report detection gaps.** If behavior didn't change but lineage did — or lineage is missing for a pattern that should be detected — report a defect so Gable's detection can be improved. These are typically one-time fixes tied to a specific access pattern. ## Measuring coverage Gable actively monitors for coverage regressions by comparing scanned output against a verified sample of known-correct field mappings. If you are interested in learning more about how coverage is measured for your services, reach out to Gable. # Dependencies (Cross-Service Edges) Source: https://docs.gable.ai/docs/onboarding/dependencies Create and manage cross-service edges that connect lineage between services and data stores Use Gable's Lineage Explorer to create cross-service edges between components. Cross-service edges represent lineage that flows between two components, such as from a service to a data store, from a data store to a service, or from one service to another. ## Before you begin Before creating a cross-service edge, make sure the components you want to connect already exist in Gable. You need: * A scanned code component or service * Any data store components and schemas that should participate in the edge * The upstream component and downstream component for the lineage flow * The fields that should be mapped between them Before adding cross-service edges, ensure all components exist in Lineage Explorer and make any desired path overrides. For more information, see: * [Services & Data Components](/docs/onboarding/services-and-data-components) * [Field Mappings & Overrides](/docs/onboarding/field-mappings-and-overrides) ## Identify the components to connect 1. Open Lineage Explorer. 2. Search for the first component you want to connect. 3. Confirm whether the component is a data store or a code component. 4. Search for the second component you want to connect. 5. Confirm the expected direction of lineage between the two components. Before creating the edge, make sure you know which component is upstream (where data originates) and which component is downstream (where data flows to). ## Identify the fields to map Before creating the edge, identify the fields that should be mapped between the upstream and downstream components. For data store components, fields come from the data store schema. For code components, fields come from the service's payloads. In the edge modal, you can filter each side by **field, payload, or friendly name** to find the right fields. If multiple fields have the same or similar names, confirm that you are selecting the field from the correct component and payload. ## Add a cross-service edge 1. Go to **Lineage Explorer**. 2. Select **Add Edge** in the top right. The Add Edge button in the Lineage Explorer header 3. In the **Create Cross-Service Edge** modal, select the **Upstream Service** and the **Downstream Service** (either can also be a data store component). The two must be different components. 4. Use the filter on each side to narrow the field list by field, payload, or friendly name. 5. Map fields between the two sides: * Select a field on one side, then select the matching field on the other side. The pair is added to the **Mapped** list. * Repeat for each field relationship the edge should carry, or use [Auto-Map](#auto-map-field-mappings) to map fields automatically. 6. Review the mapped pairs, then select **Save**. Gable automatically determines the underlying connection points on each component when the edge is saved. The new cross-service edge should now be visible in Lineage Explorer. The Create Cross-Service Edge modal with mapped field pairs ## Auto-Map field mappings When the upstream and downstream fields have similar names, Gable can compute the field mappings for you: * **Auto-Map Missing** — automatically maps any detected field relationships that do not yet exist. Existing mappings are left untouched. * **Auto-Map All** — replaces *all* existing mappings between the two components with a fully auto-mapped set. **Auto-Map All is a destructive action.** If you have existing cross-service edge configuration between the two components — including manually curated field mappings — Auto-Map All replaces it entirely with the auto-computed set. Use **Auto-Map Missing** to add new mappings without affecting existing ones. Auto-mapping matches fields based on field names using fuzzy matching. After it runs, review the suggested mappings carefully and confirm that each upstream field maps to the correct downstream field before saving. ## Editing edges Use the **Edge Details** panel to review, update, or delete an existing cross-service edge. 1. Open Lineage Explorer. 2. Select an edge in the graph view. 3. Review the **Edge Details** panel that opens on the right side of the page. The Edge Details panel shows the number of edge mappings between the two components, along with the details for each mapping. You can search the panel by field name. From the Edge Details panel, you can: * add additional field mappings with **Add Edge For This Pair** * modify the edge configuration with **Modify** * update existing field mappings * delete the edge with **Delete** When you delete an edge, it is permanently removed from the Lineage Explorer view. To restore it later, you will need to create the edge again. The Edge Details panel ## Troubleshooting After creating the edge, confirm that it appears as expected. If the edge does not appear as expected, check that: * the correct upstream and downstream components were selected * the lineage direction is correct * the expected data store schema exists * field mappings were created and saved * duplicate field names were mapped to the intended fields ## Example workflow A typical workflow looks like this: 1. Find the two components in Lineage Explorer. 2. Determine which component is upstream and which is downstream. 3. Select **Add Edge**. 4. Select the upstream and downstream components. 5. Filter each side by field, payload, or friendly name to find the fields to connect. 6. Map fields manually or with **Auto-Map Missing**. 7. Review the mapped pairs and save the edge. 8. Validate that the edge appears in Lineage Explorer and supports the expected field lineage. Cross-service edges can also be managed programmatically — see the [`gable lineage edge`](/docs/cli/lineage/edge) CLI commands. # Field Mappings & Overrides Source: https://docs.gable.ai/docs/onboarding/field-mappings-and-overrides Review a service's field mappings and their provenance, and correct scanned lineage with overrides A **field mapping** connects an input field to an output field within a service — how a value that enters the service becomes a value that leaves it. Gable detects these mappings from your code, and you can review them, see where each came from, and correct them with overrides when the scanned lineage is incomplete or wrong. ## Where field mappings appear Open a component's **Component Details** page and go to the **Known dependencies** section. Each row is a field mapping — the ingress field on the left, the egress field it becomes on the right — grouped by ingress and egress. The Known dependencies table with its metadata columns The **Source** column shows where each mapping came from: * **Scan output** — the mapping was detected by Gable's analysis of your code. * **Override** — the mapping was added or edited by a person. * **Disabled** — a scanned mapping that has been suppressed and no longer contributes to lineage. Select a mapping to open its details panel. For the full set of metadata on a mapping, see [Field-Level Lineage Metadata](/docs/tracing/field-level-lineage-metadata). ## Inspect and act on a mapping Selecting a field mapping opens a panel with its ingress and egress payloads, its connections, its code paths, and the actions for correcting it. Use the arrows in the panel header to page through mappings without closing it. The field mapping details panel with its header actions, connections, and code paths From this panel you can: * **Add a mapping that the scan missed** — use **Add upstream source** or **Add downstream consumer** in the **Connections** card to record a mapping that the scan didn't capture. These are retained as manually managed overrides. * **Add context** — use **Notes & overrides** to leave a note for downstream consumers and stewards. * **Report a defect** — flag a scanned mapping that looks wrong (see below). * **Suppress a scanned mapping** — disable a mapping that doesn't represent real lineage (see below). ### Report a defect Report a defect when a scanned mapping appears incorrect, incomplete, or unexpected — for example, the ingress or egress field is wrong, expected mappings are missing, or the mapping represents lineage that does not exist. 1. Select the field mapping to open its details panel. 2. Select **Report an issue** in the panel header. 3. In the **Report defect** dialog, describe the issue, describe what you expected instead, and choose a **Severity**. 4. Select **Submit**. The Report defect dialog Gable receives the report along with the component version and mapping information. ### Suppress a scanned mapping When a scanned mapping doesn't represent real lineage, disable it so it no longer contributes downstream. 1. Select the field mapping to open its details panel. 2. Select **Disable** in the panel header. The mapping's **Source** changes to **Disabled**, and it stays suppressed on subsequent scans until you restore it. When a mapping can't be disabled, the control reads **Disable unavailable**. ## Refine lineage on the Lineage quality tab The **Lineage quality** tab collects the manual work on a component in one place. It summarizes the count of **scan-inferred mappings**, **manual overrides**, and **disabled paths**, and lets you filter to just the overrides or disabled paths to review them. The Lineage quality tab summarizing scan-inferred mappings, manual overrides, and disabled paths ### Create a path override When the scan missed a relationship entirely, create a new path to record it. 1. On the **Lineage quality** tab, select **Create path**. 2. Define the **Ingress** payload — a payload name and its fields. 3. Define the **Egress** payload — a payload name and its fields. 4. Under **Field mappings**, pair each ingress field with the egress field it becomes. 5. Optionally attach the **Code steps** that move the data and add **Notes**. 6. Select **Create path**. The Create path dialog The new path appears with a **Source** of **Override**. Overrides are retained as manually managed lineage: future scans may add new scanned mappings but do not remove your overrides, and disabled mappings stay suppressed until you restore them. Edits create pending changes for the version. They must be approved before they take effect downstream — see [Approvals](/docs/impact/approvals). Paths can also be managed programmatically — see the [`gable lineage component path`](/docs/cli/lineage/component/path) CLI commands. # Services & Data Components Source: https://docs.gable.ai/docs/onboarding/services-and-data-components How services and data stores are represented in Gable, and how to add, edit, and delete data store components Gable represents your systems as two kinds of components: * **Code components (services)** — created automatically when Gable scans a service's source code. A code component contains the service's ingresses (data entry points), egresses (data exit points), and the paths and field mappings that connect them. * **Data store components** — user-authored components that represent materialized data assets, such as database tables, Kafka streams, files, or other persisted stores that participate in lineage. They can be added to Gable when the asset is not created automatically through static code analysis but still needs to be represented in the lineage graph. This page covers managing data store components. It does not cover creating cross-service edges or managing in-service paths and overrides — see [Dependencies (Cross-Service Edges)](/docs/onboarding/dependencies) and [Field Mappings & Overrides](/docs/onboarding/field-mappings-and-overrides). ## Add a data store 1. Open **Lineage Explorer**. 2. Select **Add Datastore Component**. 3. In the modal, enter the data store details. 4. Add the table, schema, or field information required for the data store. 5. Additional freeform metadata can be added via the optional metadata section. 6. Click **Save**. The Add Datastore Component modal in Lineage Explorer Data store components can also be created and updated programmatically — see the [`gable lineage datastore`](/docs/cli/lineage/datastore) CLI commands. ## Edit a data store 1. Select the data store component you want to update. 2. Select **Edit Component**. 3. Update the data store details. 4. Click **Save Changes**. After saving, the updated data store information is visible in Lineage Explorer. ## Delete a data store Delete a data store when it should no longer be represented in Lineage Explorer. 1. Open **Lineage Explorer**. 2. Select the data store component you want to remove. 3. Select **Delete**. 4. Confirm the deletion. After deletion, the data store component is no longer visible in Lineage Explorer. Before deleting a data store, confirm that the component is no longer needed. There will be a warning if the data store has any connected edges. If a data store with connected edges is deleted, those edges will continue to exist but the connection will be broken. *** ## Publishing data store schemas automatically Data store schema components can also be published automatically from schema files in your repository — for example, whenever `.avsc` or `.proto` files change. See the [auto-publish guide](/docs/resources/auto-publish-datastore-schemas). # CLI Changelog Source: https://docs.gable.ai/docs/releases/cli_changelog CLI updates # Product Changelog Source: https://docs.gable.ai/docs/releases/product_changelog Product updates and announcements * **Lineage explorer** — graphs now open already laid out instead of briefly appearing scattered and then snapping into position, with a smoother initial zoom when opening a lineage view. * **Lineage explorer** — fixed lineage component detail pages that could get stuck loading or render graphs off-screen. Lineage graphs now hydrate and center correctly. * **Settings** — fixed an issue where revoking an invited user could fail while the UI still behaved like the action succeeded. * **Compare versions** — improved layout so diff tables display more cleanly on smaller screens and lower-resolution laptops. * **Datastore components** — fixed a bug where renaming or editing datastore components with type "Other" would fail with a 400 error. The "Other" option now appears at the end of the datastore type dropdown. * Renamed the "Code Component Lineage History" page to "Scan Log" for improved clarity. * **Lineage explorer** — fixed an issue where loop (bidirectional) edges between services could disappear in field-level/filtered views; they now stay visible. * Improved auto-mapping logic on the edge creation modal. * **Documentation has moved** — Product documentation is now hosted at [docs.gable.ai](https://docs.gable.ai). In-app documentation links now point to the new site. * Enable sorting by commit and scan timestamp on the history table. # Guide: Auto-publish Data Store Schemas from Avro and Protobuf Source: https://docs.gable.ai/docs/resources/auto-publish-datastore-schemas Automatically publish data store schema components whenever schema files change in your repository Use this guide to automatically publish data store schema components from `.avsc` and `.proto` files whenever changes are pushed to your repository. This workflow scans for schema files, extracts and combines their fields using the `recap-core` library, and publishes to Gable's API as a `DATA_STORE` component. For managing data store components in the UI, see [Services & Data Components](/docs/onboarding/services-and-data-components). ## 1. Set up your repo This guide assumes the following repo structure. Add your schema files, publishing script, and GitHub Action using this layout (or adapt the guide to fit your repo structure if different). ``` your-repo/ ├── schemas/ │ ├── avro/*.avsc │ └── proto/*.proto ├── scripts/publish_schemas.py └── .github/workflows/publish-schemas.yml ``` Install the required Python dependencies: ``` requests # Avro's dependencies are part of the base recap-core package recap-core[proto] ``` ## 2. Add the scan + publish script Create `scripts/publish_schemas.py`. The script: 1. Starts a run to track the relevant `git` info 2. Finds all `.avsc` and `.proto` files under `schemas/`. 3. Converts each file to Recap schema format. 4. Combines their fields into a single schema. 5. Publishes the `DATA_STORE` component to Gable's ingestion API. ```python theme={null} import os import pathlib import requests from recap.converters.avro import AvroConverter from recap.converters.protobuf import ProtobufConverter from recap.types import to_dict GABLE_API_ENDPOINT = os.environ["GABLE_API_ENDPOINT"] GABLE_API_KEY = os.environ["GABLE_API_KEY"] COMPONENT_ID = os.environ["COMPONENT_ID"] TABLE_ID = os.environ["TABLE_ID"] TABLE_NAME = os.environ["TABLE_NAME"] ROOT = pathlib.Path(os.environ.get("SCHEMA_ROOT", "schemas")) def extract_fields(path: pathlib.Path): ''' Uses Gable's recap-core library to parse Avro and Proto files and return their fields ''' text = path.read_text() if path.suffix == ".avsc": recap_type = AvroConverter().to_recap(text) elif path.suffix == ".proto": recap_type = ProtobufConverter().to_recap(text) else: return [] return to_dict(recap_type)["fields"] def start_run(): start_run_request = { "action": "upload", "type": "DATA_STORE", "collection_mechanism": "BYOL", "code_info": { "namespace": "qa", "repo_uri": f"{os.environ['GITHUB_SERVER_URL']}/{os.environ['GITHUB_REPOSITORY']}", "repo_branch": os.environ["GITHUB_REF_NAME"], "repo_commit": os.environ["GITHUB_SHA"], "project_root": "/", "repo_name": os.environ["GITHUB_REPOSITORY"].split("/")[-1], "job_trigger": "MANUAL", "external_component_id": COMPONENT_ID, }, } r = requests.post( f"{GABLE_API_ENDPOINT}/v0/sca/start-run", json=start_run_request, headers={"x-api-key": GABLE_API_KEY}, timeout=30, ) r.raise_for_status() return r.json()["runId"] def publish(payload): r = requests.post( f"{GABLE_API_ENDPOINT}/v0/sca/results", json=payload, headers={"x-api-key": GABLE_API_KEY}, timeout=30, ) r.raise_for_status() def main(): run_id = start_run() fields = [] # Parse each file using recap and combine their schemas for path in sorted(ROOT.rglob("*")): if path.suffix not in (".avsc", ".proto"): continue fields.extend(extract_fields(path)) print(f"collected {path}") # Construct the component's payload payload = { "external_component_id": COMPONENT_ID, "type": "DATA_STORE", "run_id": run_id, "external_table_id": TABLE_ID, "table_metadata": { "type": "dynamodb", "table_name": TABLE_NAME, }, "schema": {"fields": fields}, } publish(payload) if __name__ == "__main__": main() ``` ## 3. Configure the API payload The API expects one POST per schema with this shape: ```json theme={null} { "external_component_id": "DA32FCF6-C49D-4329-9033-EC298480930D", "run_id": "7C5CB5DB-B436-4E42-83BB-84512BA56369", "type": "DATA_STORE", "external_table_id": "7A253847-CF7B-470E-8EB4-CAE6DFD2F70B", "table_metadata": { "type": "dynamodb", "table_name": "dynamo table" }, "schema": { "fields": [ { "name": "field_1", "type": "string" } ] } } ``` * `external_component_id` is the UUID that the data store component will be stored under in Gable. It can be any stable UUID that uniquely identifies the data store component. * `run_id` identifies the run associated with the lineage version. * `external_table_id` identifies the specific schema or table. ## 4. Add the GitHub Action Create `.github/workflows/publish-schemas.yml`: ```yaml theme={null} name: Publish schemas on: push: branches: [main] # The path filter prevents this workflow from running # if the schema files haven't changed! paths: - "schemas/**/*.avsc" - "schemas/**/*.proto" workflow_dispatch: jobs: publish: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-python@v5 with: python-version: "3.11" - run: pip install -r requirements.txt - run: python scripts/publish_schemas.py env: GABLE_API_ENDPOINT: ${{ vars.GABLE_API_ENDPOINT }} GABLE_API_KEY: ${{ secrets.GABLE_API_KEY }} ``` ## 5. Trigger publish of schemas To publish schemas automatically, merge changes to `.avsc` or `.proto` files into `main`. After the workflow runs, confirm that the data store schemas are visible in Gable and that the generated data store component reflects the expected fields. # Support Source: https://docs.gable.ai/docs/resources/support We would love to hear any feedback you have about any part of Gable. you can send us a message at [support@gable.ai](mailto:support@gable.ai). # API Keys and Endpoints Source: https://docs.gable.ai/docs/settings/api_keys In order to use any of Gable's programmatic interfaces, you will need to provide an API key and API endpoint. You can find both by navigating to the `/settings/apiKeys` page in the web console. Gable CLI commands are also provided for convenience. Click the copy icon to copy the value to your clipboard. Gable API Keys # Single Sign-On (SSO) Source: https://docs.gable.ai/docs/settings/sso Gable supports SAML 2.0 Single Sign-On (SSO). When SSO is enabled, users authenticate through your identity provider avoiding the need for a separate Gable username and password. A Gable account is provisioned automatically the first time a user logs in via SSO and any previously set password is disabled at that point. Username-and-password access remains available for accounts that do not use SSO such as dedicated service accounts. ## Steps to configure Single Sign-On To configure SSO, follow the below steps: ### 1. Retrieve your SAML configuration details In order to create a new SAML 2.0 application in your identity provider, you'll need two pieces of information that are specific to your Gable account: * **Single Sign-On URL (ACS URL)**: Also known as the Assertion Consumer Service (ACS) URL or SP sign-in URL. This URL tells your identity provider where it should send SAML Response after authenticating a user. * **Audience URI (SP Entity ID)**: Also known as the Service Provider (SP) Entity ID or Issuer. This is a unique identifier for your instance of Gable. Navigate to the `Settings->SSO` page in the web console to find the values for your account. Keep the tab open or copy the values for use in later steps. SAML Configuration Details ### 2. Create a new SAML application in your identity provider Follow the instructions below for your identity provider. 1. Log in to the Okta Admin portal. From the `Applications` page, click `Create App Integration`. Okta SSO App Integration Button 2. Select `SAML 2.0`. Okta SSO App Integration Button 3. Name the app `Gable` and set the logo (you can download the logo [here](../assets/GableLogo.png)). 4. Under the `SAML Settings` section, fill in the form using use the values you retrieved earlier from Gable's `Settings->SSO` page. * **Single Sign-On URL**: Use the value from Gable's `Settings->SSO` page * **Audience URI (SP Entity ID)**: Use the value from Gable's `Settings->SSO` page * **Name ID format**: set to `EmailAddress` * **Application username**: set to `Email` * **Update application username on**: leave set to `Create and update` 5. Configure the following `Attribute Statements` to ensure email addresses and names are correctly populated in Gable. * **`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`**: `user.email` * **`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname`**: `user.firstName` * **`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname`**: `user.lastName` You can leave the Name Format as `Unspecified` for each. Okta Saml Attributes 6. Continue through the `Feedback` prompt to complete creating the app! Once the app is created, navigate to the `Sign On` tab and copy the `Metadata URL` - you'll need this in the next step to configure SSO in Gable. 1. Log in to the Google Admin dashboard, select `Apps` from the sidebar menu, and then select `Web and Mobile Apps` from the following list. Next, select `Add app->Add custom SAML app` from the dropdown menu. Okta SSO App Integration Button 2. Name the app `Gable` and set the logo (you can download the logo [here](../assets/sso/GableLogo_google.png)). 3. Download the Idp metadata, you'll need this XML file to configure SSO in Gable. You'll have the option to re-download the file once th application is created, so don't worry if you missed this step. 4. Fill out the `Service provider details` form using the values you retrieved earlier from Gable's `Settings->SSO` page. * **ACS URL**: Use the `Single Sign-On URL (ACS URL)` value from Gable's `Settings->SSO` page * **Entity ID**: Use the `Audience URI (SP Entity ID)` value from Gable's `Settings->SSO` page * **Name ID format**: set to `EMAIL` * **Name ID**: set to `Basic Information > Primary email` 5. Configure the following `Attribute Statements` to ensure email addresses, and names are correctly populated in Gable. * **Primary email**: `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress` * **First name**: `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname` * **Last name**: `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname` You can leave the Name Format as `Unspecified` for each. 6. You'll need to configure user access before anyone at your company can login to Gable using SSO. Depending on your company policies, you may choose to enable access for everyone, or only select groups. If your identity provider is not listed, you should be able to find their documentation for creating a SAML based application, and please reach out to [support@gable.ai](mailto:support@gable.ai) if you'd like to have your IdP added! After completing the SAML app setup, your IdP should provide you with either a metadata URL, or metadata XML file for you to download. The metadata URL or file will be used in the next step to configure SSO in Gable. ### 3. Configure SSO In Gable Using either the metadata URL or file provided by your IdP, configure the SSO integration in Gable. 1. Navigate to the `Settings->SSO` page and in the Enable SSO section, click the `Enable` button. 2. Enter name for your SSO integration - this name will be what users see when they land at Gable's sign-in portal. **Note**: The following strings cannot be used as the integration name as they're reserved words in our identity management platform: `Google`, `SAML`. Depending on your identity provider, either enter the metadata URL they provided or upload the metadata file you downloaded when creating the SAML app. 3. Once you save the SSO configuration, users will have the option to sign in through your identity provider when they land on Gable's sign-in portal. # Update Profile Source: https://docs.gable.ai/docs/settings/update_profile ## 1. Accessing Your Profile Once logged in, navigate to the bottom-left corner, click the profile icon, and then select `View profile`. You can also access your profile under the `Profile` tab of Settings. ## 2. Editing Basic Information Here, you can see the current profile information and also update your first name, last name, Github handle, and email. Click the `Edit` button in the respective section to make changes. After making edits, click the `Save` button to ensure your changes are recorded. # User Management Source: https://docs.gable.ai/docs/settings/user_management ## Inviting Users You can invite new users to Gable by clicking the `+User` button on the `Settings->Users` page. Invitations are restricted to emails from your company's domain. When a new user is invited to Gable, they'll receive a welcome email titled `Your temporary Gable login information`. This email contains a temporary password that remains valid for 24 hours. Users will be prompted to change their password when they first log in. If you need to re-send an invite or reset a user's password, you can delete the user and add them again to generate a new temporary credentials email. ### SSO Integration After enabling Single Sign-On (SSO), the user login process to Gable will be integrated with your identity provider. Users won't receive a separate welcome email from Gable or need to set a standalone password. With SSO enabled, accounts are created when a user first logs in. Any user who previously set a password in Gable will have their username/password authentication method deactivated upon their first login via your identity provider. Read more about configuring SSO in our [Single Sign-On (SSO) section](../settings/sso). ## Deleting Users To delete users from Gable, click on the `Delete` button. If Single Sign-On (SSO) is enabled, any deleted users can still access Gable through your identity provider. When deleted users log in to Gable through your identity provider, their Gable account will be recreated. If you want to remove users with SSO enabled, ensure that users are either removed or their access is disabled directly within your identity provider. # Generating Compliance Evidence Source: https://docs.gable.ai/docs/tracing/compliance-evidence Use lineage to answer where regulated data comes from, what computes it, and who consumes it Compliance reviews start from a question about data, not a question about code: *where does this regulated output come from, what computed it, and which systems consume it?* Because Gable's lineage is derived from your services' actual source code — not from documentation or manually maintained diagrams — it can answer those questions with evidence that reflects how the software really behaves. This page describes the workflow for assembling that evidence. ## Trace the regulated data 1. Open the **Lineage Explorer** and search for the regulated or sensitive field — for example, an output field of a report, feed, or API response. 2. Select the field to filter the graph to its lineage. 3. Trace **upstream** to confirm every source that feeds the field: which services touch it, which data stores hold it, and where it originally enters your systems. 4. Trace **downstream** to identify every consumer that depends on it. Tracing a sensitive field upstream across services See [Tracing Data Lineage](/docs/tracing/end-to-end-lineage) for the full tracing workflow. ## Show how the data is computed For each service along the path, open **Component Details** to show what happens to the data inside the service: * the path connecting the relevant ingress and egress * the field mappings along that path * the field data flow — the steps the value takes through the code This answers "what computed this value?" at the level of specific services and fields, backed by the analyzed code version. ## Export the evidence Capture the trace as an artifact for the review: * **CSV export** — with the field selected in the Lineage Explorer, use **Export CSV** to download the upstream lineage paths for the field, hop by hop. See [Exporting Lineage](/docs/tracing/exporting-lineage). * **API export** — for the complete lineage of a run (components, schemas, and edges), use the [Lineage Export API](/docs/tracing/exporting-lineage#export-lineage-via-the-api). ## Anchor the evidence to a point in time Every version of a component's lineage is tied to an analysis run of a specific commit: * The **Scan Log** records every analyzed version, with its branch, commit, and analysis timestamps — a durable record of when each version of the lineage was produced and from what code. * To show how data handling changed between two audits or releases, compare the corresponding versions — see [Comparing Lineage Versions](/docs/impact/comparing-lineage-versions). The Scan Log as a point-in-time record of analyzed versions ## Coming soon Two upcoming capabilities will streamline this workflow: * [Sensitive Data](/docs/tracing/sensitive-data-classification) — start from a classification (such as PII) instead of a known field name, and track classified data across the graph. * [Approvals](/docs/impact/approvals) — sign off on a lineage version to establish the reviewed baseline your evidence is generated from. # Data Tagging Source: https://docs.gable.ai/docs/tracing/data-tagging How Gable tags sensitive fields, and how to review and manage tags on your data Data tags label the fields in your lineage with their sensitivity or meaning — for example, marking a field as containing personal information. Gable applies some tags automatically and lets you add your own, so you can see where sensitive data lives and track it across your services. A tag attaches to a field's underlying address, so once a field is tagged it shows that tag everywhere the field appears in lineage — not just in one mapping. ## System-generated PII tags When Gable analyzes a service, it inspects each field and automatically applies a built-in **PII** tag to fields that appear to contain personal information (for example, fields that look like an email address, social security number, or credit card number). These system-generated tags require no setup — they appear on matching fields as soon as the component is scanned. System-generated tags are shown as tag chips on the field, the same as tags you add yourself. Hover a chip to see whether it was applied by Gable or by a person. PII tags on fields in the Known dependencies table ## Tag categories Gable includes a set of built-in tags you can apply: * **PII** — personal information (also applied automatically, as described above) * **PHI** — protected health information * **PIFI** — personal financial information * **Secret** — secrets and credentials Your organization can also create its own tags with a custom name, color, and description. Only the **PII** tag is applied automatically; the others are available for you to apply. ## Tag a field Tags are managed on the field's card in the **Component Details** page. 1. Open **Component Details** for the component and locate the field (on an ingress or egress payload). 2. In the field's **Tags** row, select the **Tag** button. 3. In the tag picker, search for a tag and select it to apply. To create a new tag for your organization, select **Create new tag** and fill in the tag's details. The Tag button and tag picker on a field Because a tag applies to the field wherever it appears, tagging a field once carries the tag across every mapping that field feeds. ## Remove a tag To remove a tag from a field, select the **×** on the tag chip. System-generated tags can be removed the same way if they don't apply. ## Where tags appear Once fields are tagged, tags surface across the Component Details page so you can find sensitive data quickly: * **Header summary** — a count of tagged fields for the component. * **Known dependencies** — a **Tags** column on the field-mapping table. * **Tag filter** — filter the mappings down to those carrying a specific tag. * **Lineage quality** — a **Tagged fields** metric. Tagged-field summary and metrics on the Component Details page Tagging sensitive fields makes it easier to trace regulated data and assemble evidence — see [Generating Compliance Evidence](/docs/tracing/compliance-evidence). # Tracing Data Lineage Source: https://docs.gable.ai/docs/tracing/end-to-end-lineage Follow a field across services and data stores in the Lineage Explorer Gable analyzes your services' source code to discover how data moves within each service — from the ingresses where data enters, through the transformations in code, to the egresses where it leaves. Combined with cross-service edges, those in-service paths chain together into **end-to-end lineage**: a field can be traced from where it originates, across every service and data store it passes through, to where it is finally consumed. Use the **Lineage Explorer** to navigate that graph. ## Open the Lineage Explorer The Lineage Explorer shows your components — services and data stores — connected by cross-service edges. The graph loads the component topology first, then fills in field-level details in the background. The Lineage Explorer graph of services and data stores Each service shows its ingresses and egresses; each data store shows its schema. If friendly names have been configured, they are shown alongside the underlying signature names. ## Trace a field 1. Open the field search sidebar and search for the field you want to trace. 2. Select the field from the results. You can select multiple fields to trace them together. 3. The graph filters to the selected fields, showing the field-level connections between components — which upstream fields feed the selection, and which downstream fields consume it. Field-level lineage for a selected field Follow the connections hop by hop: * an **egress** field on one service connects to an **ingress** field on another service, or to a data store column * within a service, ingress fields connect to egress fields through the service's internal paths Your field selection is reflected in the page URL, so you can share a link that reproduces the exact trace you are looking at. ## Inspect a mapping in a component To understand *how* a single service produces a field, open its **Component Details** page (select the service in the Lineage Explorer and open its details). 1. Open the **Known dependencies** section, which lists the component's field mappings — each ingress field and the egress field it becomes. 2. Select a mapping to open its details, including the code paths that produced it. 3. Review the code path steps to see where the value is read, how it is transformed, and where it is written. For the full set of metadata on each mapping — the Known dependencies columns and the code path steps — see [Field-Level Lineage Metadata](/docs/tracing/field-level-lineage-metadata). A field mapping's details with its code paths To inspect a cross-service connection, select the edge in the graph. The **Edge Details** panel shows every field mapping the edge carries. See [Dependencies (Cross-Service Edges)](/docs/onboarding/dependencies) for managing edges. ## Next steps * Export the trace for reporting or review — see [Exporting Lineage](/docs/tracing/exporting-lineage). * Understand how lineage changed between versions — see [Reviewing Version Changes](/docs/impact/version-changes). * If a trace doesn't match your expectations, see [Understanding the Source of Lineage Issues](/docs/troubleshooting/lineage-issues). # Exporting Lineage Source: https://docs.gable.ai/docs/tracing/exporting-lineage Export field lineage to CSV from the Lineage Explorer, or export full lineage data via the API Use Gable's Lineage Explorer to export lineage for one or more fields and review their upstream dependencies in CSV format. ## Before you begin Lineage export through the UI is limited to lineage for the fields you have selected or filtered to. You can export the complete lineage data for a run — components, schemas, and edges — via the [Lineage Export API](#export-lineage-via-the-api). If the **Export CSV** button is not available in your workspace, contact Gable to have lineage export enabled. ## Export lineage for a field 1. Open **Lineage Explorer**. 2. Search for the field you want to inspect. 3. Select the field from the search results. You can select multiple fields to include all of them in one export. 4. Export the lineage as a CSV file by clicking the **Export CSV** button. The Export CSV button is disabled until at least one field is selected or filtered. Exporting field lineage to CSV from Lineage Explorer ## How to read the CSV The exported CSV includes the lineage upstream of the selected fields. This means the export shows the sources, transformations, and intermediate assets that feed into the fields you selected. Each row in the CSV represents one upstream lineage path for a selected field. The file includes these columns: * **Path ID** — a unique identifier for each lineage path * **Direction** — the lineage direction included in the export, such as `upstream` * **Hop 0, Hop 1, Hop 2, ...** — each step in the lineage path, listed in order Example export: | Path ID | Direction | Hop 0 | Hop 1 | Hop 2 | | ------- | --------- | ------------------------------------------------ | ------------------------------------------------------------------ | ---------------------------------- | | 1 | upstream | CustomerService.customer.email\_address (egress) | CustomerService.profile.email\_address (ingress) | customer-db.email\_address (table) | | 2 | upstream | CustomerService.customer.email\_address (egress) | CustomerService.marketing.contact\_email (ingress) | customer-db.contact\_email (table) | | 3 | upstream | CustomerService.customer.email\_address (egress) | CustomerService.email\_standardization.normalized\_email (ingress) | customer-feed.email\_raw (table) | Read each row from left to right. * **Hop 0** is the field you selected in Lineage Explorer * **Hop 1** is the asset directly upstream of that field * **Hop 2** and later hops show additional upstream dependencies Blank hop columns indicate that the lineage path ends at that point. Because a field can have more than one upstream source or branch, the export may contain multiple rows. ## Understanding lineage paths A lineage path shows how data flows from an upstream source to the selected field. For example, one row might show: * the selected field in **Hop 0** * a directly connected upstream field in **Hop 1** * an intermediate mapped or transformed field in **Hop 2** * a source table field in a later hop Another row may show a different upstream branch for the same selected field. Reviewing all rows together helps you understand the full upstream lineage. ## Understanding asset names Each hop contains the name of an asset in the lineage path. In many cases, the value includes both the asset name and its type in parentheses. These labels help identify the role each asset plays in the lineage path. Examples of asset types include: * **(table)** — a table-based asset * **(ingress)** — an incoming interface or input field for a service or other code component * **(egress)** — an outgoing interface or output field for a service or other code component ## Export lineage via the API To export all lineage data for a run rather than selected fields, use the Lineage Export API: ```bash theme={null} curl -H "x-api-key: $GABLE_API_KEY" \ "$GABLE_API_ENDPOINT/v0/lineage/export?run_id=" ``` The response is a JSON document containing the code components, data store components, and edge mappings associated with the run. The same export is available from the command line with [`gable lineage export`](/docs/cli/lineage/export). # Field-Level Lineage Metadata Source: https://docs.gable.ai/docs/tracing/field-level-lineage-metadata Read the metadata Gable captures for each field mapping, from the Known dependencies table down to the code path steps For each field mapping in a component — how an input field becomes an output field — Gable captures metadata describing how the mapping was derived, what happens to the value, and where it flows. This metadata appears in the **Known dependencies** section of the Component Details page, and expands into a step-by-step view of the code path. ## The Known dependencies table The **Known dependencies** section lists each field mapping as a row — the **Ingress field** that enters the service on the left, the **Egress field** it becomes on the right — along with the following metadata columns: * **Kind** — how the input participates in producing the output: **Data flow** (the value itself flows through), **Key-value bridge** (connected through a shared key), or **Control flow** (the value influences what is written without becoming it). * **Computation** — what the code does to the value along the way: **Pass-through** (the value is carried unchanged), **Calculation** (the value is computed or transformed), or **Redaction** (the value is masked or removed). * **Sources** — the number of upstream sources that feed the input field. * **Consumers** — the number of downstream consumers of the output field. * **Source** — where the mapping came from: **Scan output** (detected by Gable's analysis), **Override** (added or edited by a person), or **Disabled** (a scanned mapping that has been suppressed). * **Tags** — the sensitivity or data tags on the fields, such as PII. See [Data Tagging](/docs/tracing/data-tagging). * **Status** — when you are comparing two versions, whether the mapping was **added**, **changed**, or **removed**. See [Reviewing Version Changes](/docs/impact/version-changes). The Known dependencies table with its metadata columns Note the difference between **Sources** (the *count* of upstream sources) and **Source** (the provenance of the mapping — scan output, override, or disabled). ## Inspect a mapping Select a row to open its details panel. The panel shows the ingress and egress fields, their connections (upstream sources and downstream consumers), any tags and notes, and the **Code paths** that produced the mapping. The field mapping details panel ## Code path steps The **Code paths** card shows how the value actually travels through the code, as one or more paths. Each path is an ordered list of numbered **steps**, and each step describes a single operation. Every step includes: * **A classification** of the operation — for example **read**, **write**, **call**, **return**, **assign**, or **flow** — so you can see what the code is doing at that point. * **A location** — the file and line where the operation occurs. * **A human-readable summary** — a plain-language description of the transformation happening at that step, when one is available. * **An inline code snippet** — expand a step to view the relevant source inline. * **A link to GitHub** — open the exact line in your repository (labeled with the line number, e.g. `L42`). Code path steps with classifications, an inline source snippet, and GitHub links Reading the steps in order shows the full journey of the value: where it is read, how it is transformed, and where it is written. To follow a field beyond a single component — across services, end to end — see [Tracing Data Lineage](/docs/tracing/end-to-end-lineage). # Understanding the Source of Lineage Issues Source: https://docs.gable.ai/docs/troubleshooting/lineage-issues How Gable's lineage responds to code changes, and how to tell a real change from a detection gap ## What you're looking at Gable shows how data moves through your service, from where it enters, through the transformations in your code, to what gets written or returned. This is not a trace of your code line-by-line. It's a representation of **data behavior**: * what inputs are used * how they are transformed * what outputs are produced If those relationships stay the same, the lineage should stay the same — even if the code around it changes. ## What should (and shouldn't) change Most code changes **do not change data lineage**. Things like refactoring or renaming intermediary functions, moving logic into helpers, or reorganizing files usually leave lineage unchanged. If your change didn't alter what data is used or produced, you should expect the lineage to look the same. If lineage *does* change in those cases, that's a signal worth checking. On the other hand, lineage *should* change when you: * add or remove input fields * change how fields are computed * modify the structure of the output * introduce new writes, responses, or external calls (e.g. ingress / egress points) ## Where issues usually come from When lineage looks wrong, it's rarely about internal transformation logic. Most issues show up at the **edges of the system**, where data enters or leaves: * how requests, events, or DB reads are handled (ingress) * how data is written, returned, or emitted (egress) * how data is passed across service or library boundaries Changes in these areas can make lineage: * disappear (missing paths) * partially degrade (missing fields) * or look disconnected These parts of the system rely more on recognizable patterns and guided detection, rather than purely inferred data flow, which makes them more sensitive to structural changes in how the code is written. ## What to do if something looks off If lineage doesn't match your expectations: 1. **Sanity check the change.** Did you modify inputs, outputs, or data structures? 2. **Look at boundaries.** Did anything change in how data enters or leaves the service? 3. **Determine if it's signal or scanner defect.** * If behavior changed → lineage should change * If behavior didn't change → this may be a scanner detection gap In cases where detection needs help, Gable can be updated to better recognize the pattern. These are typically one-time fixes tied to a specific access pattern or abstraction. To report a detection issue, select the affected path in the **Paths** table on the Component Details page and choose **Report defect** from the Actions menu. Gable receives the report along with the component version and path information. See [Field Mappings & Overrides](/docs/onboarding/field-mappings-and-overrides#reporting-a-defect) for details. While a detection gap is being addressed, you can keep your lineage accurate by suppressing the incorrect path and creating a path override — see [Field Mappings & Overrides](/docs/onboarding/field-mappings-and-overrides). # Introduction Source: https://docs.gable.ai/intro What Gable does and how to use it. Gable reads your code and maps how your data actually moves through your services, down to the level of individual fields. With that map you can trace where any piece of data comes from and where it goes, produce evidence for audits, and see what a change will affect before you ship it. Most teams can see their infrastructure, deployments, and databases, but not how their software actually produces and moves the data the business runs on, or what happens to that data when the code changes. Gable answers those questions. For any output field, it shows the upstream sources it came from, how it was computed, and every downstream service that depends on it. ## What Gable shows you With Gable you can: * Understand where data enters a service, how it is transformed, and where it leaves. * Follow any field across your services, from where it originates to everywhere it ends up. * See which services and people depend on a given piece of data. * Trace how sensitive and regulated data flows across your services. ## What you can do with Gable Follow any field across your services to see where it comes from and everywhere it is used. Show where regulated and sensitive data originates and flows, ready for audits and exams. Compare versions to see what a change alters and which downstream dependencies it affects, before you release. Approve a lineage version as a trusted baseline and track what has changed since it was approved. ## Who it's for Gable is built for teams that need decisions backed by evidence drawn directly from the code, not from manually maintained spreadsheets or undocumented team knowledge. * **Compliance & governance.** Prove where regulated and sensitive data originates and where it flows, and answer audit and exam questions from evidence traced out of your code instead of assembling provenance by hand. See [Tracing Data Flow & Compliance Evidence](/docs/tracing/end-to-end-lineage). * **Change management & release decisions.** Before a change ships, see its real impact: what changed, which downstream dependencies are affected, and whether sensitive data is involved, so the go/no-go call is backed by evidence rather than a self-attested checklist. See [Data Change Impact & Safe Releases](/docs/impact/version-changes). It's also useful day to day for **developers** tracing an output back to the code that produced it and checking what a change affects, and for **reviewers** making a confident ship / no-ship call. ## Start here New to Gable? Start by connecting your services and data stores, then explore the map in the Lineage Explorer. For programmatic access, see the [CLI Reference](/docs/cli/introduction) and the [API Specifications](/api-reference/introduction).