Data model

Scribe stores identity data as entries. Each entry has a type, identifiers, attributes, and a history of changes. See Architecture for how these fit into the sync and query pipeline. Click any element below to jump to its reference section.

Every entry can be referenced by four formats. All channels accept all formats.

GlobalId is the recommended default. It’s URL-safe (no escaping needed), stable (assigned once, never changes), and fast (the entry type is encoded in the ID, so lookups skip type resolution). The canonical attribute name is entryID, with id as a convenience alias. Treat it as an opaque string.

Entries carry three categories of attributes: user data synced from the source directory, operational metadata managed by Scribe, and virtual attributes computed at query time.

Every entry carries metadata alongside user-defined data. Request them with the + directive (REST: ?fields=+, LDAP: add + to the attribute list) or by name.

Responses always use canonical names, even when you request an alias. Both forms work in filters and projections.

Two attributes give shorter alternatives to the full DN:

• entryName — the name portion. For cn=John Doe,ou=users,dc=example,dc=com, entryName is John Doe. Uses an indexed SQL function for fast lookups.
• entryRDN — the path relative to the type’s configured base. For the same entry under base ou=users,dc=example,dc=com, entryRDN is cn=John Doe.

Both support case-insensitive filtering, sorting, and projection across all channels.

Some attributes are computed at query time rather than stored. The classic example is memberOf, which finds all groups containing a user without storing membership on the user entry.

Virtual attributes are configured per transcribe. See Transcribes configuration for the full syntax.

An entry type groups directory entries of the same kind — users, groups, devices. Each type maps to a transcribe that defines what to sync (base DN, filter, scope, attributes, indexes).

See Architecture > Transcribes for how entry types work in the sync pipeline.

Every change Scribe detects produces an immutable event:

Events are append-only. Each has a unique position (commit + index) and a timestamp. The entries table is a materialized view derived from these events — nothing is ever updated or deleted in the event log. This is what makes point-in-time queries and full audit history possible.

See Architecture > Events for how change detection works.

MODIFY events provide three representations of the change. All use delta semantics (what changed, not the full state):

data {
  ... on ModifyData {
    diff { attribute operation value }
    patch { operation path value }
    merge { attribute values }
  }
}

All three formats are available in the GraphQL and REST channels.

Time-based parameters (at, since, until, range) accept flexible formats: ISO timestamps, durations, relative expressions (now-1h), and natural language (yesterday, last 3 days). See Filters > Temporal references for the complete format table.