Drafts, versions and publishing
How a change becomes the published model: draft, validate, review, publish.
There is at most one draft and one published version at a time; earlier published versions are archived (their content is kept, their search index is not).
- Start a draft: a copy of the published version (or, with nothing published, a draft created by an Excel upload or a connector).
- Edit: in the UI, by uploading Excel (replaces the draft when you choose to), or by generating from a connector. Every change is written to the audit log with who and when. Modellers and above edit.
- Validate: references between items resolve, required properties are present, values are from the allowed lists, a restricted field has agent access
none, filter names and check ids are unique per entity, examples have SQL, and the search chunks can be built. SQL in filters and checks that does not run on the connected database is reported as advice, never as a blocker: the model may be written before the database exists. - Review: compare the draft with the published version, item by item.
- Publish (publisher role): validation runs again, then publishing continues in the background: the search index is built and embedded, and only then does the draft become the published version. You can leave the page; the progress shows when you come back. If it fails, the draft stays a draft and the embeddings computed so far are kept. Text that was embedded before is never embedded again.
- Discard drops the draft.
Four-eyes rule (Settings page, off by default): whoever changed a draft cannot publish it; another publisher or admin must.
After a publish, agents' instructions are rebuilt and every tool reads the new version.
Start from zero: an admin can empty the ontology (Settings > Maintenance, type EMPTY to confirm). The current model is first saved as an Excel backup in data/backups (downloadable from the Excel card), then every version is deleted, and optionally the demo database too. Connectors, users, tokens and the activity log stay.