> ## Documentation Index > Fetch the complete documentation index at: https://docs.synq.io/llms.txt > Use this file to discover all available pages before exploring further. # PreviewRule > Report what a candidate rule would change, without saving it. The candidate is slotted into the workspace's live rule set — replacing an existing rule when `id` names one — and the whole resolution is run over every check, so scope, priority, explicit categories and producer-declared categories are all honoured. The response separates the candidate's raw reach from its real effect, which are rarely the same number. Preview a rule before saving it: one that matches broadly can recategorise a large part of a workspace in a single sweep. ## OpenAPI ````yaml /api-reference/openapi.yaml post /api/entities/v2/checks/categorisation-rules/preview openapi: 3.1.0 info: version: '1.0' title: SYNQ servers: - url: https://developer.synq.io - url: https://api.us.synq.io - url: https://api.au.synq.io security: - bearerAuth: [] tags: - name: synq.deliveries.v1.DeliveriesService description: >- DeliveriesService reports what was sent to your notification integrations — webhooks, PagerDuty, Opsgenie — and what came back. It answers the three questions an integration owner has. "Did this event reach my endpoint": list the deliveries for an event id and read the outcome of each. "Why did my endpoint reject it": read the attempts, which carry the request as it was sent and the response as it came back. "Why did I get nothing at all": every delivery that sent nothing records a reason, so a silent integration can be explained rather than guessed at. Deliveries are kept for 90 days. Credential-bearing header values are never returned, on either side of an attempt — see `Header`. - name: synq.savedviews.v1.SavedViewsService description: >- SavedViewsService manages saved views — named, reusable selections over your entities (and other surfaces) with display configuration, sharing and per-user pinning. A saved view is owned by the user who created it. It can be kept private, shared with the whole workspace, or granted to specific users. Reads return, for the calling user, how each view relates to them (mine / shared / granted) and what they are allowed to do with it. Workspace administrators can manage any view in the workspace. - name: synq.issues.issues.v1.IssuesService description: IssuesService is a service for managing Issues. - name: synq.issues.v2.IssuesService description: IssuesService is a service for managing Issues. - name: synq.integrations.v1.IntegrationsService description: |- IntegrationsService manages connections from Coalesce Quality to your data systems (warehouses, databases, and transformation tools). Concurrency: every integration carries an opaque `etag`. Read it from `GetIntegration` / `ListIntegrations`, then pass it back on `UpdateIntegration` / `DeleteIntegration` to ensure you modify the version you last saw. A stale etag is rejected with ABORTED (HTTP 409). Omit the etag for last-write-wins. Quota: each workspace has a limit on the number of integrations. Creating beyond the limit is rejected with RESOURCE_EXHAUSTED. Secrets: credential fields (passwords, tokens, keys) are write-only. They are masked (returned empty) on every read. On update, omit a secret to keep it, send a new value to rotate it, or send an explicit empty string to clear it (where the field is `optional`). - name: synq.queries.v1.NLQueryService description: >- NLQueryService generates structured Query protos from natural language descriptions using an LLM. - name: synq.queries.v1.QueriesService description: |- QueriesService compiles and evaluates ResolverQL — the compact text query language used across Coalesce Quality to select entities — over the public API. ResolverQL is a string DSL (for example `with_type("TABLE")` or `in_folder(...)`); a structured `synq.queries.v1.Query` is its parsed, machine-readable form. This service is the bridge between the two and the read-only execution surface for both: - `TranslateResolverQl` compiles a ResolverQL expression into a structured `Query` without evaluating it — inspect it, validate it, or reuse it as a filter on another API (entity listing, folder browsing, ...). - `ResolveQuery` compiles a ResolverQL expression (or takes an already-structured `Query`), evaluates it against the catalog, and returns the matched entity ids. This is the general author -> resolve loop. - name: synq.monitors.predictions.v1.MonitorPredictionsService description: Access to anomaly detection model predictions and raw metric timeseries. - name: synq.monitors.info.v1.MonitorInfoService - name: synq.monitors.history.v1.HistoryService - name: synq.monitors.automated_monitors.v1.DeploymentRulesService - name: synq.monitors.custom_monitors.v1.CustomMonitorsService - name: synq.entities.executions.v2.EntityExecutionsService description: >- EntityExecutionsService provides read-only access to entity execution history. This service allows customers to retrieve information about all executions that happened on their entities, including execution status, timing, and messages. Use cases: - Retrieve execution history for specific entities - Filter executions by time range, status, or execution type - Get aggregated summaries of execution activity - Track execution trends and patterns - name: synq.entities.executions.v1.EntityExecutionsService description: 'Deprecated: Use [synq.entities.custom.v1.EntityExecutionsService] instead' - name: synq.entities.lineage.v1.LineageService description: |- LineageService allows you to fetch: * Entity level lineage from a starting point of one or more entities. * Column Level lineage from a starting point of multiple columns of a single entity. - name: synq.entities.checks.v2.ChecksCategoriesService description: |- ChecksCategoriesService reads and edits the categories of the checks in a workspace. Categorising checks is what turns a long list of tests into a picture of data quality: it lets you ask how much of a data product is covered for completeness, or which freshness checks exist across three warehouses that each name the same idea differently. Every check resolves to at most one category per dimension: * technical — what kind of check this is, mechanically ("nullness", "uniqueness", "freshness"); * governance — what the check is for, in data-quality terms ("Completeness", "Accuracy", "Timeliness"). The two are independent, and each resolves from three sources, in descending precedence: a category set explicitly on the check through this service, a category the producing tool declared, and a category one of the workspace's categorisation rules computed. Rules are managed by ChecksCategorisationRulesService and are the right tool for anything that generalises; set a category explicitly only for the checks that are genuine exceptions. The workspace and the acting identity always come from the request credentials, never from the payload. - name: synq.entities.checks.v2.ChecksCategorisationRulesService description: |- ChecksCategorisationRulesService manages the rules that categorise a workspace's checks automatically. A rule says "checks matching this predicate get this category on this dimension". Rules are the scalable way to categorise: they apply to checks that already exist and to every check ingested afterwards, so a new dbt package or a new warehouse does not mean a fresh round of manual tagging. A rule-computed category is the lowest-precedence source — a category set explicitly on a check through ChecksCategoriesService, and one the producing tool declared, both win over it. A typical loop is: ListCategorisationFilters to see what the workspace's checks look like, PreviewRule to check the reach of a candidate, UpsertRule to save it, then GetRecategorisationStatus to confirm the existing checks have caught up. Every workspace starts with a set of platform-provided rules covering the common cases. They are visible here, they can be superseded by a workspace rule of any priority, and they cannot be edited from a workspace. - name: synq.entities.checks.v1.ChecksCategoriesService description: |- ChecksCategoriesService lets workspace admins set explicit category overrides on individual checks. An explicit category is the authoritative category for a check — it takes precedence over the categories computed by the workspace's categorisation rules. It is a public API so customers can manage check categories programmatically; the same service is also mounted on the internal API. The workspace and the acting identity are always taken from the request context, never from the payload. - name: synq.entities.constraints.v1.TableConstraintsService description: >- TableConstraintsService provides access to table constraint and index information. - name: synq.entities.sql_insights.v1.SqlInsightsService description: >- SqlInsightsService exposes analytical information about the SQL used across a workspace's entities. It answers questions such as "which SQL constructs are used in my warehouse, and how often" and "what SQL constructs does this specific entity use", without requiring the caller to re-parse any SQL. - name: synq.entities.status.v1.EntityIncidentsService description: EntityIncidentsService is the service which retrieves entity status. - name: synq.entities.status.v1.EntityIssuesService description: EntityIssuesService is the service which retrieves entity issues status. - name: synq.entities.entities.v1.EntitiesService description: EntitiesService is a service for retriving any entity. - name: synq.entities.orchestration.v1.OrchestrationService description: >- OrchestrationService provides information about orchestration relationships between entities. This includes relationships between Airflow tasks and transformation models (dbt, SQLMesh), as well as task-to-task dependencies. - name: synq.entities.annotations.v1.AnnotationsService description: >- AnnotationsService provides operations for managing and querying entity annotations. Annotations are key-value pairs that can be attached to entities for categorization and filtering. - name: synq.entities.custom.v1.RelationshipsService description: >- RelationshipsService allow management of relationships between entities. Relationships can be created, updated, and deleted between 2 custom entities, or between a custom entity and Coalesce Quality native entity.enum There is no option to create relationships between 2 Coalesce Quality native entities (dbt model, BI dashboard, etc.). - name: synq.entities.custom.v1.EntityExecutionsService - name: synq.entities.custom.v1.FeaturesService - name: synq.entities.custom.v1.EntitiesService description: >- custom.EntitiesService is a service for managing custom entities. Entities can represent various data platform concepts such as services, consumers, applications or data pipelines that are not natively available in Coalesce Quality. Entities are identified by a unique identifier and can be created, updated, read and deleted. - name: synq.entities.custom.v1.GroupsService description: >- It eliminates the need to keep state on client side to remember which assets were already created and which should be deleted. The server will keep track of the current state of the group and client can always send the intended new state. The server will calculate the diff and entities that are no longer present in the group will be removed. Example: 1. group has entities A, B, C at time t1 2. client sends group with entities B, C, D at time t2 3. server will remove entity A from the system and update the current state of the group to B, C, D The service is designed to be idempotent and can be called multiple times with the same state without causing any side effects. - name: synq.entities.custom.v1.TypesService description: TypesService is a service for managing custom entity types. - name: synq.entities.custom.v1.ChecksRelationshipsService - name: synq.entities.folders.v1.FoldersService description: >- FoldersService discovers and browses the folder / containment hierarchy of the catalog: the roots data hangs from, the sub-folders under any folder, the folders a given entity lives in, and the entities contained in a folder. It is a read / navigation surface, not folder management — there are no create, move, or delete operations. Addressing: every folder has an opaque `folder_entity_id` (round-trip it verbatim) and a structured `FolderRef{root_entity_id, folders[]}` (the human-friendly form). Entities — both folder members and the ids you pass to `GetFolderOf` — are named by their opaque entity id, the same id used across the rest of the entities API. Depth footgun: membership is SHALLOW by default. `Browse` returns only the direct children of a folder, and `ListMembers` returns only the entities placed directly in the folder. Set `deep = true` (or raise `Browse.depth`) to recurse into sub-folders. - name: synq.entities.schemas.v1.SchemaMismatchesService description: >- SchemaMismatchesService provides access to schema drift information between data platform tables and their definitions (e.g., dbt models). - name: synq.entities.schemas.v1.SchemasService description: EntitiesService is a service for retriving any entity. - name: synq.entities.resolve.v1.IdentifierResolveService description: >- IdentifierResolveService resolves identifiers to their Coalesce Quality paths and identities. - name: synq.entities.changes.v1.ChangesService description: >- ChangesService provides functionality to track and retrieve all types of changes to data entities. This unified service returns ALL change types for an entity: - Git commits: Changes to code files (dbt models, SQL files) tracked in version control - Schema changes: Database schema modifications (columns added/removed/changed) - SQL definition changes: View/materialized view definition updates detected by Coalesce Quality Changes are returned with structured metadata including: - For git commits: structured statistics (directories, file types, top changes) - For schema changes: detailed column-level diffs - For SQL changes: before/after SQL definitions Use cases: - "What changed in the last week for table X?" → Returns git commits, schema changes, SQL changes - "Show me all commits affecting this dbt model" → Returns git commits with lineage context - "What schema changes happened to this table?" → Returns schema changes detected by Coalesce Quality - name: synq.entities.impact.v1.ImpactService - name: synq.entities.coordinates.v1.DatabaseCoordinatesService description: >- DatabaseCoordinatesService is a service for getting database coordinates of Entities. - name: synq.entities.code.v1.CodeService description: >- CodeService is a service for retrieving code associated with entities in the system. It provides functionality to access and manage code artifacts such as SQL queries, Python scripts, dbt models, and other code configurations that are part of Coalesce Quality entities. - name: synq.alerts.services.v1.AlertsService description: AlertsService provides operations for managing alert configurations. - name: synq.auth.iam.v1.IamService - name: synq.datachecks.testsuggestions.v1.TestSuggestionsService - name: synq.datachecks.v1.TriggerService description: TriggerService provides synchronous execution of datachecks on entities. - name: synq.datachecks.sqltests.v1.SqlTestsService description: SqlTestsService is a service for managing SqlTests. - name: synq.datachecks.sqltests.v1.SqlTestsDeploymentRulesService description: |- SqlTestsDeploymentRulesService manages SqlTestDeploymentRules — rules that dynamically deploy SQL test templates onto every table or view a query matches, resyncing over time as the match set changes. - name: synq.extensions.atlan.integrations.v1.AtlanIntegrationService - name: synq.extensions.atlan.workflows.v1.AtlanWorkflowService - name: synq.extensions.atlan.provider.v1.AtlanProviderService - name: synq.schedule.v1.ScheduleService description: ScheduleService provides schedule evaluation utilities. - name: synq.git.commits.v1.CommitsService - name: synq.dataproducts.v2.DataproductsService description: |- DataproductsService manages data products — named, owned groupings of data assets with a membership definition, a priority and an optional folder. Ids are opaque UUIDs supplied by the caller, which makes writes idempotent (a retried create converges instead of duplicating). Mutable fields are optional on Upsert: a field that is set is written, a field that is omitted is left unchanged. Pass the `etag` you last read to guard against overwriting a concurrent edit. A data product is a leaf in the reference graph — its definition may not reference another data product or domain — so membership resolution always terminates. - name: synq.dataproducts.v1.DataproductsService description: DataproductsService can be used to manage data products. - name: synq.agent.sre.v1.TriageService description: >- Service for managing issue triage operations, allowing LLM agents to conclude investigations and record evidence during the triage process. - name: synq.agent.sre.v1.LlmService description: Service for evaluating LLM requests and producing structured output. - name: synq.agent.sre.v1.FeatureRequestService description: >- FeatureRequestService allows MCP clients to submit feature requests when users encounter missing capabilities. This is a last-resort service — it should only be used when no existing tool can fulfill the user's request. - name: synq.agent.recon.v1.SuiteDeploymentService description: |- SuiteDeploymentService is the platform plane of reconciliation. SuiteConfigService is the developer/authoring sandbox (edit, version, run ad-hoc with your own credentials — preview-only, no Entity, no Run, no Issue). A deployment is what SYNQ actually runs on the workspace's behalf: a frozen snapshot of a suite config, mapped to workspace-level SYNQ integrations, optionally scheduled or triggerable by API. Identity: every deployment has a stable deployment_id (UUIDv7) assigned on first promote. It survives re-promotes, schedule/mapping changes, and pause/resume. Downstream AssetCommand / RunCommand publication keys off deployment_id so Entity identity does not fragment on promote churn. - name: synq.agent.recon.v1.YamlService description: >- YamlService provides stateless conversion between YAML config format and proto. This is useful for UI editors that need to display/edit suite configs as YAML. - name: synq.ingest.cloudwatch.v1.CloudwatchService - name: synq.ingest.airflow.v1.AirflowLogsService - name: synq.ingest.openlineage.v1.OpenlineageService - name: synq.ingest.dwh.v1.DwhService - name: synq.owners.v1.OwnersService description: |- OwnersService manages owners and their ownerships — the "alert routing as code" surface. An owner is a named responsible party with notification channels (contacts); an ownership assigns a set of assets to an owner and configures the alerts routed to it. Owner is the resource, ownership its sub-resource: an ownership is meaningless without its owner, and deleting an owner deletes its ownerships. Ids are opaque UUIDs supplied by the caller, which makes writes idempotent (a retried create converges instead of duplicating). Mutable fields are optional on the Upsert calls: a set field is written, an omitted field is left unchanged. Pass the `etag` you last read to guard against overwriting a concurrent edit. Related: `synq.dataproducts.v2.DataproductsService` (an ownership can own a whole data product), `synq.alerts.v1.AlertsService` (how the configured alerts are reported), and `synq.users.v1.UsersService` (resolve the users behind `UserContact` and Slack/Teams mentions). - name: synq.domains.v2.DomainsService description: >- DomainsService manages data domains — named areas of ownership that group the assets, data products and sub-domains belonging to one part of the business. Ids are opaque UUIDs supplied by the caller, which makes writes idempotent (a retried create converges instead of duplicating). Mutable fields are optional on Upsert: a field that is set is written, a field that is omitted is left unchanged. Pass the `etag` you last read to guard against overwriting a concurrent edit. A domain may contain other domains and data products, so membership resolution is recursive. Every write that adds such a reference — including a change of `parent_id` — is rejected if it would close a loop, so a definition can always be resolved in finite time. - name: synq.domains.members.v1.DomainMembersService description: DomainMembersService can be used to manage domain memberships. - name: synq.domains.v1.DomainsService description: DomainsService can be used to manage domains. - name: synq.platforms.v1.PlatformsService description: PlatformsService is a service for managing Platforms and Integrations. - name: synq.incidents.v1.IncidentsService description: IncidentsService is a service for managing Incidents. paths: /api/entities/v2/checks/categorisation-rules/preview: post: tags: - synq.entities.checks.v2.ChecksCategorisationRulesService summary: PreviewRule description: |- Report what a candidate rule would change, without saving it. The candidate is slotted into the workspace's live rule set — replacing an existing rule when `id` names one — and the whole resolution is run over every check, so scope, priority, explicit categories and producer-declared categories are all honoured. The response separates the candidate's raw reach from its real effect, which are rarely the same number. Preview a rule before saving it: one that matches broadly can recategorise a large part of a workspace in a single sweep. operationId: synq.entities.checks.v2.ChecksCategorisationRulesService.PreviewRule requestBody: content: application/json: schema: $ref: '#/components/schemas/synq.entities.checks.v2.PreviewRuleRequest' required: true responses: '200': description: Success content: application/json: schema: $ref: >- #/components/schemas/synq.entities.checks.v2.PreviewRuleResponse components: schemas: synq.entities.checks.v2.PreviewRuleRequest: type: object properties: id: type: string format: uuid description: >- Set to an existing rule's id to preview an edit to it — the candidate replaces that rule during resolution, so the result reflects the change rather than the addition of a second rule. Omit to preview a new rule. nullable: true dimension: $ref: '#/components/schemas/synq.entities.checks.v2.CategoryDimension' not: enum: - 0 description: The dimension the candidate would categorise along. scope: $ref: '#/components/schemas/synq.entities.checks.v2.RuleScope' description: |- Scope the candidate would be saved with. Defaults to RULE_SCOPE_WORKSPACE. title: type: string maxLength: 200 description: >- Title the candidate would be saved with. Does not affect the outcome. category: type: string maxLength: 200 minLength: 1 description: The category the candidate would assign. matcher: $ref: '#/components/schemas/synq.entities.checks.v2.CheckMatcher' description: Which checks the candidate would apply to. priority: type: integer maximum: 1000000 minimum: -1000000 format: int32 description: >- Priority the candidate would be saved with. It participates in resolution exactly as it would once saved, so previewing at the wrong priority reports the wrong impact. sampleSize: type: integer maximum: 1000 minimum: 0 format: int32 description: >- How many check ids to return in each of the response's samples — it caps `affected_entity_ids` and `explicit_category_entity_ids` independently, so either may come back at this size. Defaults to 100, and may be 0 for counts only. The counts are always exact whatever this is set to. nullable: true title: PreviewRuleRequest required: - matcher additionalProperties: false synq.entities.checks.v2.PreviewRuleResponse: type: object properties: matchedCount: type: - integer - string format: int64 description: |- Checks whose predicate the candidate matches at all — its raw reach, whether or not it ends up winning them. affectedCount: type: - integer - string format: int64 description: |- Checks whose effective category on the candidate's dimension would actually change. This is the rule's real impact. It equals newly_categorised_count + reassigned_count, and matched_count equals this plus unchanged_count. newlyCategorisedCount: type: - integer - string format: int64 description: >- Of the affected checks, how many have no category on this dimension today. reassignedCount: type: - integer - string format: int64 description: >- Of the affected checks, how many already have a different category that the candidate would take over. Worth a second look before saving. unchangedCount: type: - integer - string format: int64 description: >- Checks the candidate matches whose effective category would not change. The three fields below say why, and add up to this one. affectedEntityIds: type: array items: type: string description: A sample of the affected checks, ordered by entity id. affectedEntityIdsTruncated: type: boolean description: True when the sample was cut short by `sample_size`. higherPriorityRuleCount: type: - integer - string format: int64 description: >- Of the unchanged checks, how many a rule of higher priority already wins, so the candidate never gets to assign anything. Raise the candidate's priority to take these over. explicitCategoryCount: type: - integer - string format: int64 description: >- Of the unchanged checks, how many carry a category set explicitly on the check, or declared by the tool that produced it. Either outranks every rule, so these are the checks the candidate looks like it covers and does not — no priority will win them. Clear the explicit category to hand a check back to the rules. sameCategoryCount: type: - integer - string format: int64 description: >- Of the unchanged checks, how many the candidate does win, assigning the category the check already has. Nothing to do about these; the rule is simply agreeing with what is there. explicitCategoryEntityIds: type: array items: type: string description: >- A sample of the checks counted in `explicit_category_count`, ordered by entity id — the ones worth showing a customer, because a rule that reads as covering them does not. explicitCategoryEntityIdsTruncated: type: boolean description: True when that sample was cut short by `sample_size`. title: PreviewRuleResponse additionalProperties: false synq.entities.checks.v2.CategoryDimension: type: string title: CategoryDimension enum: - CATEGORY_DIMENSION_UNSPECIFIED - CATEGORY_DIMENSION_TECHNICAL - CATEGORY_DIMENSION_GOVERNANCE description: >- The dimension a category classifies a check along. A check carries at most one category per dimension, and the two resolve independently of each other. synq.entities.checks.v2.RuleScope: type: string title: RuleScope enum: - RULE_SCOPE_UNSPECIFIED - RULE_SCOPE_GLOBAL - RULE_SCOPE_WORKSPACE description: |- Whether a categorisation rule belongs to the workspace or is one of the platform-provided defaults. synq.entities.checks.v2.CheckMatcher: type: object oneOf: - properties: attributes: $ref: >- #/components/schemas/synq.entities.checks.v2.CheckAttributesMatcher title: attributes description: >- Select checks by their attributes. Covers almost every rule and is the only form the rule editor can render. title: attributes required: - attributes - properties: expression: type: string title: expression maxLength: 20000 minLength: 1 description: |- A CEL expression returning a boolean, for the rare predicate the attribute matcher cannot express — combining alternatives across dimensions, or matching on a substring of a name. See https://github.com/google/cel-spec for the language. Variables available to the expression: platform, asset_type, package, kind, name, description (string) is_platform_native (bool) annotations (map) Platform and entity-type enum value names are available as string constants. For example: platform == PLATFORM_DBT && kind.startsWith("not_null") title: expression required: - expression additionalProperties: false description: Which checks a categorisation rule applies to. synq.entities.checks.v2.CheckAttributesMatcher: type: object properties: facets: $ref: '#/components/schemas/synq.entities.checks.v2.CategorisationFacets' description: Platform, entity type, package and kind the check must be one of. names: type: array items: type: string maxLength: 500 maxItems: 200 maxItems: 200 description: >- Patterns matched against the check's name. `*` stands for any sequence of characters, including none; every other character matches literally. A check matches when at least one pattern matches. An empty list matches any name. annotationMatches: type: array items: $ref: '#/components/schemas/synq.entities.checks.v2.AnnotationMatch' maxItems: 50 description: >- Conditions on the check's annotations. A check must satisfy every entry. title: CheckAttributesMatcher additionalProperties: false description: |- Selects checks by their attributes. A check matches when every populated field matches it; an empty field places no constraint, so an entirely empty matcher matches every check in the workspace. This is the form to reach for first: it is what the rule editor writes, what reads back legibly, and what ListCategorisationFilters offers values for. synq.entities.checks.v2.CategorisationFacets: type: object properties: dataPlatformTypes: type: array items: $ref: '#/components/schemas/synq.platforms.v1.DataPlatformType' maxItems: 200 description: Platforms the check runs on. entityTypes: type: array items: $ref: '#/components/schemas/synq.entities.v1.EntityType' maxItems: 500 description: Entity types of the check itself, e.g. ENTITY_TYPE_DBT_TEST. packages: type: array items: type: string maxLength: 500 maxItems: 200 maxItems: 200 description: Packages the check comes from, e.g. "dbt_utils". kinds: type: array items: type: string maxLength: 500 maxItems: 500 maxItems: 500 description: Check kinds, e.g. "not_null", "unique". title: CategorisationFacets additionalProperties: false description: >- A set of check attributes. The same four dimensions select checks in three places — the predicate of a categorisation rule, the filter on a check listing, and the values a workspace actually has — so one message carries them everywhere and a value read from one can be passed straight to the next. An empty list places no constraint on its dimension. Within a list the values are alternatives; across lists they combine. synq.entities.checks.v2.AnnotationMatch: type: object allOf: - properties: key: type: string title: key maxLength: 200 minLength: 1 description: Annotation key to look up on the check. - oneOf: - properties: equals: type: string title: equals maxLength: 1000 description: Matches when the value equals this string exactly. title: equals required: - equals - properties: exists: type: boolean title: exists description: >- Matches when the key is present, whatever its value. Set it to true; a false value is not a negation and is rejected. const: 'true' title: exists required: - exists - properties: in: $ref: >- #/components/schemas/synq.entities.checks.v2.AnnotationValues title: in description: Matches when the value is one of these. title: in required: - in - properties: regex: type: string title: regex maxLength: 1000 description: Matches when the value matches this RE2 regular expression. title: regex required: - regex title: AnnotationMatch additionalProperties: false description: |- A condition on one annotation of a check. Annotations are the key/value metadata a producer attaches to a check — a dbt test's `meta` entries, for example — which makes them the way to categorise by something only your own team knows, such as a domain or an owning squad. synq.platforms.v1.DataPlatformType: type: string title: DataPlatformType enum: - DATA_PLATFORM_TYPE_UNSPECIFIED - DATA_PLATFORM_TYPE_BIGQUERY - DATA_PLATFORM_TYPE_LOOKER - DATA_PLATFORM_TYPE_DBT - DATA_PLATFORM_TYPE_DBT_CLOUD - DATA_PLATFORM_TYPE_DBT_SELF_HOSTED - DATA_PLATFORM_TYPE_SNOWFLAKE - DATA_PLATFORM_TYPE_GCP - DATA_PLATFORM_TYPE_GIT - DATA_PLATFORM_TYPE_GITHUB - DATA_PLATFORM_TYPE_REDSHIFT - DATA_PLATFORM_TYPE_TABLEAU - DATA_PLATFORM_TYPE_AIRFLOW - DATA_PLATFORM_TYPE_CLICKHOUSE - DATA_PLATFORM_TYPE_POSTGRES - DATA_PLATFORM_TYPE_MYSQL - DATA_PLATFORM_TYPE_DATABRICKS - DATA_PLATFORM_TYPE_SQLMESH - DATA_PLATFORM_TYPE_DUCKDB - DATA_PLATFORM_TYPE_TRINO - DATA_PLATFORM_TYPE_ATLAN - DATA_PLATFORM_TYPE_COALESCE - DATA_PLATFORM_TYPE_CASTORDOC - DATA_PLATFORM_TYPE_POWERBI - DATA_PLATFORM_TYPE_THOUGHTSPOT - DATA_PLATFORM_TYPE_SIGMA - DATA_PLATFORM_TYPE_DOMO - DATA_PLATFORM_TYPE_MSSQL - DATA_PLATFORM_TYPE_ORACLE - DATA_PLATFORM_TYPE_ATHENA - DATA_PLATFORM_TYPE_FABRIC - DATA_PLATFORM_TYPE_SYNQ synq.entities.v1.EntityType: type: string title: EntityType enum: - ENTITY_TYPE_UNSPECIFIED - ENTITY_TYPE_BQ_TABLE - ENTITY_TYPE_BQ_VIEW - ENTITY_TYPE_LOOKER_LOOK - ENTITY_TYPE_LOOKER_EXPLORE - ENTITY_TYPE_LOOKER_VIEW - ENTITY_TYPE_LOOKER_DASHBOARD - ENTITY_TYPE_DBT_MODEL - ENTITY_TYPE_DBT_TEST - ENTITY_TYPE_DBT_SOURCE - ENTITY_TYPE_DBT_PROJECT - ENTITY_TYPE_DBT_METRIC - ENTITY_TYPE_DBT_SNAPSHOT - ENTITY_TYPE_DBT_SEED - ENTITY_TYPE_DBT_ANALYSIS - ENTITY_TYPE_DBT_EXPOSURE - ENTITY_TYPE_DBT_GROUP - ENTITY_TYPE_DBT_SEMANTIC_MODEL - ENTITY_TYPE_DBT_CLOUD_PROJECT - ENTITY_TYPE_DBT_CLOUD_JOB - ENTITY_TYPE_SNOWFLAKE_TABLE - ENTITY_TYPE_SNOWFLAKE_VIEW - ENTITY_TYPE_SNOWFLAKE_STREAM - ENTITY_TYPE_SNOWFLAKE_DYNAMIC_TABLE - ENTITY_TYPE_SNOWFLAKE_TASK - ENTITY_TYPE_SNOWFLAKE_EXTERNAL_TABLE - ENTITY_TYPE_SNOWFLAKE_MATERIALIZED_VIEW - ENTITY_TYPE_SNOWFLAKE_PROCEDURE - ENTITY_TYPE_SNOWFLAKE_FUNCTION - ENTITY_TYPE_SNOWFLAKE_SEMANTIC_VIEW - ENTITY_TYPE_REDSHIFT_TABLE - ENTITY_TYPE_REDSHIFT_VIEW - ENTITY_TYPE_REDSHIFT_PROCEDURE - ENTITY_TYPE_REDSHIFT_FUNCTION - ENTITY_TYPE_TABLEAU_EMBEDDED - ENTITY_TYPE_TABLEAU_PUBLISHED - ENTITY_TYPE_TABLEAU_CUSTOM_SQL - ENTITY_TYPE_TABLEAU_TABLE - ENTITY_TYPE_TABLEAU_SHEET - ENTITY_TYPE_TABLEAU_DASHBOARD - ENTITY_TYPE_AIRFLOW_DAG - ENTITY_TYPE_AIRFLOW_TASK - ENTITY_TYPE_CLICKHOUSE_TABLE - ENTITY_TYPE_CLICKHOUSE_VIEW - ENTITY_TYPE_ANOMALY_MONITOR - ENTITY_TYPE_ANOMALY_MONITOR_SEGMENT - ENTITY_TYPE_SQLTEST_TEST - ENTITY_TYPE_RECON_SUITE - ENTITY_TYPE_RECON_CASE - ENTITY_TYPE_POSTGRES_TABLE - ENTITY_TYPE_POSTGRES_VIEW - ENTITY_TYPE_MYSQL_TABLE - ENTITY_TYPE_MYSQL_VIEW - ENTITY_TYPE_DATABRICKS_WAREHOUSE - ENTITY_TYPE_DATABRICKS_TABLE - ENTITY_TYPE_DATABRICKS_VIEW - ENTITY_TYPE_DATABRICKS_JOB - ENTITY_TYPE_DATABRICKS_JOB_TASK - ENTITY_TYPE_DATABRICKS_NOTEBOOK - ENTITY_TYPE_DATABRICKS_QUERY - ENTITY_TYPE_DATABRICKS_DASHBOARD - ENTITY_TYPE_SQLMESH_PROJECT - ENTITY_TYPE_SQLMESH_SQL_MODEL - ENTITY_TYPE_SQLMESH_PYTHON_MODEL - ENTITY_TYPE_SQLMESH_EXTERNAL - ENTITY_TYPE_SQLMESH_SEED - ENTITY_TYPE_SQLMESH_AUDIT - ENTITY_TYPE_SQLMESH_UNIT_TEST - ENTITY_TYPE_SQLMESH_ENVIRONMENT - ENTITY_TYPE_SQLMESH_SNAPSHOT - ENTITY_TYPE_DUCKDB_TABLE - ENTITY_TYPE_DUCKDB_VIEW - ENTITY_TYPE_TRINO_TABLE - ENTITY_TYPE_TRINO_VIEW - ENTITY_TYPE_ATLAN_ASSET - ENTITY_TYPE_ATLAN_INTEGRATION - ENTITY_TYPE_COALESCE_PROJECT - ENTITY_TYPE_COALESCE_ENVIRONMENT - ENTITY_TYPE_COALESCE_NODE - ENTITY_TYPE_COALESCE_NODE_TEST - ENTITY_TYPE_COALESCE_JOB - ENTITY_TYPE_CASTORDOC_TABLE - ENTITY_TYPE_CASTORDOC_DASHBOARD - ENTITY_TYPE_CASTORDOC_VIEW - ENTITY_TYPE_CASTORDOC_TILE - ENTITY_TYPE_CASTORDOC_VIZ_MODEL - ENTITY_TYPE_POWERBI_REPORT - ENTITY_TYPE_POWERBI_TILE - ENTITY_TYPE_POWERBI_DATASET - ENTITY_TYPE_POWERBI_DASHBOARD - ENTITY_TYPE_POWERBI_TENANT - ENTITY_TYPE_THOUGHTSPOT_LIVEBOARD - ENTITY_TYPE_THOUGHTSPOT_WORKSHEET - ENTITY_TYPE_SIGMA_WORKBOOK - ENTITY_TYPE_SIGMA_DATA_MODEL - ENTITY_TYPE_SIGMA_ORGANIZATION - ENTITY_TYPE_DOMO_PAGE - ENTITY_TYPE_DOMO_DATASET - ENTITY_TYPE_MSSQL_TABLE - ENTITY_TYPE_MSSQL_VIEW - ENTITY_TYPE_ORACLE_TABLE - ENTITY_TYPE_ORACLE_VIEW - ENTITY_TYPE_ATHENA_TABLE - ENTITY_TYPE_ATHENA_VIEW - ENTITY_TYPE_FABRIC_TABLE - ENTITY_TYPE_FABRIC_VIEW - ENTITY_TYPE_CUSTOM_ENTITY_GENERIC - ENTITY_TYPE_CUSTOM_ENTITY_CUSTOM_TYPE_MIN - ENTITY_TYPE_CUSTOM_ENTITY_CUSTOM_TYPE_MAX synq.entities.checks.v2.AnnotationValues: type: object properties: values: type: array items: type: string maxLength: 1000 maxItems: 200 minItems: 1 maxItems: 200 minItems: 1 title: AnnotationValues additionalProperties: false description: A list of accepted annotation values. securitySchemes: bearerAuth: type: http scheme: bearer ````