Changelog: what changes in XICBOT
This is where product changes are recorded: new features, changed defaults, fixed bugs. What you change on your own assistant is not here but in the audit log of your account — with timestamp and the account that triggered it.
A tool that changes without anyone noticing what changed is a tool you cannot trust. This page therefore records how changes come about, which of them are announced and where you can read them. It does not replace the audit log in your account: that one records what happened in your account, this one records what changed in the product.
The record starts with the first release
What gets recorded here
What gets recorded is what is visible or noticeable to the operator of an assistant. Internal rework without effect on operation, answers or quotas does not appear — it would fill the list without answering a question.
New features
What is added, which area it belongs to and whether it has to be enabled or is available immediately.
Changed defaults
When a default behaviour changes, the entry states what applied before, what applies now and how to keep the old behaviour, if that is possible.
Fixed bugs
What did not work, since when it is fixed and whether anything is required on your side for the fix to take effect.
Security and data protection
Changes to access, rights, retention and deletion periods. Anything affecting the data processing agreement is marked separately.
Scope and quotas
Changes to what a package contains. Price changes are additionally stated on the pricing page and are never announced here alone.
Deprecations
What will be removed, from when, and what replaces it. Deprecations appear here before they take effect, not afterwards.
How a change is delivered
Build and verify
Every change is verified against the interface it affects — by measurement, not by looking at it. What cannot be measured counts as unverified.
Deliver
Delivery happens at times of low usage. Changes that may cause an interruption are announced beforehand; the channel for that is described under Status.
Record
After delivery the entry appears here — with date, affected area and a statement of whether anything is required from you.
Roll back when necessary
If a fault shows up after delivery, the change is rolled back rather than patched. The rollback gets an entry too; a history that failures disappear from is not a history.
Every change is verified against the interface it affects — by measurement, not by looking at it. What cannot be measured counts as unverified.
Delivery happens at times of low usage. Changes that may cause an interruption are announced beforehand; the channel for that is described under Status.
After delivery the entry appears here — with date, affected area and a statement of whether anything is required from you.
If a fault shows up after delivery, the change is rolled back rather than patched. The rollback gets an entry too; a history that failures disappear from is not a history.
Your own changes: the audit log in your account
What happens in your account does not belong in a public history. Every change to assistants, sources, tools and approvals is listed under Audit log, with timestamp and the account that triggered it. That is the place for the question why the assistant has been answering differently since yesterday: in the vast majority of cases a source changed, not the product.