Skip to content

Stored data

Orloi writes changelog data to your Postgres database in a dedicated orloi schema.

The stored data falls into two broad groups: core changelog data and AI-derived or analysis-dependent data.

Data categories

Data categoryAlways collected?Example fieldsStored whereSent to AI?Configurable?Retention
Raw eventsYes, for tables in scopetable_id, record_id, actor or source, timestamp, before and after valuesCustomer Postgres, orloi schemaNot sent to AI by default. Used only if explicitly included in a customer-controlled query or workflow.Table and field scopeCustomer-controlled
Compacted eventsYes, after raw capturereadable event text, linked raw event count, affected record contextCustomer Postgres, orloi schemaMay be used for reports and summariesAI and report settingsCustomer-controlled
MetricsOptional or configuredmetric definition, value, time window, provenance linksCustomer Postgres, orloi schemaMay be used in reportsMetric configurationCustomer-controlled
ReportsOptional AI featurereport text, structured report JSON, report period, statusCustomer Postgres, orloi schemaGenerated by configured providerCan disableCustomer-controlled
Schema contextOptional or derivedtable hints, field hints, profile summariesCustomer Postgres, orloi schemaMay be used for interpretationCan disable or exclude scopeCustomer-controlled

What Orloi does not collect

  • Airtable data outside the selected base and configured scope.
  • Tables excluded from capture.
  • Fields excluded from capture.
  • Historical Airtable activity before activation, unless separately imported.
  • Attachment file contents, unless explicitly supported and configured. Attachment field changes may still include metadata such as file names or Airtable-provided attachment references, depending on scope.

Core data

Core data is the deterministic substrate. It is useful even if AI features are disabled.

Raw events

Raw events preserve close-to-source Airtable activity for the selected base and configured scope.

They include the source details needed to reconstruct what changed for in-scope activity: table and field identifiers, record identifiers, timestamps, action/source information where available, and payload details for the change.

Raw events are intentionally detailed. They support audit, debugging, recomputation, search, and future derived layers.

Raw record events can include enough structure to show actor/source, action, time, affected table or record, and field-level before/after values where available.

Compacted events

Compacted events convert raw changes into a more readable history.

This layer is designed to be useful to humans and downstream tools. It can collapse noisy updates, prefer names over opaque IDs where available, summarize long additions or removals, and make database changes read more like business events.

When Orloi has enough schema context, compaction can prefer fields that appear business-important for a table. This helps preserve useful values before long events are shortened.

Metric definitions and values

Orloi can persist metric definitions and computed metric values.

Examples include new records, completed items, reopened items, stalled items, handoffs, activity by source, and time-windowed counts. Metric values may keep provenance links back to raw events while those raw events remain in hot storage.

Metric comparisons may include baseline context when enough history exists. Early or sparse history should be treated carefully rather than forcing confident anomaly judgments.

Dashboard and process data

Orloi may persist dashboard-facing summaries such as activity-source counts, today metrics, process facts, process variants, alerts, and signals.

These are derived from the changelog and are intended to make the default dashboard fast and useful without replacing the canonical raw history.

AI-derived or AI-dependent data

AI-derived data is generated from compacted operational context, schema context, metric context, and report bundles.

Reports

Daily and weekly reports summarize what happened, what moved, what stalled, and what may need attention.

Reports are stored in Postgres so they can be viewed later, emailed, inspected from the dashboard, or used as context for future analysis.

Report inputs can include compacted events plus compact event context: useful display fields for related records, record references, and links. This helps reports explain terse events without sending broad raw base dumps.

Company and schema context

Orloi may generate company profiles, schema intelligence, and context summaries that help interpret future activity.

These artifacts help the system understand what tables, fields, records, workflows, and repeated patterns appear to mean for the business.

Automation and process suggestions

Orloi may store AI-assisted mappings or process summaries that identify repeated manual work, bottlenecks, handoffs, or automation opportunities.

Treat these outputs as interpretation on top of deterministic history, not as the canonical source of truth.

What Orloi does not modify

Orloi installs and manages its own objects in the orloi schema. It does not modify your existing application tables.

Orloi does not write back to Airtable.