Setup & integrations
Data dictionary
The per-Org map from Slate field names to semantic meaning. This is what lets Celia reason about meaning instead of opaque field codes.
- Customer-app route
- /settings/data-dictionary
- Who uses this
- Every authenticated team member.
What it is
Your institution's translation layer. Celia ingests Slate field names verbatim, then looks
them up in this dictionary to know what each one represents. Without entries, Celia falls back
to the field name itself — which is fine for canonical names but useless for custom
SS_* fields.
What you can do here
- Browse all entries alphabetical by field name.
- Add an entry at /settings/data-dictionary/new.
- Bulk import a CSV at /settings/data-dictionary/import.
- Edit a single entry by clicking into it.
Anatomy of an entry
- Field name — exact Slate column name (e.g.,
SS_FAFSA_STATUS). - Label — human-friendly version ("FAFSA submission status").
- Type — text, number, date, boolean, enum.
- Description — what the value represents semantically.
- Allowed values — for enum types, the canonical value set.
Common workflows
Stand up a brand new dictionary
- Export your Slate field schema as CSV.
- Add a Label, Type, and Description column.
- Import via /settings/data-dictionary/import.
Fix a single bad description
- Search for the field name.
- Click into it.
- Edit the Description and save. Celia uses the new text on the next analysis.
Common gotchas
Celia keeps using the field name itself
You haven't added a dictionary entry for that field yet, or the field name in the entry doesn't exactly match the Slate column.
Talk-to-Celia says "I don't know that field"
Same root cause — add a dictionary entry and refresh.