Changelog and Release Notes

This page used to be the place a changelog would live. It is not one, and saying so is more useful than publishing dates nobody can check: Quartyl does not publish version numbers, dated release waves, or a running change history. There is no feed, no release email, and no release-notes screen in the product — the in-app Help page has exactly three tabs, Documentation, Feedback and Support (see the help map), and none of them is a changelog.

So this page answers the practical question instead: how do you find out that something changed, and what does a change cost you?

What does signal a change

Four things in the product tell you something moved. Each is a mechanism, not a announcement:

Signal	What you see	What it means
A capability appears or disappears in the sidebar	A nav item you used to have is gone, or a new one is there	Your plan’s feature set changed. Gated features are hidden, not locked, so absence is the entitlement state.
Login stops at a re-consent step	A consent view before the session is issued	The deployed terms version changed and your stored acceptance is stale. Read it; accept; you are in.
A new column, step or field in the workspace	The wizard, the eight-step pipeline stepper, or the report carries something you have not seen	The application was updated. The manual and in-app docs are the explanation.
A deprecated API response header	X-Deprecated on an API response	That endpoint is scheduled to go. The header carries the human-readable message.

The last one is the only place the platform documents its own change policy in code, and it matters if you built against the API:

• Every endpoint lives under /api/v1/.
• A breaking change does not replace v1. It creates /api/v2/, and the old version stays live alongside it — the policy is a minimum of six months.
• Deprecated routers and routes return the X-Deprecated header automatically, and individually deprecated routes are marked in the OpenAPI schema, so your integration can detect the change rather than meet it at runtime.

That is the whole published contract about versions. Database migrations and internal revisions are not customer-facing and are not listed here.

What a change note covers, when you get one

If a change matters to your workflow, you will be told about it by your own route — the agreement, the onboarding contact, or a support reply — not by this page. When a change is described, classify it yourself before acting:

• New — a capability that did not exist. Ask who can use it (roles) and whether a plan feature gates it, because a feature you cannot see may simply not be on your plan.
• Fixed — a defect repair. Ask what the symptom was, so you can tell whether your archived studies were produced before or after it.
• Breaking — a behavior change that invalidates something you did before: a changed limit, a changed workflow step, a renamed action. This is the only category that asks something of you, and it is the one to confirm in writing.
• Docs — a corrected rule or a new page in this manual. No action, but worth re-reading the page you rely on.

Do not back-date this taxonomy onto a made-up release history. If nobody can tell you when a change shipped, the honest question is whether the difference affects a study you have already signed off — and if it does, the audit trail on that study, not a changelog, is your record of what was true when.

How to find out what changed for you

1. Open the manual page for the capability. Each page states the rules, the limits and the role boundary as they stand today.
2. Check your plan features from the Firm Admin surface, before concluding a capability was removed. See plan features.
3. Read the audit trail on an affected study to establish what the platform did at the time, state transition by state transition.
4. Ask through the Help & Feedback page — the Feedback tab for something product-shaped, the Support card for something engagement-shaped. The Support card’s wording is display configuration, not a service level: see contact support.
5. For anything that changes your obligations — retention, hosting, data processing, report sign-off — go to the agreement, and treat the security page as the engineering view rather than a warranty.