@cynodia/axiom 0.14.0-alpha.1 → 0.14.0-alpha.2

package/README.md

@@ -33,7 +33,7 @@ Shorter forms of the same routing: [`AGENTS.md`](AGENTS.md) and [`llms.txt`](llm
 at this package's root.
 
 **Status: experimental / alpha.** The API may change between alpha releases. The
-documentation in `docs/` describes this exact version, `0.14.0-alpha.1`.
+documentation in `docs/` describes this exact version, `0.14.0-alpha.2`.
 
 ## Installation
 
@@ -47,7 +47,7 @@ Every release of this project is a pre-release and npm's `latest` tag points at
 plain command above installs the current version. **There is no `alpha` dist-tag** — the tag
 was removed once it stopped tracking releases, and `npm install @cynodia/axiom@alpha` now
 fails with a 404. Pin the exact version instead when one is needed:
-`npm install @cynodia/axiom@0.14.0-alpha.1`.
+`npm install @cynodia/axiom@0.14.0-alpha.2`.
 
 These are ES modules compiled to ES2022; import them with `import`, not `require`. There is
 no published Axiom CLI. `@cynodia/axiom-server`'s SQLite persistence adapter additionally

package/docs/ACTIONS_TRANSACTIONS.md

@@ -1,6 +1,6 @@
 # Actions and transactions
 
-Axiom 0.14.0-alpha.1. An action is behavior expressed as data, executed as a transaction.
+Axiom 0.14.0-alpha.2. An action is behavior expressed as data, executed as a transaction.
 
 ```ts
 {

package/docs/AGENT_API.md

@@ -1,6 +1,6 @@
 # Agent API
 
-Axiom 0.14.0-alpha.1. The machine-facing interface. Agents query semantics and apply
+Axiom 0.14.0-alpha.2. The machine-facing interface. Agents query semantics and apply
 structural transformations; they never edit generated code.
 
 ```ts

package/docs/AGENT_REFERENCE.md

@@ -1,6 +1,6 @@
 # Agent reference
 
-Axiom 0.14.0-alpha.1. Compressed operational contract. Read this plus the `.d.ts`
+Axiom 0.14.0-alpha.2. Compressed operational contract. Read this plus the `.d.ts`
 declarations before authoring or modifying an Axiom application.
 
 Formal guarantees: [`SEMANTIC_CONTRACT.md`](SEMANTIC_CONTRACT.md). Mistakes that compile:
@@ -1181,12 +1181,28 @@ Multi-authority: leaderless. Any compatible authority advances any eligible inst
 per-instance lease+fence (reused 0.12 `CoordinationProvider`); stale owner refused. Startup
 discovers runnable / retry-due / timer-due / recoverably-waiting instances and advances them
 — the application does **not** scan stuck workflows, call `resumeWorkflow`, or re-register
-timers/waits. Same logical outcome at 1 or N authorities. Incompatible build refuses to
-advance an instance (fail-closed).
+timers/waits. Same logical outcome at 1 or N authorities.
+
+Compatibility (safety boundary, not deployment metadata): an instance durably records the
+`AuthorityCompatibilityKey` at creation. `semanticFingerprint` covers `WorkflowDef`
+executable meaning — **changing a step's `action` / `event` target, argument or `where`
+expression, `retry` policy, `timer` duration, `branch` predicate, `complete`/`fail` output,
+or any control-flow edge (`next` / `then` / `else` / `onError` / `onTimeout` / `entry`), or
+the body of a referenced `ActionDef` / `EventDef`, makes existing in-flight instances
+incompatible with the new build.** An incompatible authority fails closed *before* any
+semantic step — no transition, no `ActionDef` invoke, no event/timer/branch, no
+`instanceRevision` advance — and leaves the instance for a compatible authority; it is never
+auto-failed or auto-cancelled, and `cancelWorkflow` from an incompatible build is refused.
+Presentation-only changes (`name` / `description` / `label`) and step declaration order are
+**not** semantic. A semantically identical fresh process recovers instances normally. There
+is no workflow instance migration in 0.14. Structurally invalid workflow IR is refused at
+`createAxiomServer` (`WorkflowIRError`); a malformed step reaches `validateGraph` as a
+`WORKFLOW_INVALID_STEP` diagnostic, never a native error.
 
 Inspection: `server.getWorkflow(instanceId)` / `inspectWorkflows(limit)` — `status`,
 `currentStepId`, `activationId`, `attempt`, `waitingReason`, `nextEligibleAt`,
-`instanceRevision`, `failure`, `output` (no secrets). `server.workflowHistory(instanceId)`
+`instanceRevision`, `failure`, `output`, `compatible` /
+`incompatibleReason: 'incompatible-build'` (no secrets). `server.workflowHistory(instanceId)`
 — the durable transition log. `AgentAPI.analyzeWorkflow(workflowId)` — static: inputs, steps
 + edges, action/event dependencies, terminal outcomes, acyclicity, possible wait reasons.
 

package/docs/ANTI_PATTERNS.md

@@ -1,6 +1,6 @@
 # Anti-patterns
 
-Axiom 0.14.0-alpha.1. Each of these compiles. Each is wrong. Each is followed by the correct
+Axiom 0.14.0-alpha.2. Each of these compiles. Each is wrong. Each is followed by the correct
 alternative.
 
 ## 1. Field names as entity runtime keys
@@ -1046,3 +1046,51 @@ Why wrong: workflow execution is leaderless — any compatible authority advance
 instance under a fenced per-instance lease. Recovery discovery is bounded and indexed and
 runs on startup automatically. Reading status is safe through any authority. The application
 writes none of this.
+
+## 78. Treating matching ids, or a matching Server IR version, as workflow compatibility
+
+```ts
+// WRONG — every one of these can be true while the executable meaning has changed.
+if (a.workflowId === b.workflowId && sameStepIds(a, b)) continueUnderNewBuild();
+if (a.contract === 'axiom.server.v8' && b.contract === 'axiom.server.v8') safe();
+if (a.packageVersion === b.packageVersion) safe();
+```
+
+Why wrong: Phase 22 proved a workflow's meaning can change while `workflowId`, every step id
+and the active step id stay identical — a different `action` / `event` target, a different
+`branch` predicate, a different `timer` duration, a rewired `next` edge. IR-version
+compatibility only means both runtimes understand the *vocabulary*; it says nothing about
+whether two graphs contain equivalent executable semantics, and neither does the package
+version string. The only authority is the executable `semanticFingerprint`, which now covers
+`WorkflowDef`. Keep distinct: IR protocol compatibility, graph semantic compatibility,
+workflow instance compatibility.
+
+## 79. Continuing an in-flight workflow under changed executable semantics
+
+```ts
+// WRONG — reinterpreting durable meaning under a new definition.
+const inst = load(id);                       // created under build A
+replayHistory(inst, buildB.workflowDef);     // "catch up" under B
+advance(inst, buildB.workflowDef);           // B chooses B's branch / event / timer
+```
+
+Why wrong: a durable workflow instance is bound to the semantics it was created and advanced
+under. An authority whose graph changes the executable meaning must **fail closed** — leave
+the instance untouched for a compatible authority — not replay its history under the new
+definition, not pick the new branch, not match the new event, not recompute the new timer,
+and not "find the closest step" for a renamed one. There is no workflow instance migration
+in 0.14. This is framework-owned: the application does not route by build, keep a
+compatibility registry, or migrate instances by hand.
+
+## 80. Hashing workflow presentation metadata to make mixed-build checks stricter
+
+```ts
+// WRONG — an over-tight fingerprint breaks rolling deploys for no safety gain.
+const key = sha256(JSON.stringify(workflowDef));  // includes name / description / step order
+```
+
+Why wrong: a compatibility check that fires on a `description` edit or a reordered (but
+edge-identical) step list is a defect too — it strands instances that a semantically
+identical authority could safely resume. `semanticFingerprint` deliberately strips
+`name` / `description` / `label` and is independent of step declaration order. Fingerprint
+*meaning*, not bytes.

package/docs/AUTHORITY.md

@@ -1,6 +1,6 @@
 # Authority
 
-Axiom 0.14.0-alpha.1. How an application crosses the trust boundary.
+Axiom 0.14.0-alpha.2. How an application crosses the trust boundary.
 
 Until 0.5.x an Axiom application executed locally. 0.6 adds an **authority**: a generic
 runtime that owns state, decides mutations and persists them. The same semantic graph

package/docs/CONSTRAINTS.md

@@ -1,6 +1,6 @@
 # Constraints
 
-Axiom 0.14.0-alpha.1. Two constructs, answering different questions. They are not
+Axiom 0.14.0-alpha.2. Two constructs, answering different questions. They are not
 interchangeable.
 
 | | Question | Sees |

package/docs/DISTRIBUTED_AUTHORITY.md

@@ -1,6 +1,6 @@
 # Distributed authority
 
-*This document describes Axiom `0.14.0-alpha.1`.*
+*This document describes Axiom `0.14.0-alpha.2`.*
 
 The authoritative runtime (`docs/AUTHORITY.md`) may run as **more than one process at the
 same time**, over one shared persistence provider, without any change to the
@@ -294,19 +294,31 @@ An authority's **compatibility key** is four fields:
 - `schemaVersion` / `schemaFingerprint` — the 0.11 persistence-relevant identity. A schema
   mismatch is already fatal per 0.11 migration safety.
 - `serverContract` — the Server IR contract the document declares.
-- `semanticFingerprint` — a **new**, versioned, deterministic hash over the *executable
-  server-side meaning*: action bodies, guards and operations, integration operation
-  definitions, triggers, events, subscription policy, read-policy predicates, query
-  semantics, expression definitions, constraints. It **excludes** everything a rename
-  touches — names, descriptions, labels, free-form metadata, all UI / routes / themes /
-  presentation, and declaration order. It is distinct from `schemaFingerprint`, which
-  deliberately excludes executable meaning: two graphs whose actions do entirely different
-  things but store the same shapes have the same `schemaFingerprint` and different
+- `semanticFingerprint` — a versioned, deterministic hash over the *executable server-side
+  meaning* of **every** executable graph kind (`core`'s single `EXECUTABLE_KINDS` list):
+  action bodies, guards and operations, integration operation definitions, triggers, events,
+  subscription policy, read-policy predicates, query semantics, expression definitions,
+  constraints, storage authorization, relationships, **and `WorkflowDef` executable meaning**
+  — a workflow's inputs / bindings / entry, and every step's kind, control-flow edges and
+  step-specific semantics (the `ActionDef` / `EventDef` it targets and, transitively, those
+  bodies; argument / `where` / `bind` / `when` / output expressions; `retry` policy; `timer`
+  duration). The authority-side projection derives from the same `EXECUTABLE_KINDS` list as
+  the graph-level `semanticFingerprint`, so a future graph primitive cannot alter executable
+  meaning yet escape authority compatibility. It **excludes** everything a rename touches —
+  names, descriptions, labels, free-form metadata, all UI / routes / themes / presentation,
+  and declaration order (workflow steps included). It is distinct from `schemaFingerprint`,
+  which deliberately excludes executable meaning: two graphs whose actions do entirely
+  different things but store the same shapes have the same `schemaFingerprint` and different
   `semanticFingerprint`s.
 
-Durable work records the compatibility key of the build that created it. An authority whose
-key differs **refuses to claim** that work (`INCOMPATIBLE_AUTHORITY` / the item is simply
-not claimed and stays visible as incompatible). A compatible authority runs it. During a
+Durable work — and every **durable workflow instance** — records the compatibility key of
+the build that created it. An authority whose key differs **refuses to claim** that work
+(`INCOMPATIBLE_AUTHORITY` / the item is simply not claimed and stays visible as
+incompatible). For a workflow instance the refusal is checked before *any* semantic step
+(action invocation, event match, timer fire, branch, retry, terminal transition, or a
+cancellation that would transition it); the instance is left untouched for a compatible
+authority to resume — never auto-failed or auto-cancelled. A compatible authority — topology
+and process identity aside — runs it. During a
 schema migration, incompatible workers stop claiming new work, ordinary serving is refused
 per 0.11, the migration completes, and compatible new authorities resume — migration
 ownership stays host-controlled and separate from ordinary distributed-work ownership; there

package/docs/EFFECTS.md

@@ -1,6 +1,6 @@
 # Effects
 
-Axiom 0.14.0-alpha.1. External effects are not rollback-capable state mutations. This file
+Axiom 0.14.0-alpha.2. External effects are not rollback-capable state mutations. This file
 is the delivery model; [`AUTHORITY.md`](AUTHORITY.md#external-effects) is the load-bearing
 statement of why, and [`INTEGRATIONS.md`](INTEGRATIONS.md) is the operation vocabulary this
 builds on.

package/docs/EVENTS.md

@@ -1,6 +1,6 @@
 # Events
 
-Axiom 0.14.0-alpha.1. An event is a typed fact — something that happened — never work
+Axiom 0.14.0-alpha.2. An event is a typed fact — something that happened — never work
 itself. [`AUTHORITY.md`](AUTHORITY.md#external-events) is the load-bearing statement;
 this file is the vocabulary and the webhook delivery mechanism. A **subscription** is the
 other way an external fact becomes an `EventDef` payload — see

package/docs/EXPRESSIONS.md

@@ -1,6 +1,6 @@
 # Expressions
 
-Axiom 0.14.0-alpha.1. An expression describes **what value is computed**. It is a tree of
+Axiom 0.14.0-alpha.2. An expression describes **what value is computed**. It is a tree of
 plain data, never source text and never a callback. Evaluation is pure: an expression MUST
 NOT change state.
 

package/docs/GRAPH_MODEL.md

@@ -1,6 +1,6 @@
 # Graph model
 
-Axiom 0.14.0-alpha.1. The `ApplicationGraph` is the authoritative representation of an
+Axiom 0.14.0-alpha.2. The `ApplicationGraph` is the authoritative representation of an
 application. Everything else — the IR, the page, the DOM — is derived from it and is never
 edited.
 

package/docs/INTEGRATIONS.md

@@ -1,6 +1,6 @@
 # Integrations
 
-Axiom 0.14.0-alpha.1. How an application declares and calls an external system, without
+Axiom 0.14.0-alpha.2. How an application declares and calls an external system, without
 embedding a transport, an SDK or a secret in the graph. The authority boundary this
 depends on is [`AUTHORITY.md`](AUTHORITY.md#external-systems); this file is the vocabulary.
 

package/docs/LIVE_QUERIES.md

@@ -1,6 +1,6 @@
 # Realtime — live canonical queries
 
-Axiom 0.14.0-alpha.1. The operational contract for **observing a `QueryDef` result over
+Axiom 0.14.0-alpha.2. The operational contract for **observing a `QueryDef` result over
 time**: subscribe once, receive an initial coherent result, then receive canonical changes
 as authoritative committed state moves — through any compatible authority, across
 reconnects. `axiom.server.v7` (0.13 adds no IR vocabulary).

package/docs/LOCATIONS.md

@@ -1,6 +1,6 @@
 # Locations
 
-Axiom 0.14.0-alpha.1.
+Axiom 0.14.0-alpha.2.
 
 ```text
 Expression = a value

package/docs/MIGRATIONS.md

@@ -1,6 +1,6 @@
 # Schema evolution & semantic migrations
 
-Axiom 0.14.0-alpha.1. The operational contract for evolving a deployed application's
+Axiom 0.14.0-alpha.2. The operational contract for evolving a deployed application's
 semantic model and its persisted canonical data over time — adding a required field,
 splitting one field into two, removing an obsolete one, migrating millions of
 provider-backed rows — **without** an application-authored SQL migration, an ORM migration,

package/docs/PRESENTATION.md

@@ -1,6 +1,6 @@
 # Presentation
 
-Axiom 0.14.0-alpha.1. Presentation is **semantic UX intent**, expressed as data on a UI
+Axiom 0.14.0-alpha.2. Presentation is **semantic UX intent**, expressed as data on a UI
 node. It names roles, tokens and device classes. It never names a colour, a length, a media
 query or a CSS property.
 

package/docs/QUERIES.md

@@ -1,6 +1,6 @@
 # Semantic data access & the query layer
 
-Axiom 0.14.0-alpha.1. The operational contract for demand-driven reads over authoritative
+Axiom 0.14.0-alpha.2. The operational contract for demand-driven reads over authoritative
 data that is too large to materialize as a `StateDef` — 500,000 orders, 5,000,000 order
 lines, years of audit rows. `axiom.server.v6`.
 

package/docs/RUNTIME.md

@@ -1,6 +1,6 @@
 # Runtime
 
-Axiom 0.14.0-alpha.1. The runtime executes an `ApplicationIR`. It is domain-independent: it
+Axiom 0.14.0-alpha.2. The runtime executes an `ApplicationIR`. It is domain-independent: it
 contains no knowledge of any application.
 
 ## Constructing

package/docs/SEMANTIC_CONTRACT.md

@@ -1,6 +1,6 @@
 # Semantic contract
 
-Axiom 0.14.0-alpha.1. Runtime guarantees, stated formally. This file defines behavior; it
+Axiom 0.14.0-alpha.2. Runtime guarantees, stated formally. This file defines behavior; it
 does not teach. Where this file and any specification in `../specs/` disagree, this file
 describes the implementation and is authoritative.
 

package/docs/STATE.md

@@ -1,6 +1,6 @@
 # State
 
-Axiom 0.14.0-alpha.1. A `StateDef` is a named application value: stored, or computed from
+Axiom 0.14.0-alpha.2. A `StateDef` is a named application value: stored, or computed from
 other state.
 
 ```ts

package/docs/STORAGE.md

@@ -1,6 +1,6 @@
 # Storage and blobs
 
-Axiom 0.14.0-alpha.1. How an application stores, references, serves and deletes binary data —
+Axiom 0.14.0-alpha.2. How an application stores, references, serves and deletes binary data —
 an attachment, a document, a photograph, a diagnostic log — with no filesystem path, no
 upload route and no download route anywhere in it.
 

package/docs/SUBSCRIPTIONS.md

@@ -1,6 +1,6 @@
 # Subscriptions
 
-Axiom 0.14.0-alpha.1. How an application receives a stream of external events — an MQTT
+Axiom 0.14.0-alpha.2. How an application receives a stream of external events — an MQTT
 topic, a WebSocket feed, a queue consumer, a filesystem watcher, a serial port — without a
 client, a socket or a callback anywhere in the graph.
 

package/docs/TRIGGERS.md

@@ -1,6 +1,6 @@
 # Triggers
 
-Axiom 0.14.0-alpha.1. A `TriggerDef` says **when** an action should be invoked, without
+Axiom 0.14.0-alpha.2. A `TriggerDef` says **when** an action should be invoked, without
 embedding callback code. `docs/AUTHORITY.md`
 [§ Triggers](AUTHORITY.md#triggers) is the load-bearing statement of the execution model;
 this file is the vocabulary.

package/docs/UI.md

@@ -1,6 +1,6 @@
 # UI
 
-Axiom 0.14.0-alpha.1. Eleven semantic UI node kinds describe **what exists and what it does**.
+Axiom 0.14.0-alpha.2. Eleven semantic UI node kinds describe **what exists and what it does**.
 How it looks is [presentation](PRESENTATION.md).
 
 All eleven share `UIBase`:

package/docs/VALIDATION.md

@@ -1,6 +1,6 @@
 # Validation
 
-Axiom 0.14.0-alpha.1. Validation is authoring-time structural checking. It is not the same
+Axiom 0.14.0-alpha.2. Validation is authoring-time structural checking. It is not the same
 as runtime constraint evaluation — see [`CONSTRAINTS.md`](CONSTRAINTS.md) for the four
 layers of correctness.
 
@@ -202,7 +202,7 @@ to `axiom.server.v8` or executed. Every failure is a structured diagnostic — n
 | `WORKFLOW_ENTRY_NOT_FOUND` | `WorkflowDef.entry` does not name a step of that workflow. |
 | `WORKFLOW_STEP_NOT_FOUND` | A control-flow edge (`next` / `onError` / `then` / `else` / `onTimeout`) or a binding's `producedBy` names a step that does not exist. |
 | `WORKFLOW_DUPLICATE_STEP_ID` | Two steps in one workflow share an id, or a step id collides with a graph node id. |
-| `WORKFLOW_INVALID_STEP` | A step with no id, or a `type` outside the six (`action`, `wait-event`, `timer`, `branch`, `complete`, `fail`). |
+| `WORKFLOW_INVALID_STEP` | A step with no id, a non-object step (`null`, a string, an array), or a `type` outside the six (`action`, `wait-event`, `timer`, `branch`, `complete`, `fail`). Any malformed step shape produces this diagnostic — never a native `TypeError` (spec14pt3 F1). |
 | `WORKFLOW_CYCLE_NOT_ALLOWED` | The workflow control-flow graph contains a cycle. Retries are runtime policy, not graph edges. |
 | `WORKFLOW_ACTION_NOT_FOUND` | An `action` step references an `action` node that does not exist. |
 | `WORKFLOW_EVENT_NOT_FOUND` | A `wait-event` step references an `event` node that does not exist. |

package/docs/WORKFLOWS.md

@@ -1,6 +1,6 @@
 # Durable workflows
 
-Axiom 0.14.0-alpha.1. The operational contract for **long-running semantic computations with
+Axiom 0.14.0-alpha.2. The operational contract for **long-running semantic computations with
 a durable control position** — orchestration that survives process death, authority
 failover, retries, timer delivery, event delivery and ordinary distributed contention
 without application-owned infrastructure. `axiom.server.v8`.
@@ -211,14 +211,45 @@ logical outcome.
 
 ## Compatibility
 
-A running instance stores the `AuthorityCompatibilityKey` (`{ schemaVersion,
-schemaFingerprint, serverContract, semanticFingerprint }`) at start. An authority whose key
-differs **refuses to advance it**, fail-closed — the same mechanism the distributed work
-store applies. A presentation-only graph change moves no fingerprint and stays compatible. A
-semantic workflow change makes new instances incompatible with old authorities; old
-instances are not auto-migrated — they run to completion on a compatible authority or are
-surfaced as stranded. A graph with **no** `WorkflowDef` compiles to the byte-identical
-`axiom.server.v1`–`v7` document it always did, and its `semanticFingerprint` is unchanged.
+> Durable workflow instances are bound to **executable semantic compatibility**. An
+> authority whose graph changes the executable meaning of the workflow must fail closed
+> rather than continue the instance under changed semantics.
+
+A running instance durably stores the `AuthorityCompatibilityKey` (`{ schemaVersion,
+schemaFingerprint, serverContract, semanticFingerprint }`) at creation, in the same
+transaction that creates it. Before **any** semantic step — action invocation, event match,
+timer fire, branch evaluation, retry, `complete` / `fail`, or a cancellation that would
+transition the instance — an authority checks that key against its own. If it differs the
+authority **refuses**: no `instanceRevision` advance, no `ActionDef` invocation, no event or
+timer transition, no binding write. The instance is left exactly as it stands for a
+compatible authority to resume; incompatibility is an execution-environment condition, never
+an automatic `failed` or `cancelled`.
+
+`semanticFingerprint` covers `WorkflowDef` executable meaning: `inputs`, `bindings`, `entry`,
+every step's kind and control-flow edges, and step-specific semantics — the `ActionDef` /
+`EventDef` a step targets (and, transitively, those definitions' own bodies), an `action`
+step's argument expressions / `retry` policy, a `wait-event` step's `where` / `bind` /
+`timeout`, a `timer` step's `after` / `at`, a `branch` step's `when` and edges, and
+`complete` / `fail` output/error expressions. It is computed from `core`'s single
+`EXECUTABLE_KINDS` list, so it and the authority-compatibility fingerprint cannot disagree.
+
+- **Semantically incompatible workflow definitions fail closed.** Changing any of the above
+  while an instance is in flight strands that instance on incompatible authorities.
+- **Presentation-only changes stay compatible.** `name`, `description`, `label` — anywhere
+  in the workflow — move no fingerprint. Step *declaration order* is not semantic either
+  (control flow is by explicit edges).
+- **Authority / process identity is irrelevant.** A fresh process running a semantically
+  identical build recovers the instance normally; topology and authority count may change
+  freely.
+- **Workflow migration across incompatible definitions is not provided in 0.14.** An old
+  instance waits for a compatible authority; there is no instance upgrader, step remapping
+  or binding migration, and none is inferred ("closest step" recovery never happens).
+- A graph with **no** `WorkflowDef` compiles to the byte-identical `axiom.server.v1`–`v7`
+  document it always did, and its `semanticFingerprint` / `schemaFingerprint` are unchanged.
+- Pre-`0.14.0-alpha.2` instances carry a compatibility key computed before `WorkflowDef`
+  participated; a corrected authority treats them as incompatible and fails closed (these
+  are pre-freeze alpha releases — silent reinterpretation is the only unacceptable
+  outcome).
 
 ---
 
@@ -226,8 +257,11 @@ surfaced as stranded. A graph with **no** `WorkflowDef` compiles to the byte-ide
 
 `server.getWorkflow(instanceId)` / `server.inspectWorkflows(limit)` return the semantic
 fields — `status`, `currentStepId`, `activationId`, `attempt`, `waitingReason`,
-`nextEligibleAt`, `createdAt`, `updatedAt`, `instanceRevision`, `failure`, `output` — and
-**no** secrets (no HMAC keys, database paths, raw SQL, credentials).
+`nextEligibleAt`, `createdAt`, `updatedAt`, `instanceRevision`, `failure`, `output`,
+`compatible` (whether *this* build may advance it; `incompatibleReason: 'incompatible-build'`
+when not) — and **no** secrets (no HMAC keys, database paths, raw SQL, credentials).
+Read-only inspection of an incompatible instance stays available so an operator can see
+*why* it is not progressing rather than finding it silently stuck.
 `server.workflowHistory(instanceId)` is the durable semantic transition log (`started`,
 `step-activated`, `step-succeeded`, `step-failed`, `retry-scheduled`, `event-matched`,
 `timer-fired`, `timeout-fired`, `branch-chosen`, `completed`, `failed`, `cancelled`) — a
@@ -280,3 +314,8 @@ the fixtures from the contract alone.
   is retained past its `sinceEventSeq` is an implementation-owned retention concern.
 - `WorkflowStore` bounded retention of terminal instances and history is
   implementation-owned; an active workflow never expires.
+- Structurally invalid workflow IR (unknown step kind, dangling edge, malformed
+  timer/terminal, missing entry) is refused at authority admission — `createAxiomServer`
+  throws `WorkflowIRError` rather than starting with a workflow it cannot execute. Malformed
+  step input to `validateGraph` produces a `WORKFLOW_INVALID_STEP` diagnostic, never a
+  native error.

package/llms.txt

@@ -1,6 +1,6 @@
 # Axiom
 
-> AI-native semantic application framework, version 0.14.0-alpha.1. An Axiom application is a
+> AI-native semantic application framework, version 0.14.0-alpha.2. An Axiom application is a
 > typed semantic graph — state, behavior, constraints, UI structure, presentation and
 > authority as structured data — executed by generic runtimes. The JavaScript, HTML and CSS
 > that reach a browser are compiler output and are never authored or edited. The primary

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cynodia/axiom",
-  "version": "0.14.0-alpha.1",
+  "version": "0.14.0-alpha.2",
   "description": "AI-native semantic web application framework.",
   "license": "MIT",
   "author": "AskTech AS",
@@ -34,10 +34,10 @@
     }
   },
   "dependencies": {
-    "@cynodia/axiom-core": "0.14.0-alpha.1",
-    "@cynodia/axiom-runtime": "0.14.0-alpha.1",
-    "@cynodia/axiom-compiler": "0.14.0-alpha.1",
-    "@cynodia/axiom-agent-api": "0.14.0-alpha.1"
+    "@cynodia/axiom-core": "0.14.0-alpha.2",
+    "@cynodia/axiom-runtime": "0.14.0-alpha.2",
+    "@cynodia/axiom-compiler": "0.14.0-alpha.2",
+    "@cynodia/axiom-agent-api": "0.14.0-alpha.2"
   },
   "scripts": {
     "build": "tsc -b tsconfig.json"