Effective May 2025 — supersedes all previous notes
AMLTRIX is an open‑source adversarial‑knowledge framework that remains in Beta. Community feedback and ongoing research drive frequent updates. This document governs all aspects of AMLTRIX versioning; no other standing documents on versioning are required.
1. Beta status and release stream
- Framework releases follow the pattern
1.0‑beta.#(e.g.,1.0‑beta.7). - Each increment—no matter how large or small—is treated as a minor update within the Beta stream; we do not issue separate patch / hot‑fix tags while in Beta.
- When AMLTRIX exits Beta, semantic versioning will switch to the standard major.minor convention (§ 2).
2. Version‑number formats
| Level | Format | Triggers |
|---|---|---|
| Framework (Beta) | 1.0‑beta.# |
Any public release that aggregates object‑level or structural updates. |
| Framework (Post‑Beta) | x.y |
x (major) for architectural or conceptual shifts; y (minor) for incremental improvements. |
| Individual objects (techniques, mitigations, value instruments, actors, products and services, data sources and their relationships) | Default 1.0 |
Increments only if a change materially affects interpretation or operational use (see § 3). |
| Matrix & Tactics | Single shared version (e.g., Matrix v1.1) |
Any addition, merge, or re‑definition of a tactic. |
Retention policy: Older minor Beta releases remain accessible on the version‑history page for a limited period (typically ≥ 6 months) to aid validation and roll‑backs.
3. Object‑versioning policy (May 2025)
All objects default to 1.0 and do not increment unless at least one of the following occurs:
- Tactic reassignment (techniques or sub‑techniques).
- Reclassification that changes the object’s conceptual role.
- Substantive definition rewrite that alters how the object is understood or applied.
Changes that do not trigger a version bump include spelling/grammar fixes, added references, clarifying notes, formatting tweaks, new or reordered relationships.
Deprecations: An object may be flagged Deprecated in any Beta release when consensus indicates it will be removed or replaced. Deprecated objects may be removed in the very next release; a separate data extract—maintained on Github—lists each deprecated object, its replacement (if any), and the date of deprecation.
Backward‑compatibility expectations: We strive to keep object IDs stable throughout Beta. Field names may be added, rearranged, or—if unavoidable—removed. Any such change is highlighted in the release notes.
4. Change management & transparency
- Official version history: https://framework.amltrix.com/version-history provides the authoritative log of all framework releases and object‑level changes.
- GitHub commits: every edit—large or small—is committed individually for full auditability.
- Changelogs: each framework release includes a concise summary of material updates and any deprecations.
5. Institutional best practices
- Track the latest Beta release. Use the highest
1.0‑beta.#tag until AMLTRIX exits Beta. - Note object versions when present. If no version is displayed, assume
1.0. - Review changelogs selectively. Focus on entries that flag object‑version increments, field‑name adjustments, or deprecations that affect your tooling.
- Audit via GitHub or the version‑history page when needed; these are the definitive trails for every modification.
6. Exit from Beta
Leaving Beta will be a consensus decision by the maintainer team and community contributors, informed by overall stability and coverage. Once announced, the framework will advance to 1.0 and adopt the post‑Beta semantic scheme in § 2.
7. Summary
- Releases during Beta are sequential
1.0‑beta.#tags—no patch tags. - Objects start at
1.0; versions change only on material meaning shifts. - Field names can still evolve in Beta; watch changelogs.
- The version‑history page and GitHub commits are your single sources of truth.
In short: Follow the latest
1.0.beta.#, assume objects are1.0unless flagged otherwise, and consult the version‑history page for meaningful shifts.