> ## Documentation Index
> Fetch the complete documentation index at: https://docs.threataware.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Settings → Schemas

> The canonical Device and User data schemas — what fields exist, what types, what the AI can see

## What this page is

At `/settings/schemas`:

<img src="https://mintcdn.com/threatawareltd/IwzdezxNqgZB-5I4/images/core/settings-schemas.png?fit=max&auto=format&n=IwzdezxNqgZB-5I4&q=85&s=0ff8e445f97ea171d655aa69243b7866" alt="Schemas page with two rows — Device Data and User Data, each with Schema configured status, X-RAY button, Edit button" width="1440" height="900" data-path="images/core/settings-schemas.png" />

*"Manage AI schemas for your organization."*

Two schemas, both shipped configured:

* **Device Data** — every field on a device record
* **User Data** — every field on a user record

Each row has:

* **Status** — `Schema configured` (live)
* **X-RAY** button — view the schema structure as JSON
* **Edit** button — modify which fields are exposed and how

## What schemas are used for

The schemas control two related things:

### What the AI sees

Reporting builds apps with an AI Composer. The AI sees **schema only** — field names, field types, structure. It does **not** see actual data values. The Schemas page is where you decide which fields the AI knows exist.

| Without exposure                              | With exposure                                                   |
| --------------------------------------------- | --------------------------------------------------------------- |
| AI can't reference a custom field in a prompt | AI knows `metadata.cost_center` exists and is a string          |
| Field is invisible to Studio Composer         | Field appears in autocomplete and is usable in generated charts |

### What X-Ray reveals

[X-Ray](/x-ray) shows raw integration data per device. The schemas govern the canonical field paths X-Ray maps to — confirming, for example, that `system.crowdstrike.deployed`, `system.crowdstrike.functioning`, `system.crowdstrike.configuredCorrectly`, `system.crowdstrike.required` are the consistent shape across the platform.

## Editing a schema

<Warning>
  **Schemas are tenant-wide.** Editing affects every Studio app, every X-Ray view, and every API consumer. Test in a staging tenant if you have one. Default schemas are sufficient for most customers — only edit if you have specific privacy or extensibility needs.
</Warning>

<Steps>
  <Step title="Click Edit on the schema row">
    Schema editor opens.
  </Step>

  <Step title="Toggle field visibility">
    For each field, decide:

    * **Exposed to AI** (default for most fields)
    * **Hidden from AI** (sensitive fields like serial numbers in some tenants)
    * **Hidden entirely** (rare — affects API output too)
  </Step>

  <Step title="(Optional) add custom fields">
    Custom metadata fields can be declared in the schema so the AI knows they exist. Their values come from integration data or API uploads.
  </Step>

  <Step title="Save">
    Changes propagate within a few minutes.
  </Step>
</Steps>

## The X-RAY button

Clicking **X-RAY** on a schema row opens a JSON view of the schema:

A schema X-Ray view shows the canonical structure — for example, a Device Data schema includes the fields verifiable in the [Devices](/device-management) search bar autocomplete:

* `hostName` (string)
* `os` (enum: Windows / MacOs / Linux)
* `osVersion` (string)
* `lastOnline`, `lastLogin` (time)
* `macAddress`, `privateIp`, `publicIp`
* `location.country`, `location.city`, `location.countryCode`, `location.coordinates`
* `lastUser.email`, `lastUser.name`, `lastUser.department`, `lastUser.jobTitle`
* `metadata.*` — hardware and tenant-specific fields
* `tags` (string array)
* `system.<integration>.{deployed,functioning,configuredCorrectly,required}` (booleans)
* `issues`, `software`, `systems` (nested collections)

For the complete confirmed field list see [Query Syntax Reference](/reference/query-syntax).

This is the same structure the AI Composer sees — useful for understanding what fields are referenceable in prompts and queries.

## Privacy: what to consider hiding

For tenants with strict privacy requirements, consider hiding from the AI:

| Field                    | Why                                                     |
| ------------------------ | ------------------------------------------------------- |
| `lastUser.email`         | PII — full email address                                |
| `lastUser.manager`       | PII chain                                               |
| `metadata.serial_number` | Asset identifier — could enable physical-asset tracking |
| `macAddress`             | Hardware identifier                                     |
| `publicIp`               | Network identifier                                      |

Hiding from the AI doesn't remove the field from queries or X-Ray for human users — it means Studio apps can't generate code that uses these fields. For full field-level hiding from human users too, use [Access Control field-level permissions](/access-control#field-level-hiding).

## Cross-references

<CardGroup cols={3}>
  <Card title="X-Ray" icon="magnifying-glass" href="/x-ray">
    Per-device raw data view
  </Card>

  <Card title="Studio" icon="palette" href="/reporting">
    Uses the schema to power AI generation
  </Card>

  <Card title="Access Control" icon="users-gear" href="/access-control">
    User-facing field hiding
  </Card>
</CardGroup>