Our commitment to feature stability and how we manage changes to protect your workflows
We understand that your financial models and workflows depend on consistent, reliable behavior from our platform. This policy explains what stability you can expect and how we communicate changes.
Financial modeling requires predictability. When you build processes around our tools, you need confidence that updates will not unexpectedly alter your results or break established workflows.
The following types of changes are generally considered backward compatible. These changes aim to improve the platform without disrupting existing usage patterns.
Corrections that align outputs with documented behavior.
Faster calculations, reduced latency, or optimized resource usage.
New capabilities that do not alter existing defaults or workflows.
Clarifications, examples, or expanded guidance.
UI improvements that maintain functional equivalence.
Note: While these changes are designed to be non-disruptive, we recommend reviewing release notes to understand what has changed in each update.
Breaking changes are modifications that may require you to update your workflows, review your outputs, or adjust your processes. We treat these changes with care and communicate them clearly.
Modifications that alter how features behave when used with existing settings.
Features or capabilities that are no longer available or have been restructured.
Different results produced from the same data and configuration.
Modifications to export formats, import requirements, or stored data structures.
Settings or preferences that are no longer supported.
Important: We aim to minimize breaking changes, but they are sometimes necessary to improve security, accuracy, or platform capabilities. When breaking changes occur, we provide advance notice based on the feature's maturity level.
Our compatibility commitments vary based on feature maturity. Features progress through stages as they stabilize, and our stability guarantees increase accordingly.
This feature is stable and production-ready. Results can be relied upon for business decisions.
Change Policy: Features deprecated with 90-day notice and migration path.
Enterprise Note: Covered by SLA. Support available through enterprise channels.
This feature is functional and improving. Review results before final decisions.
Change Policy: API and behavior may change. Breaking changes announced 14 days in advance.
Enterprise Note: Best-effort support. Changes communicated 14 days in advance.
This feature is exploratory. Use for investigation only, not for final decisions.
Change Policy: May be modified or removed without notice.
Enterprise Note: Not covered by support agreements. Use at own risk.
See Also: Feature Status for the current maturity level of each feature.
We communicate changes through established channels to ensure you have visibility into platform updates.
Our primary communication channel. All significant changes are documented in our What's New page, including the type of change and affected features.
For production features, breaking changes are communicated in advance where reasonable. Beta features receive shorter notice periods, and experimental features may change without advance notice.
Documentation is updated alongside feature changes to reflect current behavior. The Version History page tracks changes over time for each feature.
While we work to maintain stability, there are steps you can take to ensure smooth operation of your workflows.
We encourage you to review release notes periodically, especially before finalizing critical outputs. This helps you stay informed of changes that may affect your work.
As with any analytical tool, final responsibility for validating results remains with you. We provide the tools; you verify the outputs meet your requirements.
Check the maturity level of features you depend on. Production features offer the strongest stability guarantees; experimental features should not be used for critical decisions.