Skip to content

Welcome to eXate Platform Documentation

The eXate Platform is the core component that powers all other eXate products. It unifies policy management, data classification, and data protection into one automated flow.

The Platform Journey

If you're setting eXate up for the first time, work through these in order. Each step builds on the one before it, and each page also covers the supporting reference data that belongs to that step, rather than sending you off to a separate "static data" section:

  1. Attributes & Attribute Groups, classify what you're protecting (Email, Salary, SSN).
  2. Countries, scope where that data is allowed to be shared, including sharing with external Third Parties.
  3. Claims, define reusable conditions about who's asking, including Departments and a worked Subject Entities example. This is the step that feels backwards the first time, see that page for why it comes before the rule that uses it.
  4. Policies, combine Attributes, Countries, and Claims into an actual governance rule: who can see what, where, and why, including the Data Usage settings behind Purpose of Use.
  5. Manifests, connect that governance rule to your real data by mapping actual JSON paths, files, or database columns to Attributes, including registering the Application it belongs to. This is what turns a Policy into working, column-level protection.
  6. Data Protection (PETs), choose how unprotected-ineligible requests actually get protected: masking, tokenisation, or encryption, and Data Exfiltration Protection for guarding data once it leaves the application entirely.
  7. Filter Expressions, add row-level security on top of the column-level protection above.
  8. Vault, where the configuration and database connections underneath all of the above are managed.
  9. Admin, manage the tenancy and Users of the eXate platform itself, including Metering to monitor usage once it's running.

See the Glossary for a plain-English definition of every object mentioned above.

Platform Flow

This diagram shows the same shape end to end: how data gets classified, how that classification drives Policy, and how Policy is enforced when someone requests the data. Highlighted here: how a data catalog item (an Attribute Group or Tag) gets identified and applied, and how Claims shape the identity side of that evaluation.

flowchart LR
    classDef step fill:#eaf3fa,stroke:#01328e,stroke-width:2px,color:#01328e,font-weight:bold;
    classDef highlight fill:#fef3c7,stroke:#d97706,stroke-width:2.5px,color:#92400e,font-weight:bold;
    classDef sub fill:#ffffff,stroke:#add8e6,stroke-width:1.5px,color:#01328e;

    Data["Incoming Data<br/>(database, API, file)"]:::step --> Manifest["Manifest<br/>maps fields to Attributes"]:::step
    Manifest --> AttrGroup["Attribute Group / Tag<br/>identified"]:::highlight
    GatorAId["GatorAId<br/>(automatic classification)"]:::sub -.-> AttrGroup
    AttrGroup --> Policy["Policy evaluation"]:::step
    Claims["Claims<br/>user request context"]:::highlight --> Policy
    Policy -->|"Country + Purpose of Use + Claims match"| PET["PET applied<br/>(mask / tokenise / encrypt)"]:::step
    PET --> Output["Data returned<br/>protected or unprotected"]:::step

eXate's equivalent of a "data catalog" is two objects working together: Attribute Groups, which you define, and Tags, which can be applied automatically. GatorAId is what does that automatic classification. On the identity side, Claims are where you can strip out fields you don't want evaluated, or add extra context the calling application didn't originally send, before Policy evaluates them.

The two highlighted nodes above, Attribute Group / Tag and Claims, are the ones this page is about. The same shape applies with different emphasis elsewhere, for example Policy on the Policies page, or PET on the Data Protection page.

How eXate Protects Data

flowchart LR
    classDef step fill:#eaf3fa,stroke:#01328e,stroke-width:2px,color:#01328e,font-weight:bold;
    classDef sub fill:#ffffff,stroke:#add8e6,stroke-width:1.5px,color:#01328e;

    subgraph S1["1. Capture the Policies"]
        direction TB
        A1["Access Control (ABAC)"]:::sub
        A2["Data Sovereignty"]:::sub
        A3["Data Regulation"]:::sub
    end

    subgraph S2["2. Automatically Classify Data"]
        direction TB
        B1["Semi-structured data (JSON, XML), unstructured text"]:::sub
        B2["GatorAId classification"]:::sub
        B3["DB schemas and data"]:::sub
    end

    subgraph S3["3. Automatically Protect the Data"]
        direction TB
        C1["APIgator: realtime protection via REST/gRPC, data in motion"]:::sub
        C2["Datagator: realtime and bulk protection, data at rest"]:::sub
    end

    S1:::step --> S2:::step --> S3:::step

This applies consistently whether the underlying deployment is physical, virtual, private cloud, public cloud, or sovereign cloud.

Data Protection and Entitlements

Once data is protected, access to it is resolved dynamically per consumer, based on the Policies, Claims, and Country Access Lists defined against the relevant Attributes, so the same stored protected data can be presented differently to different consumers.

flowchart LR
    classDef step fill:#eaf3fa,stroke:#01328e,stroke-width:2px,color:#01328e,font-weight:bold;
    classDef store fill:#01328e,stroke:#01328e,stroke-width:2px,color:#ffffff,font-weight:bold;
    classDef consumer fill:#ffffff,stroke:#add8e6,stroke-width:1.5px,color:#01328e;

    P["Data Producer<br/>(source system)"]:::step -->|"Datagator / APIgator / GatorSet"| Store["Stored Protected Data"]:::store
    Store -->|"via APIgator"| C1["Data Consumer 1<br/>Full access (entitled)"]:::consumer
    Store -->|"via JDBC / Datagator"| C2["Data Consumer 2<br/>Partially masked"]:::consumer
    Store -->|"via Datagator"| C3["Data Consumer 3<br/>No access (fields empty)"]:::consumer

Each consumer's view is determined at the point of access, not baked into the stored data, so the same underlying record can be fully visible, partially masked, or withheld entirely depending on who's asking and from where.

eXate Object Hierarchy & Flow

Understanding the relationship between core eXate objects is essential for configuring data protection policies. Below is a conceptual flow diagram showcasing how these objects interact, followed by a detailed breakdown of their associations.

flowchart TD
    %% Custom Styles for Premium Look (Optimized for Light & Dark Modes)
    classDef manifest fill:#e0f2fe,stroke:#0284c7,stroke-width:2.5px,color:#0369a1,font-weight:bold;
    classDef rule fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#15803d,font-weight:bold;
    classDef filter fill:#f3e8ff,stroke:#9333ea,stroke-width:2px,color:#6b21a8,font-weight:bold;
    classDef entity fill:#f1f5f9,stroke:#475569,stroke-width:1.5px,color:#334155,font-weight:bold;
    classDef input fill:#fee2e2,stroke:#dc2626,stroke-width:1.5px,color:#991b1b,font-weight:bold;
    classDef pet fill:#ccfbf1,stroke:#0d9488,stroke-width:2px,color:#115e59,font-weight:bold;

    %% Nodes (Quotes added around labels to prevent parsing errors)
    M["Manifest <br><i>(Synonym: Entitlement)</i>"]:::manifest
    Path["Path / Schema Path <br><i>(attributePath in map)</i>"]:::entity
    Attr["Attribute"]:::entity
    R["Policy <br><i>(formerly Rule / Rule Pack)</i>"]:::rule
    Ctry["Country <br><i>(Country Access List)</i>"]:::input
    Clm["Claim <br><i>(Claims Definition / Pack)</i>"]:::input
    F["Filter <br><i>(Boolean Expression / Restriction)</i>"]:::filter
    Lst["List"]:::input
    Act["Action <br><i>(Action Path & Directive)</i>"]:::entity
    PG["PET Group <br><i>(Protection Definition)</i>"]:::pet
    PET["PET <br><i>(Privacy Enhancing Tech)</i>"]:::pet

    %% Manifest Composition
    M -->|Contains / Defines Schema via| Path
    Path -->|Maps to| Attr
    M -->|Contains| F

    %% Rule Hierarchy & Access Control
    R -->|Links to / Governs Access to| Attr
    Ctry -->|Evaluated in| R
    Clm -->|Required for| R

    %% Filter referencing List, Claims and executing Actions
    F -->|References / Evaluates| Lst
    F -->|References / Evaluates| Clm
    F -->|Executes| Act
    Act -->|Applied on| Path

    %% PET Hierarchy & Default Configuration
    PET -->|Belongs to / Configured in| PG
    PG -->|Defines Default Protection for| Attr

    %% Path-Level Override
    Path -->|Can Override Default PET with| PET

    %% Subgraphs
    subgraph RuleGroup ["Access Control & Sovereignty"]
        R
    end

    subgraph FilterGroup ["Data Protection Filters (Restrictions)"]
        F
        Act
    end

    subgraph ReferenceGroup ["Reference Elements"]
        Ctry
        Clm
        Lst
    end

    subgraph PETGroup ["Privacy Enhancing Technologies (PETs)"]
        PG
        PET
    end

    %% Visual Styling for Subgraphs (Transparent fills to inherit theme color)
    style RuleGroup fill:none,stroke:#16a34a,stroke-width:1px,stroke-dasharray: 5 5;
    style FilterGroup fill:none,stroke:#9333ea,stroke-width:1px,stroke-dasharray: 5 5;
    style ReferenceGroup fill:none,stroke:#475569,stroke-width:1px,stroke-dasharray: 5 5;
    style PETGroup fill:none,stroke:#0d9488,stroke-width:1px,stroke-dasharray: 5 5;

Core Objects & Relationships

Based on the eXate Management OpenAPI Specification (OAS), the platform's schema centers around several key objects, their interactions, and data flows:

1. Manifest (Synonym: Entitlement)

  • Definition: The top-level root object representing the data schema, access constraints, and dynamic restrictions for a dataset.
  • Relations & Flow:
    • Attribute Map (attributeMap): Defines the dataset schema by mapping specific JSON/XML paths or database column paths (attributePath) to global platform Attributes.
    • Filters (restrictions): Contained directly within the Manifest to enforce fine-grained, dynamic protection filters based on context.
    • Policies (rules in the API schema): In the physical OAS schema, this object is still named rules for backward compatibility, but conceptually it's now a Policy. Policies are associated with the Manifest, and govern and link directly to Attributes to authorize or deny access.

2. Attributes

  • Definition: Global, reusable definitions representing specific classifications of data (e.g., Email, CreditCard, Salary).
  • Relations & Flow:
    • Mapped to specific schema or document elements within a Manifest's attributeMap.
    • Governed by Policies to determine who can access them.
    • Assigned a default PET Group to dictate how they are protected by default.

3. Policies (formerly Rules / Rule Packs)

  • Definition: Determines whether access to specific attributes is granted during protect or access requests. See Policies for the full concept and how to create one.
  • Relations (Policy Composition):
    • Attribute Links: Rather than being owned by a Manifest, Policies conceptually link to and govern access to specific Attributes or Attribute Groups.
    • Country (Country Access Lists): Defines geographical access constraints and data sovereignty criteria (e.g., ISO country code matching).
    • Claim (Claims Definition / Pack): Defines user context parameters (such as roles, departments, or security clearances) that must match to trigger the Policy.
    • Access Granting: Attribute, Country, and Claim converge to define and evaluate a Policy.

4. Filters (Restrictions / Boolean Expressions)

  • Definition: Dynamic, fine-grained restrictions executed to alter, redact, or mask datasets when specific preconditions are satisfied.
  • Relations & Flow:
    • Configured directly inside the Manifest.
    • Can contain Boolean Expressions which dynamically reference:
      • Lists: Reference data values used to perform set or group matches, and to supply substitute values for masking.
      • Claims: Dynamic user traits used for conditional eligibility.
    • Executes Actions (Directives) (e.g., redact, mask, tokenize, encrypt) targeted at specific Paths or Attributes.

5. List

  • Definition: Managed collections of reference values used to perform set or group matches within Filter expressions.
  • Properties & Structure:
    • Defined via SubstituteGroup.SubstituteGroupV2 in the OAS.
    • Supports multiple data types (ListValueType) such as String, Date, Int, Decimal, Boolean, and Timestamp.
    • Classified by ListType into default (globally available) or manifest (specific to an entitlement).
    • Contains ListValues which are an array of values (SubstituteGroup.ListArray) used during evaluation.

6. Privacy Enhancing Technologies (PETs) & PET Groups

  • Definition: Algorithms and configurations used to protect sensitive data through masking, tokenization, or encryption.
  • Relations & Flow:
    • PETs: The individual algorithms (e.g., CustomStringMaskPet, cryptographic PETs, masking PETs, or typed PETs like StringPET, DateTimePET, etc.).
    • PET Group (Protection Definition): Modeled as ProtectionDefinition.ProtectionDefinition (or SubPETGroupv2). A PET Group groups multiple PET configurations together (e.g., grouping CryptographicJob and MaskingJob settings).
    • Attribute Linking: Each Attribute is linked to a default PET Group (via its ProtectionDefinition field), defining how it is protected by default.
    • Path-Level Overrides: Within a Manifest's attributeMap, default protection settings can be overridden on a per-path basis via the overridePET field. This allows a specific JSON path or database column to use a different PET or custom protection setting instead of the Attribute's default PET Group.

Data Sovereignty Concepts

These terms are often used interchangeably but mean distinct things. eXate's policy engine is built to address all five:

  • Data Residency: the physical location where data is stored, without necessarily addressing the governing laws.
  • Data Sovereignty: the notion that data is subject to the laws of the country or jurisdiction in which it is physically stored.
  • Data Localisation: a requirement that data cannot leave a particular jurisdiction.
  • Data Privacy: the protection of personal data from those who should not have access to it, in order to establish trust, comply with regulations, maintain ethical practices, and drive innovation.
  • Data Protection: the process of protecting sensitive information from loss, using tools such as encryption, anonymisation, pseudonymisation, and consent.

Sections

  • Glossary: Plain-English definitions of every eXate concept.
  • Attributes & Attribute Groups: Classify what you're protecting, plus Meta Tags.
  • Countries: Scope where data is allowed to be shared, plus Third Parties.
  • Claims: Reusable conditions about who's asking, plus Departments and a worked Subject Entities example.
  • Policies: What Policies are and how to create them, plus Data Usage.
  • Manifests: What a Manifest is, plus registering Applications, and portal walkthroughs for building one in APIgator and Datagator.
  • Data Classification: Automatically discover, scan, and classify enterprise data sources using intelligent engines.
  • Enforcement Points: Intercept and protect data across different architectural layers, including APIs, Bulk ETL, Database Proxy, and JDBC.
  • Data Protection: Data masking, cryptographic PETs, Custom PETs, the List substitute-value mechanism, and Data Exfiltration Protection.
  • Filter Expressions: Row-level security.
  • Vault: Key management, database connections, and multi-region configuration.
  • Admin: Managing the tenancy, its Users, and Metering.