<!--
  Full-page Markdown export (rendered HTML → GFM).
  Source: https://neotoma.io/ur/inspector/schemas
  Generated: 2026-04-27T12:48:34.470Z
-->
# Inspector, Schemas

Neotoma is schema-agnostic at write time but schema-aware at read time. The Schemas section of Inspector is where operators see what types have actually been registered, what fields each one carries, which fields define identity, and how that schema has evolved.

## Schema list

The list at `/schemas` shows every registered `entity_type` with its current schema version, field count, identity rule, and how many entities of that type currently exist. The same numbers back the histogram on the dashboard, but here you can sort by churn, last write, or observation cardinality.

inspector.neotoma.io/schemas

Inspector

Neotoma

Dashboard

Conversations

Turns

Compliance

Activity

Feedback

Entities

Observations

Sources

Relationships

Graph Explorer

Schemas

Timeline

Interpretations

Agents

Agent grants

Settings

Schemas

47 registered entity types

Search…

| Type | Version | Fields | Identity | Entities |
| --- | --- | --- | --- | --- |
| agent\_message | v1.4 | 9 | turn\_key | 4,910 |
| transaction | v0.9 | 12 | schema\_rule | 3,104 |
| contact | v0.6 | 8 | schema\_rule | 2,231 |
| task | v0.4 | 7 | canonical\_name | 1,556 |
| event | v0.3 | 11 | schema\_rule | 902 |
| file\_asset | v0.2 | 6 | schema\_rule | 612 |

Schemas list with type, version, field count, identity rule, and live entity cardinality.

◆

## Schema detail, fields & identity

Click a type to drill into its schema. The detail view shows each field's name, inferred JSON type, whether it's part of the identity rule, when it was first observed, and the example values that produced its inferred type. The identity rule itself,`schema_rule`, `canonical_name`, or `turn_key`, is highlighted because it determines how deduplication works at write time.

inspector.neotoma.io/schemas/transaction

Inspector

Neotoma

Dashboard

Conversations

Turns

Compliance

Activity

Feedback

Entities

Observations

Sources

Relationships

Graph Explorer

Schemas

Timeline

Interpretations

Agents

Agent grants

Settings

transaction

v0.9 · 12 fields · identity\_rule = schema\_rule(amount, merchant, billing\_period)

v0.9Edit fields

| Field | Type | Identity? | First seen | Coverage |
| --- | --- | --- | --- | --- |
| amount | number | identity | v0.1 | 100% |
| merchant | string | identity | v0.1 | 100% |
| billing\_period | string | identity | v0.2 | 98% |
| category | string | \- | v0.3 | 92% |
| currency | string | \- | v0.4 | 100% |
| source\_quote | string | \- | v0.7 | 61% |
| api\_response\_data | object | \- | v0.8 | 44% |

Schema detail: every field, its inferred type, whether it's part of the identity rule, and per-field cardinality.

◆

## Schema evolution

Schemas evolve via `update_schema_incremental`. Adding fields bumps the minor version; removing fields bumps the major version (and removes them from snapshots while preserving the underlying observations). Inspector shows the version history per type with a diff between adjacent versions, so operators can see when a field was introduced, deprecated, or restored.

◆

## Identity rules

Three identity bases are exposed:

-   **schema\_rule**, a tuple of fields uniquely identifies the entity (e.g. `(amount, merchant, billing_period)` for `transaction`).
-   **canonical\_name**, a single human-readable name uniquely identifies the row (common for `contact`, `company`, `place`).
-   **turn\_key**, used for chat bookkeeping: `conversation_message` rows resolve per-turn so multiple observations from the same turn collapse to one entity.

Heuristic-name resolution is also surfaced as a fallback identity basis for entities that didn't match a strict rule; the entity list filter for `identity_basis` uses the same enum.

◆

## Suggested fields

When a write introduces a previously-unseen field, the schema registry records it at low coverage. Inspector flags low-coverage fields so operators can decide to: promote them (formalise into the schema), prune them (remove via `fields_to_remove`), or leave them as ad-hoc metadata. See [REST API](/api) for the schema mutation endpoints.