Alpha support boundary
Alpha 1 is Loom's current product-maturity label. It is an evaluation-stage release: you can try the documented commands and features and report defects, but you should expect contracts to change between releases.
This page defines the words Loom uses for current and future behavior. It does not turn every product-page statement into a guarantee. For exact behavior, follow the linked reference or executable evidence.
Claim states
Every behavioral claim belongs to one of four states.
| State | Meaning | Required evidence |
|---|---|---|
| Supported | Present in the current release and intended to work within its documented platform, input, and lifecycle constraints. | Current executable behavior plus a reference, contract, test, or release check that names the scope. |
| Experimental | Present for evaluation, but its interface, output, or compatibility may change or be removed during Alpha. | Evidence that the behavior exists, an explicit Experimental label, and the known limits. |
| Planned | Directional work that is not part of the current executable contract. It has no delivery-date or final-design promise. | A tracking issue or specification. Examples must say that they are not supported in the current release. |
| Unsupported | Absent, rejected by the current executable, or outside the documented contract. | A validation rule, diagnostic, or reference boundary when readers could otherwise mistake it for supported behavior. |
If a claim lacks the evidence required for Supported, do not describe it as supported. Label it Experimental, Planned, or Unsupported as the facts require, or remove it until the evidence exists.
What Alpha 1 does and does not say
Alpha 1 identifies product maturity. It does not, by itself, promise:
- backward compatibility between releases;
- production readiness, uptime, or support response times;
- performance, scale, security-certification, or compliance targets;
- support for an operating system, provider, command, flag, or schema field that the current reference does not list; or
- delivery of anything on the roadmap.
A separate reference or release artifact can make a narrower guarantee. That guarantee must name its version, scope, constraints, and evidence.
Keep the version labels separate
Loom uses several kinds of version label. They answer different questions.
| Label | What it identifies |
|---|---|
| Alpha 1 | The product's current maturity stage. |
The output of loom version | The version string embedded in the CLI build; development builds may report the same value. |
Workflow version: v1 | The accepted workflow syntax family, not a promise of cross-release compatibility. |
Artifact schema_version | The format version of a receipt, manifest, or event contract. Breaking format changes should increment it. |
During Alpha, versioned schemas may evolve and no general backward-compatibility window is guaranteed. Check the reference for the release you are using before building automation around a field or output shape.
Where current behavior is defined
Use the narrowest source that matches your question:
- CLI reference for commands, flags, defaults, and CLI environment settings;
- MCP reference for the server and tool surface;
- Workflow syntax v1 and the workflow schema reference for accepted configuration;
- Contract reference for receipts, manifests, events, and other versioned data; and
- roadmap and tracking pages for direction only, never current support.
When prose and executable evidence disagree, treat the mismatch as a documentation or product defect. Confirm the current release through its help, validation behavior, tests, or versioned contract, and correct the conflicting claim instead of widening support by implication.
Rule for new guarantees
A new present-tense behavioral guarantee must identify:
- its state;
- the release, platform, provider, input, and lifecycle limits that matter; and
- a concrete evidence location, such as executable help, a focused test, a schema or contract source, or a release/CI verification result.
Planned claims need a tracking source and must stay visibly separate from current behavior. Unsupported behavior may be documented to prevent confusion, but a workaround does not make that behavior supported.