What versions independently
The savvy-cli workspace tracks its own release history in CHANGELOG.md, following Keep a Changelog conventions, alongside a Cargo workspace version (0.6.0 at last sync). Independently of that release cadence:
- Each JSON Schema in
seceng-scan-content/schemas/carries its own$idand dialect (see the schema reference). - The capability registry uses
seceng.capability.registry.v1as its own schema version, separate from the server release. - The generated OpenAPI document (
packages/savvy-sdk/openapi.json) is regenerated per build viacargo run -p savvy-server -- --export-openapi.
Capability lifecycle, the real compatibility signal
Every capability in engines/seceng-engine/src/capabilities.rs declares a lifecycle stage. This is the signal to actually build integration decisions around, not a single product-wide version number:
| Stage | What it means for you |
|---|---|
| Experimental | Contract may change without a deprecation notice. Do not pin production automation to it. |
| Preview | Stabilizing; breaking changes are possible but less likely and should come with notes. |
| Stable | Safe to depend on for production integrations. |
| Deprecated | Plan a migration; a replacement capability should be named. |
See the current per-capability lifecycle values in the generated capabilities reference.
Partner policy
- Pin the specific engine/server build you validated against.
- Check the capability lifecycle for anything you depend on before every upgrade.
- Verify checksums on any release artifact you consume.
- Re-run your golden fixture and error/timeout handling after every upgrade, not only after major ones.
- Preserve a rollback path to your last-validated build.
Compatibility
Partners should ignore unknown optional fields in structured outputs and validate the declared schema version rather than assuming a fixed shape. SecEng's contracts (including the partner-adapter contracts in commercial/partner-adapters/contracts/) are explicitly pre-1.0: "breaking changes require a schema-version change; compatible additions should prefer optional fields or extensions."