docs(gitbook-71): No subject

docs/SUMMARY.md

@@ -19,10 +19,7 @@
 
 ## Reference
 
-* [Data Catalog Integrations](reference/data-catalog-integrations/README.md)
-  * [Collibra](reference/data-catalog-integrations/collibra.md)
-  * [Datahub](reference/data-catalog-integrations/datahub.md)
-  * [Open Data Discovery (ODD)](reference/data-catalog-integrations/open-data-discovery-odd.md)
+* [Data Catalog Integrations](reference/data-catalog-integrations.md)
 * [Processing Platform Integrations](reference/processing-platform-integrations/README.md)
   * [BigQuery](reference/processing-platform-integrations/bigquery.md)
   * [Databricks](reference/processing-platform-integrations/databricks.md)

docs/data-policy/rule-set/README.md

@@ -4,6 +4,6 @@ description: On-view adaptations of the data
 
 # Rule Set
 
-You have defined the structure of your data, either using a [`Processing Platform Integration`](../../reference/processing-platform-integrations/)  a [`Data Catalog Integration`](../../reference/data-catalog-integrations/) or by hand in thee attributes list of the data policy. The [`Principals`](../principals.md) in your processing platform of choice are defined and you want to distinguish regarding what data is available to which principals. Here `Rule Sets` come in to play.
+You have defined the structure of your data, either using a [`Processing Platform Integration`](../../reference/processing-platform-integrations/)  a [`Data Catalog Integration`](../../reference/data-catalog-integrations.md) or by hand in thee attributes list of the data policy. The [`Principals`](../principals.md) in your processing platform of choice are defined and you want to distinguish regarding what data is available to which principals. Here `Rule Sets` come in to play.
 
 Each `Rule Set` defines a [`Target`](target.md) view, dynamically defined for each (set of) `Principal`. It  allows you to carefully control what principals have access to what data. [`Field Transforms`](field-transform.md) apply transforms (masking, nullifying, replacing, etc.) to a specific field, whereas [`Filters`](filter.md) are able to filter complete rows from the view. Linking transforms and filters to the correct principals makes for a powerful tool.

docs/data-policy/rule-set/field-transform.md

@@ -164,7 +164,9 @@ Below you will find raw data and sample outputs for different sets of principals
 | 456    | [email protected]  | Lenovo  |
 | 789    | [email protected] | HP      |
 {% endtab %}
+{% endtabs %}
 
+{% tabs %}
 {% tab title="[ F&R ]" %}
 | userId | email            | brand |
 | ------ | ---------------- | ----- |

docs/data-policy/rule-set/filter.md

@@ -8,7 +8,7 @@ description: Condition based row filtering
 
 When you have dataset that includes, for example, both large and small transactions, you might only want the _Fraud and Risk_ [`Principal`](../principals.md) to be able to see these large transactions. We defined row based filtering. Each `Filter` contains a list of `Condition` and each condition consists of a list of `Principal` and the actual condition.
 
-Similar to [`Field Transform`](field-transform.md), the list of `Principal` defines to which groups of users the `Filter` must be applied. The condition is a _SQL expression_ that should match the specified [`Processing Platform`](../../reference/processing-platform-integrations/)'s syntax. If the condition evaluates to true, the set of `Principal` is allowed to view the data, else the rows are omitted in the resulting view.
+Similar to [`Field Transform`](field-transform.md), the list of `Principal` defines to which groups of users the `Filter` must be applied. The condition is a _SQL expression_ that should match the specified [`Processing Platform`](../../reference/processing-platform-integrations/)'s syntax. In contrast to `Field Transforms`, where each transform is defined for exactly one field, the filter conditions can contain logic regarding multiple fields. If the condition evaluates to true, the set of `Principal` is allowed to view the data, else the rows are omitted in the resulting view.
 
 Every `Filter` should at least contain one `Condition` without any `Principal`, defined as last item in the list. This `Condition` acts as the default or fallback filter.
 
@@ -49,10 +49,10 @@ filters:
 | 3             | 5000              | 24  |
 | 4             | 50                | 24  |
 | 5             | 2000              | 17  |
-
-
 {% endtab %}
+{% endtabs %}
 
+{% tabs %}
 {% tab title="[ F&R ]" %}
 | transactionId | transactionAmount | age |
 | ------------- | ----------------- | --- |

docs/data-policy/schema.md

@@ -6,7 +6,7 @@ description: The source's data structure
 
 ## Introduction
 
-The first step to defining a `Data Policy` is knowing what your source data looks like. This source data most likely will live in a [`Data Platform`](../reference/processing-platform-integrations/) or [`Data Catalog`](../reference/data-catalog-integrations/). But you will also be able to define the structure yourself. Below we demonstrate the different options to define your schema
+The first step to defining a `Data Policy` is knowing what your source data looks like. This source data most likely will live in a [`Data Platform`](../reference/processing-platform-integrations/) or [`Data Catalog`](../reference/data-catalog-integrations.md). But you will also be able to define the structure yourself. Below we demonstrate the different options to define your schema
 
 ### Bare Policy
 
@@ -155,4 +155,4 @@ If your `Data Platform` (or [`Processing Platform`](../reference/processing-plat
 
 ## Data Catalog
 
-The source's data structure can also be retrieved from a [`Data Catalog`](../reference/data-catalog-integrations/). Here too we provide both a [REST API](../reference/api-reference.md#catalogs-catalogid-databases-databaseid-schemas-schemaid-tables-tableid-bare-policy) and a CLI to receive the _bare policy_. Find out what the minimum required permissions are per `Data Catalog` in our [data catalog integration pages](../reference/data-catalog-integrations/). 
+The source's data structure can also be retrieved from a [`Data Catalog`](../reference/data-catalog-integrations.md). Here too we provide both a [REST API](../reference/api-reference.md#catalogs-catalogid-databases-databaseid-schemas-schemaid-tables-tableid-bare-policy) and a CLI to receive the _bare policy_. Find out what the minimum required permissions are per `Data Catalog` in our [data catalog integration pages](../reference/data-catalog-integrations.md). 

docs/getting-started/connect-a-data-catalog.md

@@ -4,7 +4,7 @@ description: How PACE connects to 0 or more data catalogs.
 
 # Connect a Data Catalog
 
-PACE can connect to various data catalogs, to retrieve the meta information that these contain about tables. Currently supported are [Collibra](https://www.collibra.com/us/en/resources/enterprise-data-catalogs), [Datahub](https://datahubproject.io/) and [Open Data Discovery](https://opendatadiscovery.org/). The [data-catalog-integrations](../reference/data-catalog-integrations/ "mention")section goes into details about how we use their information.
+PACE can connect to various data catalogs, to retrieve the meta information that these contain about tables. Currently supported are [Collibra](https://www.collibra.com/us/en/resources/enterprise-data-catalogs), [Datahub](https://datahubproject.io/) and [Open Data Discovery](https://opendatadiscovery.org/). The [data-catalog-integrations.md](../reference/data-catalog-integrations.md "mention")section goes into details about how we use their information.