@cynodia/axiom 0.8.0-alpha.1 → 0.8.2-alpha.1

package/docs/ACTIONS_TRANSACTIONS.md

@@ -1,6 +1,6 @@
 # Actions and transactions
 
-Axiom 0.8.0-alpha.1. An action is behavior expressed as data, executed as a transaction.
+Axiom 0.8.2-alpha.1. 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.8.0-alpha.1. The machine-facing interface. Agents query semantics and apply
+Axiom 0.8.2-alpha.1. 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.8.0-alpha.1. Compressed operational contract. Read this plus the `.d.ts`
+Axiom 0.8.2-alpha.1. 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:
@@ -31,7 +31,7 @@ One canonical term per concept. These are not interchangeable.
 ## Graph construction
 
 ```ts
-const graph = new ApplicationGraph(id, name);      // version defaults to '0.8.0'
+const graph = new ApplicationGraph(id, name);      // version defaults to '0.8.2'
 graph.addNode<StateDef>({ id, kind: 'state', ... }); // returns NodeId; throws if id exists
 graph.getNode<StateDef>(id);                        // deep clone, or undefined
 graph.updateNode(node);                             // write a modified node back
@@ -496,6 +496,22 @@ if (!result.ok) {
 warnings never make a graph invalid. 72 codes in `VALIDATION_CODES`, grouped in
 [`VALIDATION.md`](VALIDATION.md).
 
+**`validateGraph(graph)` with no options is target-neutral by design** (spec 8.2 §2-4): a
+graph is never rejected for a renderer or trigger runtime nobody named. This means a bare
+`validateGraph(graph).valid === true` does **not** by itself guarantee the graph is
+executable by the browser client — a UI node kind no renderer implements, or a
+client-authority trigger kind the browser trigger runtime does not execute
+(`CLIENT_TRIGGER_UNSUPPORTED`), both validate silently under the no-options call. Use
+`validateForBrowser(graph)` (`@cynodia/axiom-compiler`) for a validate-only check against
+real browser capabilities, or call `compileToIR(graph)` directly — it applies those same
+capabilities and throws `GraphValidationError` on exactly what `validateForBrowser` would
+report as an error. See [Renderability](#renderability) below for the parallel UI-kind gate.
+
+```ts
+validateGraph(graph).valid;          // target-neutral: accepts every UI kind and trigger kind
+validateForBrowser(graph).valid;     // browser-real: same as compileToIR's validation step
+```
+
 ## Agent API
 
 ```ts
@@ -605,12 +621,13 @@ before authoring an application that reaches an external system or reacts to tim
 event.
 
 1. **INTEGRATION INVARIANT** — external systems are accessed through typed integration operations; the graph never carries an SDK, a host name or a secret.
-2. **QUERY INVARIANT** — external queries are explicit execution, resolved before the transaction they feed opens — never a pure `Expression`.
-3. **EFFECT INVARIANT** — external effects are not rollback-capable state mutations. Reaching `integration-effect` only records intent; the adapter runs only after commit.
+2. **QUERY INVARIANT** — external queries are explicit execution, resolved before the transaction they feed opens — never a pure `Expression`. `timeoutMs` is enforced by the runtime itself, not left to adapter cooperation; a non-cooperating adapter cannot wedge the invocation past its deadline (spec 8.1 §15-25).
+3. **EFFECT INVARIANT** — external effects are not rollback-capable state mutations. Reaching `integration-effect` only records intent; the adapter runs only after commit. The outcome reaches a follow-up action as a structured envelope (`effectOutcomeEntity` — `EFFECT_ID_FIELD`/`EFFECT_OPERATION_ID_FIELD`/…), never a raw result or a formatted string requiring text parsing to correlate (spec 8.1 §37-41).
 4. **OUTBOX INVARIANT** — effect intent is committed atomically with the state write that requested it, before external execution, so a crash between the two does not lose it.
-5. **TRIGGER INVARIANT** — a trigger invokes an ordinary action, under exactly the guards, constraints, transition constraints and authorization any other caller is subject to.
+5. **TRIGGER INVARIANT** — a trigger invokes an ordinary action, under exactly the guards, constraints, transition constraints and authorization any other caller is subject to. Every invocation this authority runs — client request or trigger tick — is serialized against every other one, so simultaneous same-period triggers commit one at a time identically on the deterministic and the real host (spec 8.1 §26-30).
 6. **EVENT INVARIANT** — an event is a typed fact, validated against its declared payload type before any action sees it; an action is where work happens.
 7. **SECRET INVARIANT** — integration credentials live in host configuration (`AxiomServerOptions.integrations`), never in `ApplicationGraph`.
+8. **INVOCATION SOURCE INVARIANT** — a system-originated invocation (trigger, event, effect outcome) and an anonymous client request are distinct authoritative facts; a client cannot forge the former (`ExecutionContext.source` is server-computed, never read from protocol data), and `ActionDef.invocation.allowedSources` lets an action restrict which it accepts independently of `authorization`'s identity check (spec 8.1 §3-14).
 
 ```ts
 { kind: 'integration', id: INTEGRATION_DEVICE_PROVIDER }
@@ -630,29 +647,44 @@ event.
 
 - `mode: 'query'` may bind its result into scope (`bindAs`) for later operations in the same action; `mode: 'effect'` never runs synchronously and its outcome reaches an action only through a dispatched `succeededEventId`/`failedEventId`.
 - A trigger's target action runs where the action itself runs — server if it writes server state or calls an integration, client only for `route-enter`/`route-leave`. Derived, never declared, exactly like ordinary action authority.
-- A triggered/event-originated invocation runs with `principal: null`, `source: 'system'` — the same as an anonymous client request, never an impersonated user. Authorization still evaluates.
+- A triggered/event-originated invocation runs with `principal: null`, `source: 'system'` — the same as an anonymous client request, never an impersonated user. Authorization still evaluates, and `invocation.allowedSources` is checked before it: `{ invocation: { allowedSources: ['system'] } }` refuses a direct client `InvokeRequest` with `INVOCATION_SOURCE_NOT_ALLOWED`, which is what protects a webhook- or effect-outcome-only action from being forged by a client that guessed its id.
 - `createDeterministicServerHost().advance(ms)` fires due timers deterministically; no trigger test waits on a real clock.
 
 ```ts
 agent.listIntegrations() / agent.listIntegrationOperations(id?);
 agent.getActionsUsingIntegration(id) / agent.getEffectsForAction(actionId);
 agent.getTriggersForAction(actionId) / agent.getTimedTriggers();
-agent.getActionsTriggeredByEvent(eventId) / agent.getWebhookEvents();
+agent.getActionsTriggeredByEvent(eventId) / agent.getTriggeredEvents();  // graph-static: has a bound trigger, not "was delivered"
 agent.getExternalDependencies();   // { integrations, operations } — the deployment manifest
+agent.getSystemOnlyActions() / agent.getTriggersTargetingClientOnlyActions();
+agent.isClientInvocable(actionId) / agent.isSystemOnly(actionId);
 ```
 
 Portable artifacts, for a runtime written in another language:
 
 ```
-@cynodia/axiom-server/conformance                     the fixture manifest
+@cynodia/axiom-server/conformance                     the fixture manifest (fixture.format, below)
 @cynodia/axiom-server/conformance/<name>.json         one fixture, pure data
-@cynodia/axiom-server/schema/server-ir.v1.schema.json JSON Schema for the IR
+@cynodia/axiom-server/schema/server-ir.v1.schema.json JSON Schema for axiom.server.v1 (frozen)
+@cynodia/axiom-server/schema/server-ir.v2.schema.json JSON Schema for axiom.server.v2
+@cynodia/axiom-server/schema/server-ir.v3.schema.json JSON Schema for axiom.server.v3
+@cynodia/axiom-server/schema/server-ir.v4.schema.json JSON Schema for axiom.server.v4 (latest)
 @cynodia/axiom-server/schema/protocol.v1.schema.json  JSON Schema for the protocol
 ```
 
+This list is generated/tested content, not hand-maintained prose: `packages/demo/test
+/documentation.test.ts` fails if a shipped `schema/*.json` file is missing from it or a
+listed file no longer exists (spec 8.2 §43-45). `runConformanceFixture`/
+`runConformanceSuite` (`@cynodia/axiom-server`) are the public runner over that fixture
+format — see [`AUTHORITY.md`](AUTHORITY.md#conformance) for `fixture.conformance` (the
+fixture-format version) vs `fixture.serverIR.contract` (the per-fixture Server IR contract)
+vs the manifest's own `conformance`/`protocol`/`release` fields — three separate concepts,
+never conflated under one "contract" name (spec 8.2 §9-10).
+
 Boundary diagnostics: `UNKNOWN_SERVER_ACTION` `ARGUMENT_TYPE_MISMATCH` `AUTHORIZATION_DENIED`
-`CONCURRENCY_CONFLICT` `MALFORMED_REQUEST` `AUTHORITY_UNREACHABLE`, plus `SERVER_STATE_WRITE`
-and `REMOTE_ACTION_UNAVAILABLE` on the client.
+`INVOCATION_SOURCE_NOT_ALLOWED` `CONCURRENCY_CONFLICT` `MALFORMED_REQUEST`
+`AUTHORITY_UNREACHABLE`, plus `SERVER_STATE_WRITE` and `REMOTE_ACTION_UNAVAILABLE` on the
+client.
 
 ## Metadata classes
 
@@ -679,6 +711,19 @@ Capabilities describe **node-kind** support, not partial support: a renderer can
 that it draws a kind but not one of its options. Nothing in the current vocabulary needs that,
 and it is a deliberate future extension rather than an oversight.
 
+The same gate exists for client-authority triggers, since the browser trigger runtime
+implements no `TriggerSpec.kind` at all:
+
+```ts
+validateGraph(graph, { triggerRuntime: BROWSER_TRIGGER_CAPABILITIES });  // CLIENT_TRIGGER_UNSUPPORTED
+compileToIR(graph);                                                     // applies it by default
+```
+
+`CLIENT_TRIGGER_UNSUPPORTED`'s message states the remediation, not only the refusal: move
+the trigger's target action to server authority, or compile for a trigger runtime that
+publishes the kind (`compileToIR(graph, { triggerRuntime })`). Full model:
+[`TRIGGERS.md`](TRIGGERS.md#where-a-trigger-executes).
+
 ## Named expressions
 
 ```ts

package/docs/ANTI_PATTERNS.md

@@ -1,6 +1,6 @@
 # Anti-patterns
 
-Axiom 0.8.0-alpha.1. Each of these compiles. Each is wrong. Each is followed by the correct
+Axiom 0.8.2-alpha.1. Each of these compiles. Each is wrong. Each is followed by the correct
 alternative.
 
 ## 1. Field names as entity runtime keys
@@ -390,8 +390,11 @@ credential belongs to the host, not the graph.
 { kind: 'native', implementationId: 'app.sendEmail' }
 ```
 
-External effects are deliberately unsolved in 0.6. A design involving commands, a
-transactional outbox and idempotency is future work; do not smuggle one in meanwhile.
+Use `IntegrationDef` + an `integration-effect` operation instead — a typed semantic
+operation, dispatched post-commit through the durable outbox, with retry and an
+idempotency key, whose outcome reaches a follow-up action as a structured event rather than
+a side effect nothing can roll back. See [`INTEGRATIONS.md`](INTEGRATIONS.md) and
+[`EFFECTS.md`](EFFECTS.md).
 
 ## 31. Restating what the model already knows
 

package/docs/AUTHORITY.md

@@ -1,6 +1,6 @@
 # Authority
 
-Axiom 0.8.0-alpha.1. How an application crosses the trust boundary.
+Axiom 0.8.2-alpha.1. 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
@@ -39,6 +39,7 @@ describes both halves, so there is no backend to write.
 18. **TRIGGER** — a trigger invokes an ordinary action, under the same guards, constraints, transition constraints and authorization any other caller is subject to. See [Triggers](#triggers).
 19. **EVENT** — an event is a typed fact, validated against its declared payload type before any action sees it; an action is where work happens. See [External events](#external-events).
 20. **SECRET** — integration credentials live in host configuration, never in `ApplicationGraph`. See [External systems](#external-systems).
+21. **INVOCATION SOURCE** — a system-originated invocation (trigger, event, effect outcome) and an anonymous client request are distinct authoritative facts; a client cannot forge the former, and an action may restrict which it accepts independently of caller identity. See [Invocation source](#invocation-source).
 
 ## Authority and persistence are different questions
 
@@ -88,8 +89,49 @@ claim that validation already happened.
 | Forge an action id | resolved from the authority's own IR → `UNKNOWN_SERVER_ACTION` |
 | Send an argument of the wrong shape | checked against the declared type → `ARGUMENT_TYPE_MISMATCH` |
 | Invoke without permission | `authorization`, evaluated on the authority → `AUTHORIZATION_DENIED` |
+| Invoke an action reachable only by a trigger, event or effect outcome | `invocation.allowedSources` → `INVOCATION_SOURCE_NOT_ALLOWED` |
+| Claim to be a trigger, event or effect outcome | `context.source` is server-computed; no protocol field lets a request supply it |
 | Read server-only state | it is not in the client IR, the snapshot or any answer |
 
+## Invocation source
+
+`authorization` answers *who* may invoke an action; invocation source answers *how the
+invocation reached the authority at all* — a distinct question, because the two can diverge.
+An action meant only as a webhook's target, or only as an `integration-effect`'s
+`succeededEventId`/`failedEventId` handler, may declare no `authorization` at all — it was
+never meant to need one, since only the trigger runtime was ever supposed to call it. Before
+this existed, any client that guessed the action's id could invoke it directly, forging a
+fake webhook delivery or a fake effect outcome (spec 8.1 §3-9).
+
+```ts
+{
+  id: ACTION_APPLY_STATUS_CHANGE,
+  kind: 'action',
+  invocation: { allowedSources: ['system'] },   // a client InvokeRequest is refused
+  operations: [ /* … */ ],
+}
+```
+
+`allowedSources` is `['client', 'system']` — both — unless declared otherwise, so every
+existing graph keeps its current behavior. `'system'` covers every trigger kind (interval,
+delay, lifecycle, event) and every effect-outcome dispatch; there is no finer distinction,
+because a trigger invokes an action "through the same semantics as any other caller"
+([TRIGGER](#load-bearing-server-invariants)) and does not get a different one here either.
+
+The source itself is `ExecutionContext.source`, computed by the authority and never read
+from client-supplied protocol data — `InvokeRequest` and `EventRequest` carry no `source`
+field to forge in the first place. A client request is always `'client'`; a trigger-, event-
+or effect-outcome-originated invocation is always `'system'`, with `principal: null` exactly
+as an anonymous client's is, so `authorization` still evaluates and cannot be bypassed by a
+trigger either (spec §69,104) — invocation source and principal are deliberately separate
+questions, and a system invocation is not a stand-in identity.
+
+`checkInvocationSource` runs before `authorization`, before argument-driven work, and before
+any transaction opens: a refusal changes nothing, commits nothing, and dispatches no effect
+or event. `validateGraph` also catches the case a graph author can state statically — a
+trigger targeting an action whose `allowedSources` excludes `'system'` could never succeed —
+with `TRIGGER_TARGET_SOURCE_MISMATCH`.
+
 ## Server IR
 
 ```ts
@@ -435,6 +477,7 @@ does for a local failure.
 | `INTEGRATION_ADAPTER_MISSING` | The Server IR requires an integration with no registered adapter — refused at `start()`, never deferred to first invocation. |
 | `EVENT_DISPATCH_DEPTH_EXCEEDED` | An event → action → effect → event chain was stopped before it could recurse unboundedly. |
 | `WEBHOOK_VERIFICATION_FAILED` | A webhook delivery failed provider signature verification and was refused before an event was ever constructed. |
+| `INVOCATION_SOURCE_NOT_ALLOWED` | The action's `invocation.allowedSources` does not include this invocation's source (spec 8.1 §3-9) — refused before `authorization` is even evaluated, because no caller reaching the authority this way may invoke the action at all. |
 
 Two client-side codes belong to the boundary as well:
 
@@ -506,6 +549,26 @@ Running them requires no part of this implementation. That is the point: the Ser
 specification plus these fixtures are the whole contract, so an independent runtime in
 another language can be held to exactly the same standard.
 
+**A public reference runner is exported for the TypeScript reference runtime itself**
+(spec 8.2 §14-16):
+
+```ts
+import { runConformanceFixture, runConformanceSuite } from '@cynodia/axiom-server';
+
+const result = await runConformanceFixture(fixtureJson);   // { name, ok, failures[] }
+```
+
+It imports only `@cynodia/axiom-server` and fixture data — no graph, no compiler, no
+builder — and reports structured pass/fail rather than throwing on an ordinary fixture
+mismatch. `packages/server/test/conformance.test.ts` runs every shipped fixture through
+this exact function, and `npm run conformance:run` (`scripts/run-conformance.mjs`) runs the
+whole suite from a standalone script using nothing but this public API and the manifest —
+the "held to the same standard by an outside caller" claim, demonstrated rather than
+asserted. The fixture **model** (`ConformanceFixture` and friends, `conformance-types.ts`)
+is deliberately kept separate from this **adapter**
+(`conformance-runner.ts`): a non-TypeScript implementation needs only the model's shape and
+the semantics on this page, never this file.
+
 Enumerate the suite from its manifest rather than by listing a directory:
 
 ```
@@ -513,12 +576,24 @@ Enumerate the suite from its manifest rather than by listing a directory:
 @cynodia/axiom-server/conformance/<name>.json → one fixture
 ```
 
-The manifest names the contracts the fixtures are written against (`axiom.conformance.v1`,
-`axiom.server.v1`, `axiom.protocol.v1`), the release, every area covered, and every fixture
-with its file. A runtime that does not implement a contract the manifest names should refuse
-the suite rather than discover the mismatch one assertion at a time. The files are plain JSON
-in a documented package directory, so a non-JavaScript consumer can read them straight out of
-the tarball without Node's module resolver.
+The manifest carries three **separate, non-overlapping** version concepts (spec 8.2 §9-10;
+do not conflate them under one "contract" name):
+
+| Field | Means |
+| --- | --- |
+| `manifest.conformance` | The **fixture-format** version (`axiom.conformance.v1`/`v2`) — the shape of the JSON documents themselves: what top-level keys a fixture may have (`invocations` vs `steps`/`externalAdapters`, and so on). |
+| `manifest.baseContract` | The **oldest** Server IR contract any fixture in this manifest may use — `axiom.server.v1`, always, since new fixtures are added without ever raising this floor. It does **not** describe what the newest fixture needs. |
+| `manifest.fixtures[].contract` | The Server IR contract **that specific fixture** requires — this is what is authoritative for what running it needs. The suite ships fixtures spanning `v1` through `v4` simultaneously, each correctly labelled. |
+| `manifest.release` | The `@cynodia/axiom` package version this snapshot of the suite shipped with — unrelated to either version above. |
+
+Before 8.2 the manifest's top-level field was named `contract` and fixed at
+`axiom.server.v1`, which read as a claim about the whole suite even after `v3`/`v4`
+fixtures were added; it is now named `baseContract` with the meaning above, precisely
+because per-fixture `contract` is what is actually authoritative. A runtime that does not
+implement a contract a fixture names should refuse that fixture rather than discover the
+mismatch mid-assertion. The files are plain JSON in a documented package directory, so a
+non-JavaScript consumer can read them straight out of the tarball without Node's module
+resolver.
 
 Every fixture is executed against the reference runtime by this repository's own test suite,
 and its expectations are exhaustive — a fixture that says which states changed must name all
@@ -530,6 +605,7 @@ of them and no others. No fixture is permitted to disagree with the shipped runt
 @cynodia/axiom-server/schema/server-ir.v1.schema.json
 @cynodia/axiom-server/schema/server-ir.v2.schema.json
 @cynodia/axiom-server/schema/server-ir.v3.schema.json
+@cynodia/axiom-server/schema/server-ir.v4.schema.json
 @cynodia/axiom-server/schema/protocol.v1.schema.json
 ```
 
@@ -549,15 +625,21 @@ page plus the conformance fixtures.
 | `axiom.server.v1` | the frozen 0.6.1 contract, below | 0.6.1 |
 | `axiom.server.v2` | the expression kinds `group` and `expression-ref`, and the `expressionDefs` they resolve against | 0.7.0 |
 | `axiom.server.v3` | integrations, integration operations, events, triggers, and the `integration-query`/`integration-effect` operation kinds | 0.8.0 |
+| `axiom.server.v4` | `ActionDef.invocation.allowedSources` invocation-source restriction, and the structured effect-outcome envelope (`effectOutcomeEntity`, `EFFECT_ID_FIELD` and its sibling reserved fields) that every effect dispatch uses from 8.1 onward | 0.8.1 |
 
-`SERVER_IR_CONTRACTS` enumerates all three. The rules:
+`SERVER_IR_CONTRACTS` enumerates all four, and is the single source of truth this table is
+tested against — `packages/demo/test/documentation.test.ts` fails if a contract in
+`SERVER_IR_CONTRACTS` has no row here, or a row here names a contract the code does not
+declare (spec 8.2 §7-8). The rules:
 
-- **A document declares the oldest contract that can carry it.** `compileToServerIR` computes the label from the vocabulary the document actually uses, so an application that uses nothing from 0.7 or 0.8 produces a byte-identical `axiom.server.v1` document, and the committed v1 conformance fixtures are unchanged.
-- **A runtime MUST refuse a contract it does not implement**, and MUST refuse a document whose vocabulary exceeds its declared contract. A v2 runtime executing a v1-labelled document that uses `group` would accept what a conforming v1 runtime elsewhere refuses, and the two would then disagree about the same file. `createAxiomServer` raises rather than executing one.
-- **A frozen contract gains nothing.** `axiom.server.v1` does not contain `group`, `expression-ref`, `expressionDefs`, an integration, a trigger, an event, or the `integration-query`/`integration-effect` operation kinds, and `server-ir.v1.schema.json` is byte-frozen. Vocabulary arrives under a new identifier or not at all.
+- **A document declares the oldest contract that can carry it.** `compileToServerIR` computes the label from the vocabulary the document actually uses, so an application that uses nothing from 0.7 or 0.8 produces a byte-identical `axiom.server.v1` document, and the committed v1 conformance fixtures are unchanged. `usesV4Semantics` computes the v4 case specifically: an action's `invocation.allowedSources` genuinely restricting the default two-source set, or any `integration-operation` with `mode: 'effect'` (since every effect dispatch uses the structured v4 envelope) — a document that merely mentions `invocation` without restricting it only needs `axiom.server.v2`, the same tier `group`/`expression-ref` occupy.
+- **A runtime MUST refuse a contract it does not implement**, and MUST refuse a document whose vocabulary exceeds its declared contract. A v2 runtime executing a v1-labelled document that uses `group` would accept what a conforming v1 runtime elsewhere refuses, and the two would then disagree about the same file. `createAxiomServer` raises rather than executing one — including refusing a document that **understates** its own contract (`understatedContract`).
+- **A frozen contract gains nothing.** `axiom.server.v1` does not contain `group`, `expression-ref`, `expressionDefs`, an integration, a trigger, an event, the `integration-query`/`integration-effect` operation kinds, `invocation`, or the structured effect-outcome envelope, and `server-ir.v1.schema.json` is byte-frozen. Vocabulary arrives under a new identifier or not at all.
+- **`axiom.server.v4` is the latest contract as of 0.8.2** (`SERVER_IR_LATEST_CONTRACT`). 0.8.2 is polish-only — documentation, effect observability timing, fixture coverage and AgentAPI aliasing — and introduces no incompatible IR vocabulary change, so no `axiom.server.v5` was created (spec 8.2 §55-56).
 
 There is one JSON Schema per contract, each generated from the runtime's own vocabulary and
-each shipped: `server-ir.v1.schema.json`, `server-ir.v2.schema.json`, `server-ir.v3.schema.json`.
+each shipped: `server-ir.v1.schema.json`, `server-ir.v2.schema.json`, `server-ir.v3.schema.json`,
+`server-ir.v4.schema.json`.
 
 **`group`.** Partitions a collection: `Collection<A>` → `Collection<Group<K, A>>`. Groups appear
 in the order their key was **first seen** in the source; members keep source order; two keys are
@@ -725,7 +807,7 @@ Stated plainly rather than left to discovery:
 - **Generated values cannot be bound within an action, in general.** An operation cannot name a value an earlier operation produced: `uuid()` evaluated in one `insert` cannot be referred to by a later `insert` in the same action. Give the record an identity the action already has — a parameter, or a field of something it read — or perform the second write in a second action. 0.8 adds exactly one narrow, purpose-built exception: an `integration-query`'s `bindAs` result, resolved before the transaction opens (see [External systems](#external-systems)) — not a general operation-result binding mechanism.
 - **Read authorization per caller or per record.** Visibility is per state.
 - **Absolute/cron schedules.** `interval` and `delay` triggers cover "every N milliseconds" and "once after N milliseconds"; a calendar schedule ("every day at 09:00") is not modeled.
-- **Client-side execution of interval, delay and lifecycle triggers.** `ApplicationIR.triggers` carries client-authority triggers for inspection, but the browser runtime does not yet schedule or dispatch them itself — only the authoritative runtime does. A client-authority trigger declared in a graph today is compiled and analyzable, not executed.
+- **Client-side execution of interval, delay and lifecycle triggers.** The browser runtime implements no trigger kind at all. Before spec 8.1 a client-authority trigger silently compiled into `ApplicationIR.triggers` and simply never fired; now `validateGraph`/`compileToIR` reject it with `CLIENT_TRIGGER_UNSUPPORTED` instead, so the gap is a compile-time error rather than a runtime discovery. Only the authoritative runtime executes triggers today.
 - **Durable effect delivery beyond the two shipped `PersistenceAdapter`s.** At-least-once delivery across a restart is real for `createMemoryPersistence` (within the process) and `createSqlitePersistence`; a third adapter earns the same claim only by implementing `loadPendingEffects`/`recordEffectAttempt` itself.
 - **Realtime synchronization**, subscriptions and collaboration. Request/response only.
 - **Query semantics.** Authoritative collections are loaded into runtime state; large-data querying needs its own design.

package/docs/CONSTRAINTS.md

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

package/docs/EFFECTS.md

@@ -1,6 +1,6 @@
 # Effects
 
-Axiom 0.8.0-alpha.1. External effects are not rollback-capable state mutations. This file
+Axiom 0.8.2-alpha.1. 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.
@@ -79,6 +79,22 @@ doubles it each time. The wait uses the host's own scheduling
 (`ServerHost.scheduleOnce`), so a test can drive it with `createDeterministicServerHost()`
 + `advance(ms)` and never wait on a real clock.
 
+**`IntegrationFailure.retryable: false` is control flow, not metadata.** It stops the
+remaining retry policy immediately, regardless of `maxAttempts` — an adapter that always
+answers `retryable: false` never retries at all, whatever `policy` says (spec 8.1 §73).
+
+**The three states of `retryable` (spec 8.2 §38-39):**
+
+| `retryable` | Meaning | Effect on the declared policy |
+| --- | --- | --- |
+| `false` | The adapter determined a retry cannot succeed. | Stops immediately — the remaining `maxAttempts` are never spent. |
+| `true` | The adapter determined a retry may succeed. | Continues — the next attempt runs after the policy's delay. |
+| absent | The adapter could not determine retryability either way. | Continues, exactly as `true` — an unknown answer is not treated as a refusal. |
+
+`packages/server/test/effect-retry.test.ts` is the regression coverage for all three,
+including a genuine multi-attempt retry sequence with a stable `idempotencyKey` across
+every attempt.
+
 ## Effect status and observability
 
 ```ts
@@ -102,21 +118,161 @@ mutation, and mixing the two would misrepresent what actually happened (spec §7
 `report()` events cover the whole lifecycle: `effect-requested`, `effect-attempted`,
 `effect-succeeded`, `effect-failed`.
 
+**Exact status semantics (spec 8.2 §17-21):**
+
+| Status | Means |
+| --- | --- |
+| `pending` | A durable effect intent exists (committed in the outbox), but no attempt is currently executing — either dispatch has not started yet, or it is waiting between retry attempts. |
+| `running` | An adapter attempt has been started and has not yet settled. Set **before** `IntegrationAdapter.effect(...)` is called, synchronously with the durable `attempts` increment, so `effectLog()`'s public view reflects reality rather than lagging behind it. |
+| `succeeded` | An attempt returned `{ ok: true }`. Terminal. |
+| `failed` | Every attempt the retry policy allows was exhausted, or one returned `retryable: false`. Terminal. |
+
+Before 8.2, `running` existed in the type but nothing updated `AxiomServer`'s in-memory
+`effectLog()` view when an attempt actually started — a hung adapter call was
+indistinguishable from an effect nobody had dispatched yet, both showing `status: 'pending',
+attempts: 0` forever even though the adapter had genuinely been invoked. `attempts` counts
+**invocation attempts started**, not merely attempts that settled — it increments at the
+same moment `status` moves to `'running'`, before the adapter is called, so a hung attempt
+is still counted. `packages/server/test/integrations.test.ts`'s hung-effect regression is
+the test for this.
+
+**Restart semantics for a `running` effect (spec 8.2 §20).** A record persisted as
+`'running'` when the authority restarts means a previous process called the adapter and was
+never told the outcome — that attempt is unaccounted for, not spent. It is treated as
+resumable/unknown outstanding work: the resumed dispatch gets a **fresh** full retry budget
+(local attempt count restarts at zero; the persisted `attempts` total still carries forward
+honestly across the restart) rather than silently going idle at zero remaining attempts.
+Axiom never claims to know whether the old process's call actually reached the provider —
+only that at-least-once redelivery, paired with `idempotencyKey`, is what makes resuming it
+safe.
+
+**No runtime-enforced effect timeout in 0.8.2.** Unlike an `integration-query`'s
+`timeoutMs` (deadline enforced by the runtime itself — see [`INTEGRATIONS.md`](INTEGRATIONS.md#timeout)),
+a `running` effect attempt has no deadline: a non-cooperating adapter call can remain
+`running` indefinitely, and nothing in this release will time it out or reclassify it. This
+is a deliberate scope boundary, not an oversight (spec 8.2 §24) — see the note below for why.
+
+**Research note: effect timeout is deferred, not merely unbuilt (spec 8.2 §25).** A future
+effect timeout cannot safely map a timed-out attempt directly to `failed`: unlike a query,
+an effect may have genuinely reached the provider and caused the external side effect
+before the response was lost — declaring it `failed` could make an idempotent caller retry
+a side effect that already happened once, and declaring it `succeeded` could be simply
+wrong. The honest state that later work would need is something like `unknown` — distinct
+from both terminal states — but that state is deliberately **not** introduced in 0.8.2. Do
+not add a deadline just because `running` is now observable; effect timeout remains a
+distinct future design topic.
+
 ## The result reaches an action only through an event
 
 An effect's outcome is never folded back into the transaction that requested it. Instead,
 `succeededEventId`/`failedEventId` — ordinary `EventDef` nodes — are dispatched through
 the same event pipeline an external webhook uses (see [`EVENTS.md`](EVENTS.md)), once the
-outcome is known:
+outcome is known, as a **structured envelope** (spec 8.1 §37-41):
 
-- **Success payload** is the effect operation's own `resultType` value — the adapter's
-  returned result, unchanged.
-- **Failure payload** is the error formatted as text, `"<code>: <message>"` — declare
-  `failedEventId`'s `payloadType` as `primitiveType('string')` to receive it.
+```ts
+import { EFFECT_ID_FIELD, EFFECT_OPERATION_ID_FIELD, EFFECT_RESULT_FIELD, effectOutcomeEntity } from '@cynodia/axiom-core';
+
+graph.addNode(effectOutcomeEntity(ENTITY_EFFECT_OUTCOME, primitiveType('string')));   // the operation's resultType
+graph.addNode<EventDef>({ id: EVENT_SUCCEEDED, kind: 'event', payloadType: entityType(ENTITY_EFFECT_OUTCOME) });
+graph.addNode<EventDef>({ id: EVENT_FAILED, kind: 'event', payloadType: entityType(ENTITY_EFFECT_OUTCOME) });
+```
+
+One shape covers both outcomes — field ids are graph-global, so two entities could not both
+declare `effectId`/`operationId`/`integrationId` without colliding:
+
+| Field | Present on success | Present on failure |
+| --- | --- | --- |
+| `EFFECT_ID_FIELD` | always | always |
+| `EFFECT_INTEGRATION_ID_FIELD` | always | always |
+| `EFFECT_OPERATION_ID_FIELD` | always | always |
+| `EFFECT_IDEMPOTENCY_KEY_FIELD` | when declared | when declared |
+| `EFFECT_CORRELATION_ID_FIELD` | when the action's transaction has one | when the action's transaction has one |
+| `EFFECT_RESULT_FIELD` | the operation's own `resultType` value | absent |
+| `EFFECT_CODE_FIELD` | absent | the adapter's failure code |
+| `EFFECT_MESSAGE_FIELD` | absent | the adapter's failure message |
+| `EFFECT_RETRYABLE_FIELD` | absent | whether a retry might have succeeded |
+
+A follow-up action correlates the outcome to the effect that caused it through
+`EFFECT_ID_FIELD`/`EFFECT_OPERATION_ID_FIELD` — never by parsing text. Before 8.1, the
+success payload was the raw `resultType` value with no envelope, and the failure payload
+was a single formatted string `"<code>: <message>"`; an application still declaring
+`primitiveType('string')` as either event's `payloadType` now fails validation, because the
+dispatched value is always this entity shape.
 
 Both are checked against the declared `EventDef.payloadType` the same way any event is,
 so a mismatched declaration is caught rather than silently dropped.
 
+**The full envelope, field by field (spec 8.2 §31-33):**
+
+| Field | Present | Source, lifetime and stability |
+| --- | --- | --- |
+| `EFFECT_ID_FIELD` | always | The framework-generated id of this effect intent. Stable for the life of the intent (survives restart — it is what `EffectRecord.id` is keyed by), never consumer-settable. |
+| `EFFECT_INTEGRATION_ID_FIELD` | always | The `IntegrationDef.id` the operation belongs to. Graph-static. |
+| `EFFECT_OPERATION_ID_FIELD` | always | The `IntegrationOperationDef.id` invoked. Graph-static. |
+| `EFFECT_IDEMPOTENCY_KEY_FIELD` | when the `integration-effect` operation declared one | Whatever the action's `idempotencyKey` expression evaluated to at commit time. Application-controlled, and the field the framework recommends for business correlation (below). |
+| `EFFECT_CORRELATION_ID_FIELD` | when the committing action's transaction has one | See below — this is **not** a business correlation key. |
+| `EFFECT_RESULT_FIELD` | success only | The operation's own `resultType` value, unwrapped from the adapter's `IntegrationSuccess.value`. |
+| `EFFECT_CODE_FIELD` | failure only | The adapter's `IntegrationFailure.code`. |
+| `EFFECT_MESSAGE_FIELD` | failure only | The adapter's `IntegrationFailure.message` — see the security note below before copying it into state. |
+| `EFFECT_RETRYABLE_FIELD` | failure only | The adapter's `IntegrationFailure.retryable`, coerced to a boolean (`retryable === true`; both `false` and absent read as `false` here — the three-way distinction that matters for retry control flow is internal to the retry policy, not exposed on the terminal payload). |
+
+Success and failure share this one envelope family — the always-present fields plus
+`idempotencyKey`/`correlationId` when applicable — but they are **not symmetric**: success
+never carries `EFFECT_CODE_FIELD`/`EFFECT_MESSAGE_FIELD`/`EFFECT_RETRYABLE_FIELD`, and
+failure never carries `EFFECT_RESULT_FIELD`. Do not describe the two shapes as identical;
+describe them as one family with disjoint success-only and failure-only fields.
+
+**What `EFFECT_CORRELATION_ID_FIELD` actually is.** Its value is the internal Axiom
+transaction id (`Transaction.id`, formatted like `tx_<n>`) of the action's transaction that
+recorded the effect intent — the same id `RuntimeDiagnostic.transactionId` already carries
+elsewhere. Concretely:
+
+- **Source**: assigned by the runtime's own per-process transaction counter, never supplied
+  or influenced by the application or the adapter.
+- **Lifetime**: exists only as long as the process that created it is running.
+- **Uniqueness scope**: unique only within one running authority process — it is not a
+  globally unique identifier.
+- **Stable across restart?** No. The counter resets when the authority restarts, so this
+  value cannot be used to correlate an effect across a restart, or across two different
+  authority processes.
+- **Consumer-settable?** No — there is no way for a graph or an adapter to choose it.
+- **Always present?** In practice yes, since every `integration-effect` operation only ever
+  runs inside an action's transaction, and every transaction is assigned an id — but it is
+  documented as conditional (`when the committing action's transaction has one`) because
+  that is a property of the runtime's transaction model, not a graph-level guarantee this
+  document freezes.
+
+**Its string format (`tx_<n>`) is explicitly not part of the public contract** (spec 8.2
+§27) — only its semantics are: "identifies the Axiom transaction that created this effect
+intent, within this process's lifetime." A future implementation may change the format
+without that being a breaking change, as long as the semantics hold.
+
+**Business correlation guidance (spec 8.2 §28-30).** `EFFECT_CORRELATION_ID_FIELD` is an
+**internal diagnostic aid**, not a business correlation key — it identifies "which
+transaction" in this process, not "which order" or "which device" to a follow-up action.
+**Effect outcomes do not automatically carry the original operation's arguments.** An
+application that needs to correlate an outcome back to a specific business entity (which
+order this reboot was for, which customer this notification was about) should use
+`idempotencyKey` for that purpose when the value is naturally unique per business operation
+(an order id, a reservation id) — it is already carried through to both the success and
+failure envelope, application-controlled, and exists for exactly this shape of problem.
+0.8.2 deliberately does **not** add a separate `correlationKey`/`correlationValue`
+primitive: `idempotencyKey` already covers the common case cleanly, and a second field
+whose only job is to avoid a documentation inconvenience was judged not worth the added
+vocabulary (spec 8.2 §29-30). This may be revisited if a concrete use case proves
+`idempotencyKey` alone is not conceptually clean enough — none has yet.
+
+**Effect message security (spec 8.2 §33).** Framework diagnostics — anything Axiom itself
+emits as a `RuntimeDiagnostic`/`ServerDiagnostic` — are sanitized according to
+`DISCLOSABLE_DETAIL_KEYS` (see [`AUTHORITY.md`](AUTHORITY.md#diagnostics)) before crossing
+the trust boundary. `EFFECT_MESSAGE_FIELD`/`EFFECT_CODE_FIELD` are different: they are
+**application data**, populated verbatim from whatever `IntegrationFailure.message`/`.code`
+the adapter returned, and dispatched into ordinary graph state through the event pipeline
+like any other value. Once an application's own action copies an adapter's message into
+state, **that application is responsible for what the message contains** — Axiom's
+diagnostic sanitization does not reach into adapter-authored text. Never place a secret or
+credential in an adapter's `IntegrationFailure.message`.
+
 ## No automatic compensation
 
 0.8 does not implement compensation. If an effect has a semantic inverse, it is another

package/docs/EVENTS.md

@@ -1,6 +1,6 @@
 # Events
 
-Axiom 0.8.0-alpha.1. An event is a typed fact — something that happened — never work
+Axiom 0.8.2-alpha.1. 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.
 
@@ -75,6 +75,10 @@ unverified request never reaches the semantic layer at all (`WEBHOOK_VERIFICATIO
 401). Provider-specific protocol — headers, signing scheme, payload shape — stays entirely
 in `verify`/`decode`; nothing crosses into `ApplicationGraph`.
 
+`serveAxiomApplication({ ..., webhooks })` accepts the same option directly (spec 8.1
+§56-58) — a webhook-receiving application no longer has to drop to `createAxiomServer` +
+`serveOverHttp` just to register one.
+
 ## Duplicate delivery
 
 `decode`'s optional `deliveryId` is deduplicated against a **bounded, per-route,
@@ -106,10 +110,20 @@ Full tables: [`VALIDATION.md`](VALIDATION.md#integrations-effects-triggers-and-e
 ## AgentAPI
 
 ```ts
-agent.getWebhookEvents();               // EventDef[] — events at least one trigger reacts to
+agent.getTriggeredEvents();             // EventDef[] — events at least one trigger reacts to
 agent.getActionsTriggeredByEvent(id);   // ActionDef[]
 ```
 
-"Which webhook can mutate `Order`?" (spec §78) is answerable by following
-`getWebhookEvents()` through `getActionsTriggeredByEvent()` to the actions it can reach,
+`getTriggeredEvents()` is a **graph-static** query — "which `EventDef`s have a `TriggerDef`
+bound to them" — not "which webhook deliveries has this server received" (spec 8.2 §34-37).
+An event it returns may be dispatched by a verified external webhook, by an effect's
+`succeededEventId`/`failedEventId`, or by any other internal source; the graph does not
+record which, so nothing here claims to. Webhook routes and deployment-level registration
+are host/deployment concerns, deliberately outside what `GraphQueries` infers.
+
+`getWebhookEvents()` is a deprecated alias, kept for backward compatibility; new code should
+call `getTriggeredEvents()`.
+
+"Which trigger-bound event can mutate `Order`?" (spec §78) is answerable by following
+`getTriggeredEvents()` through `getActionsTriggeredByEvent()` to the actions it can reach,
 without reading a single handler.

package/docs/EXPRESSIONS.md

@@ -1,6 +1,6 @@
 # Expressions
 
-Axiom 0.8.0-alpha.1. An expression describes **what value is computed**. It is a tree of
+Axiom 0.8.2-alpha.1. 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.8.0-alpha.1. The `ApplicationGraph` is the authoritative representation of an
+Axiom 0.8.2-alpha.1. 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.
 
@@ -25,7 +25,7 @@ edited.
 ## API
 
 ```ts
-const graph = new ApplicationGraph(id, name, version?);   // version defaults to '0.8.0'
+const graph = new ApplicationGraph(id, name, version?);   // version defaults to '0.8.2'
 
 graph.addNode<T>(node): NodeId        // generates an id if omitted; throws if it exists
 graph.getNode<T>(id): T | undefined   // deep clone

package/docs/INTEGRATIONS.md

@@ -1,6 +1,6 @@
 # Integrations
 
-Axiom 0.8.0-alpha.1. How an application declares and calls an external system, without
+Axiom 0.8.2-alpha.1. 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.
 
@@ -85,6 +85,40 @@ that does not conform is never handed to the application as `unknown` — it is
 `INTEGRATION_RESULT_INVALID` (a runtime diagnostic; see [`RUNTIME.md`](RUNTIME.md)) before
 `ref(bindAs)` would ever resolve to it.
 
+## Timeout
+
+**The Axiom runtime enforces `timeoutMs`, not the adapter.** `queryIntegration` races
+`adapter.query(...)` against a `ServerHost.scheduleOnce(timeoutMs, ...)` deadline (spec 8.1
+§15-25) — a non-cooperating adapter whose promise never settles cannot wedge the semantic
+invocation, or by extension a polling interval trigger, forever. On timeout, the invocation
+fails with `INTEGRATION_TIMEOUT` immediately; the adapter's promise is never cancelled (Axiom
+cannot know whether that is safe for an arbitrary provider call), but if it eventually
+settles, that result is simply discarded — it can never mutate state or fire a follow-up,
+because the deadline already answered pre-transaction.
+
+An adapter MAY still race its own deadline internally (`createHttpIntegrationAdapter` does,
+via `AbortController`) to cancel the underlying provider call early, but this is an
+optimization, never a correctness requirement: the runtime's own enforcement is what a graph
+author can rely on regardless of which adapter is registered.
+
+### A hung query delays other work, bounded by `timeoutMs` (spec 8.2 §40-42)
+
+The Axiom authority executes every invocation it runs — an ordinary client request, a
+trigger tick, an effect-outcome event dispatch — through one serialized FIFO queue
+(`AxiomServer`'s internal `serialize`, spec 8.1 §26-30). A query that hangs therefore does
+not merely block *its own* invocation: it also blocks whatever unrelated request happened
+to queue up behind it, even one that shares no state, integration or trigger with it at
+all. This is expected, not a bug to route around — it is what makes same-instant triggers
+commit one at a time identically on the deterministic and the real host.
+
+**The delay this can cause is bounded by `timeoutMs`, never indefinite.** The hung query
+itself cannot run past its declared deadline (above), so the request queued behind it is
+released as soon as that deadline fires — worst case, `timeoutMs`, not forever. Do not
+introduce concurrent query execution to remove this delay; the observed serialization is
+correct under the current authority model (spec 8.2 §41) and changing it is out of scope.
+See `'a hung query delays a genuinely unrelated queued Action, bounded by timeoutMs'`
+(`packages/server/test/timeout-and-scheduling.test.ts`) for the regression test.
+
 ## Registering an adapter
 
 ```ts
@@ -113,9 +147,12 @@ REST service: a base URL, a method and a path template per operation (`{param}`
 substituted from the operation's arguments), a JSON body built from the remaining
 arguments, and a timeout via `AbortController`. It is explicitly not the canonical
 integration model — a typed `IntegrationOperationDef` is — only a way to prove one works
-without writing a bespoke adapter for a demo. `createFakeIntegrationAdapter({ query?,
-effect? })` returns deterministic, caller-supplied results: what conformance fixtures and
-tests use, since semantics must never depend on a real network call.
+without writing a bespoke adapter for a demo. `createFakeIntegrationAdapter({ query?, effect? })` returns deterministic, caller-supplied
+results: what conformance fixtures and tests use, since semantics must never depend on a
+real network call. Its callbacks receive the same `context` (`{ timeoutMs }` for a query,
+`{ idempotencyKey }` for an effect) the real `IntegrationAdapter` interface does, so a test
+can simulate a hanging call, a declared timeout, or a stable idempotency key without
+dropping to a hand-written adapter.
 
 ## Validation
 

package/docs/LOCATIONS.md

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

package/docs/PRESENTATION.md

@@ -1,6 +1,6 @@
 # Presentation
 
-Axiom 0.8.0-alpha.1. Presentation is **semantic UX intent**, expressed as data on a UI
+Axiom 0.8.2-alpha.1. 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/RUNTIME.md

@@ -1,6 +1,6 @@
 # Runtime
 
-Axiom 0.8.0-alpha.1. The runtime executes an `ApplicationIR`. It is domain-independent: it
+Axiom 0.8.2-alpha.1. 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.8.0-alpha.1. Runtime guarantees, stated formally. This file defines behavior; it
+Axiom 0.8.2-alpha.1. 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.8.0-alpha.1. A `StateDef` is a named application value: stored, or computed from
+Axiom 0.8.2-alpha.1. A `StateDef` is a named application value: stored, or computed from
 other state.
 
 ```ts

package/docs/TRIGGERS.md

@@ -1,6 +1,6 @@
 # Triggers
 
-Axiom 0.8.0-alpha.1. A `TriggerDef` says **when** an action should be invoked, without
+Axiom 0.8.2-alpha.1. 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.
@@ -44,6 +44,14 @@ can only be satisfied by a real, authenticated principal is correctly refused wh
 trigger targets it; this is not a special case in the authorization check, it is the
 ordinary one applied to a `null` principal, exactly as an anonymous client request gets.
 
+`source: 'system'` is also what `invocation.allowedSources` checks (spec 8.1 §3-14, full
+model in [`AUTHORITY.md`](AUTHORITY.md#invocation-source)): an action meant only to be a
+trigger's target — an effect's `succeededEventId`/`failedEventId` handler, a webhook's — can
+declare `invocation: { allowedSources: ['system'] }` so an anonymous client that guessed its
+id cannot invoke it directly. A trigger targeting an action that has opted out of
+`'system'` entirely is rejected at validation (`TRIGGER_TARGET_SOURCE_MISMATCH`), since the
+trigger could then never succeed.
+
 ## Where a trigger executes
 
 Derived from where its target action executes, not declared:
@@ -60,10 +68,26 @@ triggers targeting a server-authority one, are rejected at validation
 (`TRIGGER_WRONG_AUTHORITY`) — the mismatch can never reach a runtime that would silently
 do nothing with it.
 
-**Client-authority `interval`/`delay`/`route-enter`/`route-leave` triggers compile into
-`ApplicationIR.triggers` for inspection, but the browser runtime does not yet schedule or
-execute them.** Only the authoritative runtime does, today. See [Not in
-0.8.0](AUTHORITY.md#not-in-080).
+**A client-authority trigger of a kind the browser cannot execute is a validation error,
+not a silent no-op — for any call that actually names the browser's capabilities.** The
+browser runtime implements no trigger kind at all today
+(`BROWSER_TRIGGER_CAPABILITIES.supportedTriggerKinds` is empty), so `compileToIR` — which
+applies `BROWSER_TRIGGER_CAPABILITIES` by default — and `validateForBrowser` both reject
+such a trigger with `CLIENT_TRIGGER_UNSUPPORTED`, the same capability-gate pattern
+`RendererCapabilities` already applies to UI node kinds. Before spec 8.1, the trigger
+validated and compiled into `ApplicationIR.triggers` and simply never fired, which is
+exactly the "publicly declared, typechecks, passes validation, has no defined runtime
+behaviour" shape the framework forbids.
+
+**`validateGraph(graph)` with no options is target-neutral by design (spec 8.2 §2-4) and
+does not raise `CLIENT_TRIGGER_UNSUPPORTED`** — a graph is never rejected for a trigger
+runtime nobody named, exactly as it is never rejected for a renderer nobody named. A
+validate-only workflow that wants the browser-real answer without compiling calls
+`validateForBrowser(graph)` (`@cynodia/axiom-compiler`) instead of the bare call; both it
+and `compileToIR` apply the identical `BROWSER_TRIGGER_CAPABILITIES`, so they never
+disagree. Compiling for a trigger runtime that *does* implement a kind
+(`compileToIR(graph, { triggerRuntime })`) accepts it. Only the authoritative runtime
+executes triggers today. See [Not in 0.8.0](AUTHORITY.md#not-in-080).
 
 ## Interval semantics
 
@@ -142,6 +166,23 @@ No test verifying interval/delay behavior needs to wait on a real second (spec
 `advance(ms)` fires every host timer that becomes due, re-scheduling intervals, in the
 order they would fire on a real clock.
 
+**Every invocation — client request or trigger tick — is serialized against every other one
+this authority runs** (spec 8.1 §26-30), the same FIFO ordering `AxiomServer.handle()`
+already gave client requests. `advance(ms)` firing several same-period triggers in one call
+does not race their commits against each other: each waits its turn, exactly as it would
+under real, staggered timer callbacks. This is why the deterministic host and the real host
+agree on outcome for the same schedule — the ordering guarantee does not depend on which
+host is running. Only the overlap check itself (`inFlight`, above) runs unserialized, since
+it exists specifically to detect *concurrent* ticks of the *same* trigger, which requires
+running immediately when the timer fires.
+
+**A hung query cannot wedge a trigger forever.** `integration-query`'s `timeoutMs` is
+enforced by the runtime itself (spec 8.1 §15-25, full model in
+[`INTEGRATIONS.md`](INTEGRATIONS.md#timeout)) — a non-cooperating adapter's promise that
+never settles still causes the invocation, and therefore the tick, to fail within
+`timeoutMs`, clearing `inFlight` so the next scheduled tick runs normally instead of being
+skipped as an overlap forever.
+
 ## Validation
 
 | Code | Raised when |
@@ -150,6 +191,8 @@ order they would fire on a real clock.
 | `TRIGGER_INTERVAL_NOT_POSITIVE` | `everyMs`/`afterMs` is not a positive number. |
 | `UNKNOWN_EVENT` | An `event` trigger's `eventId` does not resolve to an `EventDef`. |
 | `TRIGGER_WRONG_AUTHORITY` | An authority mismatch between the trigger kind and its target action, described above. |
+| `TRIGGER_TARGET_SOURCE_MISMATCH` | The target action's `invocation.allowedSources` excludes `'system'`, so this trigger could never invoke it. |
+| `CLIENT_TRIGGER_UNSUPPORTED` | A client-authority trigger of a kind the named trigger runtime does not execute. |
 
 Full table: [`VALIDATION.md`](VALIDATION.md#integrations-effects-triggers-and-events).
 
@@ -159,7 +202,12 @@ Full table: [`VALIDATION.md`](VALIDATION.md#integrations-effects-triggers-and-ev
 agent.getTriggersForAction(actionId);        // TriggerDef[]
 agent.getTimedTriggers();                    // TriggerDef[] — interval and delay only
 agent.getActionsTriggeredByEvent(eventId);    // ActionDef[]
+agent.getSystemOnlyActions();                 // ActionDef[] — invocation.allowedSources excludes 'client'
+agent.getTriggersTargetingClientOnlyActions(); // TriggerDef[] — could never succeed
+agent.isClientInvocable(actionId);            // boolean
+agent.isSystemOnly(actionId);                 // boolean
 ```
 
 "What runs automatically" and "what happens every 5 seconds" (spec §78) are answerable
-without reading source.
+without reading source, and so is "which actions are reachable only by a trigger, event or
+effect outcome" (spec 8.1 §13).

package/docs/UI.md

@@ -1,6 +1,6 @@
 # UI
 
-Axiom 0.8.0-alpha.1. Eleven semantic UI node kinds describe **what exists and what it does**.
+Axiom 0.8.2-alpha.1. 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.8.0-alpha.1. Validation is authoring-time structural checking. It is not the same
+Axiom 0.8.2-alpha.1. 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.
 
@@ -130,6 +130,9 @@ Full model: [`INTEGRATIONS.md`](INTEGRATIONS.md), [`EFFECTS.md`](EFFECTS.md),
 | `TRIGGER_INTERVAL_NOT_POSITIVE` | An `interval` trigger's `everyMs`, or a `delay` trigger's `afterMs`, that is not a positive number. |
 | `UNKNOWN_EVENT` | An event id that does not resolve to an `EventDef` — a trigger's `eventId`, or an `integration-effect`'s `succeededEventId`/`failedEventId`. |
 | `TRIGGER_WRONG_AUTHORITY` | An `event` trigger targeting a client-authority action (only the server dispatches events), or a `route-enter`/`route-leave` trigger targeting a server-authority one (only the client router dispatches those). |
+| `TRIGGER_TARGET_SOURCE_MISMATCH` | A trigger — which always invokes with `source: 'system'` — targets an action whose `invocation.allowedSources` excludes `'system'`; the trigger could never succeed (spec 8.1 §3-9). |
+| `INVALID_INVOCATION_SOURCE` | `ActionDef.invocation.allowedSources` is present but empty — the action could never be invoked at all. |
+| `CLIENT_TRIGGER_UNSUPPORTED` | A client-authority trigger of a kind the intended trigger runtime does not execute — before 8.1 this validated and compiled anyway, and simply never fired (spec 8.1 §31-36). The browser trigger runtime executes no kind today. Only raised when a `triggerRuntime` is actually named — `validateGraph(graph)` with no options is target-neutral and never raises it; `validateForBrowser(graph)`/`compileToIR(graph)` name the real browser capabilities and do (spec 8.2 §2-6). The message states the remediation: move the target action to server authority, or compile for a trigger runtime that publishes the kind. |
 
 ### UI and routing
 

package/package.json

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