@cynodia/axiom 0.7.0-alpha.2 → 0.8.0-alpha.1

package/README.md

@@ -6,8 +6,8 @@ Axiom represents application behavior, state, UI structure and presentation as s
 semantic data executed by generic runtimes. An application is a typed graph, not source
 files: the JavaScript and HTML that reach the browser are output, and are never edited.
 
-**Status: experimental / alpha (0.7.0-alpha.x).** The API may change between alpha
-releases. The documentation in `docs/` describes this exact version.
+**Status: experimental / alpha.** The API may change between alpha releases. The
+documentation in `docs/` describes this exact version.
 
 ## Installation
 

package/docs/ACTIONS_TRANSACTIONS.md

@@ -1,6 +1,6 @@
 # Actions and transactions
 
-Axiom 0.7.0-alpha.2. An action is behavior expressed as data, executed as a transaction.
+Axiom 0.8.0-alpha.1. An action is behavior expressed as data, executed as a transaction.
 
 ```ts
 {
@@ -86,7 +86,7 @@ All four failure sources are evaluated; the action does not stop at the first.
 
 ## Operations
 
-Seven kinds, enumerated by `OPERATION_KINDS`. `set`, `insert` and `remove` are the
+Nine kinds, enumerated by `OPERATION_KINDS`. `set`, `insert` and `remove` are the
 mutations; each addresses a [`Location`](LOCATIONS.md).
 
 ### `set`
@@ -179,6 +179,37 @@ The controlled boundary for behavior the operation vocabulary cannot express.
 **Use it only where no semantic primitive exists.** A native operation is opaque to every
 analysis Axiom offers.
 
+### `integration-query`
+
+```ts
+{ kind: 'integration-query', operationId: NodeId, arguments?: Record<string, Expression>, bindAs: NodeId, timeoutMs?: number }
+```
+
+Calls a `mode: 'query'` `IntegrationOperationDef` and binds its result into scope: later
+operations in the same action refer to it as `ref(bindAs)`, the same way a `for-each`'s
+`scopeId` introduces the current member. Resolved **before the transaction opens**, ahead
+of guards — a query is awaited, but never mid-transaction. Never legal inside `for-each`.
+Full model: [`INTEGRATIONS.md`](INTEGRATIONS.md).
+
+### `integration-effect`
+
+```ts
+{
+  kind: 'integration-effect',
+  operationId: NodeId,
+  arguments?: Record<string, Expression>,
+  idempotencyKey?: Expression,
+  succeededEventId?: NodeId,
+  failedEventId?: NodeId,
+}
+```
+
+Calls a `mode: 'effect'` `IntegrationOperationDef`. It **never calls the adapter during the
+transaction**: reaching this operation only records intent, discarded on rollback exactly
+like a mutation is. The adapter runs only after the transaction commits, and the response
+this action's caller gets back never waits for it — "committed, effect pending." Never legal
+inside `for-each`. Full model: [`EFFECTS.md`](EFFECTS.md).
+
 ## Authorization
 
 ```ts

package/docs/AGENT_API.md

@@ -1,6 +1,6 @@
 # Agent API
 
-Axiom 0.7.0-alpha.2. The machine-facing interface. Agents query semantics and apply
+Axiom 0.8.0-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.7.0-alpha.2. Compressed operational contract. Read this plus the `.d.ts`
+Axiom 0.8.0-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.7.0'
+const graph = new ApplicationGraph(id, name);      // version defaults to '0.8.0'
 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
@@ -477,7 +477,7 @@ reads nothing from globals.
 
 ## Diagnostics
 
-23 runtime codes, all in `RUNTIME_DIAGNOSTIC_CODES`. Match on `code`, never on the message.
+30 runtime codes, all in `RUNTIME_DIAGNOSTIC_CODES`. Match on `code`, never on the message.
 Full table with `details` fields: [`RUNTIME.md`](RUNTIME.md#diagnostic-codes).
 
 ```ts
@@ -493,7 +493,7 @@ if (!result.ok) {
 ## Validation
 
 `validateGraph(graph)` → `{ valid, errors, warnings }`. `valid` is `errors.length === 0`;
-warnings never make a graph invalid. 49 codes in `VALIDATION_CODES`, grouped in
+warnings never make a graph invalid. 72 codes in `VALIDATION_CODES`, grouped in
 [`VALIDATION.md`](VALIDATION.md).
 
 ## Agent API
@@ -529,6 +529,13 @@ authoring an application that crosses the trust boundary.
 11. **IDEMPOTENCY** — a generated request id is unique across runtime instances; records are scoped by principal.
 12. **CHANGES** — `changes` names every observable state whose value moved, and no others.
 13. **PORTABILITY** — `axiom.server.v1` is frozen and language-independent.
+14. **INTEGRATION** — external systems are accessed through typed integration operations.
+15. **QUERY** — an external query is explicit action/trigger execution, never a pure `Expression`.
+16. **EFFECT** — external effects are not rollback-capable state mutations.
+17. **OUTBOX** — effect intent is committed before external execution, atomically with the state write that requested it.
+18. **TRIGGER** — triggers invoke ordinary actions, under the same guards, constraints and authorization.
+19. **EVENT** — events are typed facts; actions perform work.
+20. **SECRET** — credentials never live in graph semantics.
 
 ```ts
 { id: STATE_PRODUCTS, kind: 'state', authority: 'server' }                  // the authority owns it
@@ -590,6 +597,50 @@ through the same action-outcome lifecycle a local refusal uses — so a `diagnos
 presents a server refusal exactly as it presents a local one, and the control that started it
 renders `aria-busy` and refuses a second press until it settles.
 
+## INTEGRATIONS, EFFECTS, TRIGGERS
+
+Full model: [`INTEGRATIONS.md`](INTEGRATIONS.md), [`EFFECTS.md`](EFFECTS.md),
+[`TRIGGERS.md`](TRIGGERS.md), [`EVENTS.md`](EVENTS.md). These are the invariants to know
+before authoring an application that reaches an external system or reacts to time or an
+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.
+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.
+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`.
+
+```ts
+{ kind: 'integration', id: INTEGRATION_DEVICE_PROVIDER }
+{
+  kind: 'integration-operation', id: OP_FETCH_STATUS, integrationId: INTEGRATION_DEVICE_PROVIDER,
+  mode: 'query', resultType: primitiveType('string'),
+}
+{
+  kind: 'action', id: ACTION_REFRESH,
+  operations: [
+    { kind: 'integration-query', operationId: OP_FETCH_STATUS, bindAs: SCOPE_STATUS },
+    { kind: 'set', target: stateLocation(STATE_STATUS), value: ref(SCOPE_STATUS) },
+  ],
+}
+{ kind: 'trigger', id: TRIGGER_POLL, actionId: ACTION_REFRESH, when: { kind: 'interval', everyMs: 5000 } }
+```
+
+- `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.
+- `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.getExternalDependencies();   // { integrations, operations } — the deployment manifest
+```
+
 Portable artifacts, for a runtime written in another language:
 
 ```

package/docs/ANTI_PATTERNS.md

@@ -1,6 +1,6 @@
 # Anti-patterns
 
-Axiom 0.7.0-alpha.2. Each of these compiles. Each is wrong. Each is followed by the correct
+Axiom 0.8.0-alpha.1. Each of these compiles. Each is wrong. Each is followed by the correct
 alternative.
 
 ## 1. Field names as entity runtime keys

package/docs/AUTHORITY.md

@@ -1,6 +1,6 @@
 # Authority
 
-Axiom 0.7.0-alpha.2. How an application crosses the trust boundary.
+Axiom 0.8.0-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
@@ -32,6 +32,13 @@ describes both halves, so there is no backend to write.
 11. **IDEMPOTENCY** — an automatically generated request id is unique across runtime instances, whatever the host's uuid provider does. See [Idempotency](#idempotency).
 12. **CHANGES** — `InvokeResponse.changes` names every observable state whose value moved, and no others. See [Observing authoritative state](#observing-authoritative-state).
 13. **PORTABILITY** — `axiom.server.v1` semantics are language-independent, defined normatively by this document, the [schemas](#machine-readable-contracts) and the [conformance fixtures](#conformance). See [Server IR v1](#server-ir-v1-is-frozen).
+14. **INTEGRATION** — external systems are accessed through typed integration operations, never through `NativeOperation` or a raw request embedded in the graph. See [External systems](#external-systems).
+15. **QUERY** — an external query is explicit action/trigger execution, resolved before the transaction it feeds opens — never a pure `Expression`. See [External systems](#external-systems).
+16. **EFFECT** — an external effect is not a rollback-capable state mutation. It is recorded as intent, and dispatched only after the transaction that requested it commits. See [External effects](#external-effects).
+17. **OUTBOX** — effect intent is committed atomically with the state write that requested it, before the adapter is ever called. See [External effects](#external-effects).
+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).
 
 ## Authority and persistence are different questions
 
@@ -311,14 +318,23 @@ Transport-independent by construction. One endpoint, semantic requests:
 ```ts
 { kind: 'snapshot', protocol: 'axiom.protocol.v1', credential?, sinceRevision? }
 { kind: 'invoke',   protocol: 'axiom.protocol.v1', actionId, arguments?, credential?, requestId? }
+{ kind: 'event',    protocol: 'axiom.protocol.v1', eventId, payload, credential? }
 ```
 
 ```ts
-{ kind: 'result',   ok, diagnostics, changes, revision, requestId?, replayed? }
-{ kind: 'snapshot', snapshot: { revision, states, partial? } }
-{ kind: 'error',    diagnostics }
+{ kind: 'result',       ok, diagnostics, changes, revision, requestId?, replayed? }
+{ kind: 'snapshot',     snapshot: { revision, states, partial? } }
+{ kind: 'error',        diagnostics }
+{ kind: 'event-result', ok, diagnostics }
 ```
 
+`event` (spec 0.8) is an **additive** request kind under the same `axiom.protocol.v1`
+identifier, not a new protocol version: unlike a Server IR document, a protocol message
+carries no document-wide vocabulary ceiling a receiver could silently misinterpret. A
+pre-0.8 server's `isServerRequest` check already rejects an unrecognized `kind` as
+malformed rather than misreading it as something else, so an older implementation degrades
+safely without needing to know the new kind exists.
+
 ### `sinceRevision`
 
 A snapshot request may name a revision the caller already holds. The answer is then
@@ -412,6 +428,13 @@ does for a local failure.
 | `CONCURRENCY_CONFLICT` | Another transaction committed the same state first. Nothing was applied. |
 | `MALFORMED_REQUEST` | The request was not an Axiom semantic request, or spoke an unknown protocol. |
 | `AUTHORITY_UNREACHABLE` | The authority could not be reached, timed out, or answered with a transport error. |
+| `EFFECT_FAILED` | An external effect's adapter reported failure after exhausting its retry policy. |
+| `TRIGGER_INVOCATION_FAILED` | A trigger's target action reported failure, or its arguments failed to evaluate. |
+| `EVENT_PAYLOAD_INVALID` | An external event's payload did not conform to its declared `EventDef.payloadType`. |
+| `TRIGGER_OVERLAP_SKIPPED` | An interval trigger's tick fired while its previous invocation was still running, and the default `'skip'` overlap policy discarded it. |
+| `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. |
 
 Two client-side codes belong to the boundary as well:
 
@@ -505,6 +528,8 @@ 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/protocol.v1.schema.json
 ```
 
@@ -523,15 +548,16 @@ 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 |
 
-`SERVER_IR_CONTRACTS` enumerates both. The rules:
+`SERVER_IR_CONTRACTS` enumerates all three. 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 produces a byte-identical `axiom.server.v1` document, and the committed v1 conformance fixtures are unchanged.
+- **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` or `expressionDefs`, and `server-ir.v1.schema.json` is byte-frozen. Vocabulary arrives under a new identifier or not at all.
+- **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.
 
 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`.
+each shipped: `server-ir.v1.schema.json`, `server-ir.v2.schema.json`, `server-ir.v3.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
@@ -598,16 +624,111 @@ result is identical to some serial order. Across processes, correctness rests on
 persistence adapter's revision check — the contract guarantees that a commit from a stale
 snapshot is refused, not that two processes coordinate.
 
-## Not in 0.7.0
+## External systems
+
+0.8 adds a typed boundary to systems Axiom does not own: an `IntegrationDef` names a
+capability domain (a shipping provider, a device fleet), and an `IntegrationOperationDef`
+names one typed operation of it, with a declared `mode: 'query' | 'effect'`. The graph
+never mentions an SDK, a host name, an HTTP client or a secret — those are supplied by an
+`IntegrationAdapter`, registered with the authority (`AxiomServerOptions.integrations`),
+keyed by integration id. **Integrations default server-only** (secrets, trust, CORS,
+auditability, deterministic authority): an operation is client-invokable only if it
+declares `clientSafe: true`, and client safety is never inferred from the absence of a
+declared secret.
+
+**A missing adapter fails `start()`, not the first invocation.** Every integration a
+document requires is checked against the registry before any request is accepted
+(`INTEGRATION_ADAPTER_MISSING`).
+
+**A query is explicit execution, never a pure `Expression`.** An `integration-query`
+operation calls its adapter and binds the (type-checked) result into scope as
+`ref(bindAs)`, resolved **before the transaction opens** — ahead of guards, so a query
+never runs mid-transaction and a guard can never reference its result. A malformed
+provider response is rejected at this boundary (`INTEGRATION_RESULT_INVALID`) rather than
+handed to the application as `unknown`. Full model: `docs/INTEGRATIONS.md`.
+
+## External effects
+
+**An external effect is not a rollback-capable state mutation**, and 0.8 does not pretend
+otherwise (spec §15,16). Axiom can roll back a state write; it cannot roll back an email,
+a payment or a shipment request.
+
+Reaching an `integration-effect` operation only **records intent** — appended to the same
+per-transaction log a mutation is, and discarded on rollback the same way. The adapter is
+never called during the transaction. Only once the transaction **commits** — effect intent
+persisted atomically with the state write that requested it, the transactional outbox
+invariant — does an `EffectRunner` dispatch it, and the response the caller receives never
+waits for that: "action committed, effect pending," not "action committed and its effect
+succeeded." A `PersistenceAdapter` that implements `loadPendingEffects`/
+`recordEffectAttempt` (both shipped adapters do) resumes any intent that was committed but
+never reached a terminal status, so a crash between commit and dispatch does not lose it —
+**at-least-once delivery**, not exactly-once. Effect operations may declare `idempotent:
+true` and a `retry` policy (`'none' | 'fixed' | 'exponential'`); an idempotency key,
+computed from `idempotencyKey`, is handed to the adapter on every attempt so a provider can
+deduplicate a retried call.
+
+An effect's outcome is never folded back into the transaction that requested it. Instead,
+its declared `succeededEventId`/`failedEventId` — an ordinary `EventDef` — is dispatched
+through the same event pipeline an external webhook uses, once the outcome is known. There
+is no automatic compensation: a semantic inverse (`refundPayment`) is another explicit
+action, never an implicit `rollback(createPayment)`. Full model: `docs/EFFECTS.md`.
+
+## Triggers
+
+A `TriggerDef` says **when** an action should be invoked — `interval`, `delay`,
+`lifecycle` (`application-start`, `runtime-ready` on the server; `route-enter`,
+`route-leave` on the client) or `event` — without embedding callback code. **A triggered
+action runs through exactly the same semantics any other caller does**: the same guards,
+constraints, transition constraints and authorization. There is no weaker, trigger-specific
+execution path.
+
+Timed and event triggers whose target action is server-authority run **on the authority**,
+continuing whether or not a browser is connected; `application-start`/`runtime-ready`
+triggers run once, in startup order, before requests are accepted (see
+[Startup](#startup)). An interval trigger's default overlap policy is `'skip'`: a tick that
+fires while the previous invocation is still running is discarded, not queued and never run
+concurrently (`TRIGGER_OVERLAP_SKIPPED`); `'queue'` runs one pending tick immediately after.
+
+**Timed and event-originated invocations run under a system context, never an impersonated
+user.** `ExecutionContext.principal` is `null` — exactly what an anonymous client request's
+is — and `.source` is `'system'`, carried only for observability. Authorization still
+evaluates against that; it is never bypassed. An action whose authorization rule can never
+be satisfied by a `null` principal is correctly refused when a trigger invokes it — the
+graph decides, by declaring authorization or not on the actions it targets. Full model:
+`docs/TRIGGERS.md`.
+
+## External events
+
+An `EventDef` is a typed fact — a webhook delivery, an effect's outcome — never work
+itself; a `TriggerDef{when:{kind:'event'}}` is what says what happens next. The semantic
+protocol's `EventRequest` (`kind: 'event'`) carries only `eventId` and `payload`; the
+payload is validated against `EventDef.payloadType` **before any action sees it**
+(`EVENT_PAYLOAD_INVALID` otherwise) — malformed input never reaches trusted code.
+
+**Provider authenticity is verified before an event is even constructed.** A webhook route
+is registered on the Node host (`serveOverHttp({ webhooks })`), never declared by the
+application: `verify` runs over the raw request first, and an unverified delivery never
+reaches `decode` or the semantic layer. A provider `deliveryId`, when supplied, is
+deduplicated against a bounded recent-deliveries window per route — a duplicate within that
+window is acknowledged without dispatching the event again, with no claim of durable,
+unbounded deduplication.
+
+**Event dispatch is depth-guarded**, so a cycle (an event whose triggered effect's own
+success re-fires it) is stopped rather than recursing unboundedly
+(`EVENT_DISPATCH_DEPTH_EXCEEDED`, `MAX_EVENT_DISPATCH_DEPTH` dispatches deep). Full model:
+`docs/EVENTS.md`.
+
+## Not in 0.8.0
 
 Stated plainly rather than left to discovery:
 
-- **Generated values cannot be bound within an action.** 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. A semantic binding for this (`bindAs` on an operation, `ref` to it later) needs a lexical lifetime, a type, `for-each` and nested-invoke semantics, serialization and dependency analysis all decided together; doing that hastily would weaken a contract that is now frozen, so it is deferred to 0.7.
+- **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.
-
-- **External effects.** A database write rolls back; an email does not. Nothing here makes an external side effect participate in a transaction, and `NativeOperation` MUST NOT be used to smuggle one in. A deliberate effect model — commands, a transactional outbox, idempotency — is future work.
+- **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.
+- **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.
 - **Relational schema generation**, migrations and ORM behaviour.
 - **Multi-node distributed execution.** Correctness is guaranteed within one authority process.
-- **File storage, background jobs, scheduling.**
+- **File storage, background worker fleets, a general job queue, a saga engine, a workflow language.** Effects and triggers are deliberately not a distributed job system (spec §2).

package/docs/CONSTRAINTS.md

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

package/docs/EFFECTS.md

@@ -0,0 +1,142 @@
+# Effects
+
+Axiom 0.8.0-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.
+
+## The operation
+
+```ts
+{
+  kind: 'integration-effect',
+  operationId: NodeId,
+  arguments?: Record<string, Expression>,
+  idempotencyKey?: Expression,
+  succeededEventId?: NodeId,
+  failedEventId?: NodeId,
+}
+```
+
+`operationId` must name an `IntegrationOperationDef` with `mode: 'effect'`
+(`INTEGRATION_OPERATION_MODE_MISMATCH` otherwise). Legal only at an action's top level,
+never inside `for-each`.
+
+## Execution model — commit, then dispatch
+
+```text
+Action
+  ↓
+state transaction opens
+  ↓
+`integration-effect` reached → intent recorded (transaction-local, like a mutation)
+  ↓
+guards / constraints / transition constraints evaluated
+  ↓
+commit — state writes AND effect intent persisted atomically (the outbox invariant)
+  ↓
+response returned to the caller: "committed, effect pending"
+  ↓
+EffectRunner dispatches the intent → IntegrationAdapter.effect(...)
+  ↓
+terminal status (succeeded/failed) → declared event dispatched, if any
+```
+
+Reaching `integration-effect` **never calls the adapter**. It only appends an intent to a
+transaction-scoped log — the same log a mutation is recorded in, `AxiomRuntime
+.getEffectIntents()`, discarded on rollback exactly the way a rolled-back mutation is. The
+adapter is called only **after** the surrounding transaction commits, by a separate
+`EffectRunner`, and the invoking request's response never waits for that call — spec §123's
+"action committed, effect pending" is literal: `outcome`/`ok` in the response describes
+whether the **state transaction** committed, not whether the effect has succeeded yet.
+
+## The outbox invariant
+
+Effect intent is committed **atomically with the state write that requested it** —
+`PersistenceAdapter.commit()` receives both `writes` and `effects` in the same call, and a
+durable adapter persists them together. `createMemoryPersistence` and
+`createSqlitePersistence` both implement the adapter's optional `loadPendingEffects()` /
+`recordEffectAttempt()` pair, so a restarted authority resumes any intent that was
+committed but never reached a terminal status — a crash between commit and the adapter
+call does not lose the intent.
+
+**Delivery is at-least-once, never exactly-once.** A resumed dispatch gets a fresh full
+retry budget rather than picking up a partially-spent one, because a process that crashed
+mid-call was never told whether its one call succeeded. This is why `idempotent: true` and
+an `idempotencyKey` matter: a provider capable of deduplicating a retried call is what
+turns at-least-once delivery into an effectively-once outcome.
+
+## Retry
+
+```ts
+retry?: { policy: 'none' | 'fixed' | 'exponential'; maxAttempts?: number; delayMs?: number }
+```
+
+Declared on the `IntegrationOperationDef`, not on the calling action — retry is an
+external-effect-execution concern, not business UI. `policy: 'none'` (the default) is one
+attempt. `'fixed'` waits `delayMs` (default 1000ms) between attempts; `'exponential'`
+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.
+
+## Effect status and observability
+
+```ts
+type EffectDispatchStatus = 'pending' | 'running' | 'succeeded' | 'failed';
+
+interface EffectRecord {
+  id: string;
+  operationId: NodeId;
+  arguments: Record<string, unknown>;
+  status: EffectDispatchStatus;
+  attempts: number;
+  lastError?: { code: string; message: string; retryable?: boolean };
+  result?: unknown;             // the adapter's returned value, once succeeded
+}
+
+server.effectLog();   // EffectRecord[]
+```
+
+`server.effectLog()` is distinct from `server.mutationLog()` — an effect is not a state
+mutation, and mixing the two would misrepresent what actually happened (spec §73). Host
+`report()` events cover the whole lifecycle: `effect-requested`, `effect-attempted`,
+`effect-succeeded`, `effect-failed`.
+
+## 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:
+
+- **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.
+
+Both are checked against the declared `EventDef.payloadType` the same way any event is,
+so a mismatched declaration is caught rather than silently dropped.
+
+## No automatic compensation
+
+0.8 does not implement compensation. If an effect has a semantic inverse, it is another
+explicit action and effect — `refundPayment`, never `rollback(createPayment)`.
+
+## Validation and diagnostics
+
+| Code | Raised when |
+| --- | --- |
+| `UNKNOWN_EVENT` | `succeededEventId`/`failedEventId` naming something that is not an `EventDef`. |
+| `EFFECT_FAILED` | An adapter reported failure after the retry policy was exhausted. |
+
+Full tables: [`VALIDATION.md`](VALIDATION.md#integrations-effects-triggers-and-events),
+[`AUTHORITY.md`](AUTHORITY.md#diagnostics).
+
+## AgentAPI
+
+```ts
+agent.getEffectsForAction(actionId);   // IntegrationOperationDef[] — the effect-mode operations it calls
+```
+
+"What can this application do to an external system, and from where" is answerable without
+reading source — spec §78's example question, made concrete.

package/docs/EVENTS.md

@@ -0,0 +1,115 @@
+# Events
+
+Axiom 0.8.0-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.
+
+## The model
+
+```ts
+interface EventDef {
+  id: NodeId;
+  kind: 'event';
+  payloadType: TypeRef;
+}
+```
+
+Nothing more: an event is a name and a typed payload. What happens when one occurs is a
+`TriggerDef{when:{kind:'event', eventId}}` — see [`TRIGGERS.md`](TRIGGERS.md). Keeping
+"a fact occurred" (`EventDef`) and "do this work" (`ActionDef`, via a trigger) as separate
+node kinds is deliberate (spec §46): an event may have zero, one or several triggers bound
+to it, and none of them is embedded in the event's own declaration.
+
+## Event vs. action
+
+| | Answers |
+| --- | --- |
+| `EventDef` | "What happened?" |
+| `ActionDef` | "What should be done about it?" |
+
+An event never mutates state itself. Only the action a trigger invokes does, through the
+ordinary governed write path.
+
+## Sources
+
+An event reaches the semantic layer three ways, and all three funnel through the same
+`dispatchEvent`/`TriggerRuntime.fireEvent` path and the same payload validation:
+
+1. **An external webhook**, decoded and verified by a registered host adapter (below).
+2. **An effect's own outcome** — `succeededEventId`/`failedEventId` on an
+   `integration-effect` operation (see [`EFFECTS.md`](EFFECTS.md)).
+3. **The semantic protocol directly** — `EventRequest{ kind: 'event', eventId, payload }`,
+   for a host that already trusts its own caller (an internal service, a test).
+
+## Payload validation
+
+Every event's payload is checked against its declared `EventDef.payloadType` — the same
+`validateValueAgainstType` walk that checks action arguments and seed data — **before any
+trigger's action runs**. A malformed payload never reaches trusted code:
+`EVENT_PAYLOAD_INVALID`, and no action is invoked.
+
+## Webhooks
+
+```ts
+import { serveOverHttp } from '@cynodia/axiom-server';
+
+await serveOverHttp({
+  server,
+  webhooks: {
+    '/webhooks/device-provider': {
+      verify: (request) => verifySignature(request.headers, request.rawBody, secret),
+      decode: (request) => {
+        const body = JSON.parse(request.rawBody.toString('utf8'));
+        return { eventId: EVENT_DEVICE_STATUS_CHANGED, payload: body.status, deliveryId: body.id };
+      },
+    },
+  },
+});
+```
+
+An application author never declares an HTTP route (spec §54) — `webhooks` is a
+*deployment* concern, registered where the Node host is stood up, and the graph never
+mentions it. `verify` runs over the **raw, unparsed request**: signature verification is
+over the exact bytes a provider signed, and it runs strictly before `decode` — an
+unverified request never reaches the semantic layer at all (`WEBHOOK_VERIFICATION_FAILED`,
+401). Provider-specific protocol — headers, signing scheme, payload shape — stays entirely
+in `verify`/`decode`; nothing crosses into `ApplicationGraph`.
+
+## Duplicate delivery
+
+`decode`'s optional `deliveryId` is deduplicated against a **bounded, per-route,
+most-recent window** (512 entries): a duplicate delivery within that window is
+acknowledged (`ok: true`) without dispatching the event again. This is not a durable,
+unbounded guarantee — a delivery older than the window, or a restart, is not remembered.
+State that. Do not claim more.
+
+## Event loop protection
+
+A cascade — an event triggers an action, whose effect's success re-fires the same event —
+is bounded: `MAX_EVENT_DISPATCH_DEPTH` (8) dispatches deep, then further dispatch stops
+(`EVENT_DISPATCH_DEPTH_EXCEEDED`) rather than recursing without limit. Depth is carried
+forward from the invocation that created an effect intent to the event its outcome
+dispatches, so the guard holds across the commit/dispatch boundary, not only within one
+synchronous call chain.
+
+## Validation and diagnostics
+
+| Code | Raised when |
+| --- | --- |
+| `UNKNOWN_EVENT` | A trigger's `eventId`, or an effect's `succeededEventId`/`failedEventId`, does not resolve to an `EventDef`. |
+| `EVENT_PAYLOAD_INVALID` | A payload does not conform to its declared `payloadType`. |
+| `EVENT_DISPATCH_DEPTH_EXCEEDED` | A cascade was stopped at the depth guard. |
+
+Full tables: [`VALIDATION.md`](VALIDATION.md#integrations-effects-triggers-and-events),
+[`AUTHORITY.md`](AUTHORITY.md#diagnostics).
+
+## AgentAPI
+
+```ts
+agent.getWebhookEvents();               // 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,
+without reading a single handler.

package/docs/EXPRESSIONS.md

@@ -1,6 +1,6 @@
 # Expressions
 
-Axiom 0.7.0-alpha.2. An expression describes **what value is computed**. It is a tree of
+Axiom 0.8.0-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.7.0-alpha.2. The `ApplicationGraph` is the authoritative representation of an
+Axiom 0.8.0-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.7.0'
+const graph = new ApplicationGraph(id, name, version?);   // version defaults to '0.8.0'
 
 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

@@ -0,0 +1,152 @@
+# Integrations
+
+Axiom 0.8.0-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.
+
+## The model
+
+```ts
+interface IntegrationDef {
+  id: NodeId;
+  kind: 'integration';
+  name?: string;
+}
+
+interface IntegrationOperationDef {
+  id: NodeId;
+  kind: 'integration-operation';
+  integrationId: NodeId;
+  mode: 'query' | 'effect';
+  parameters?: IntegrationOperationParameter[];
+  resultType: TypeRef;
+  clientSafe?: boolean;
+  idempotent?: boolean;
+  retry?: { policy: 'none' | 'fixed' | 'exponential'; maxAttempts?: number; delayMs?: number };
+}
+
+interface IntegrationOperationParameter {
+  id: NodeId;
+  name?: string;
+  valueType: TypeRef;
+  required?: boolean;
+}
+```
+
+`IntegrationDef` names a capability domain — a shipping provider, a device fleet, a
+payments processor. `IntegrationOperationDef` is one typed operation of it. Neither ever
+carries an SDK name, a host name, a secret or an HTTP client: those live in the host, as an
+`IntegrationAdapter` (`@cynodia/axiom-server`), registered by integration id.
+
+**`INTEGRATION_OPERATION_MODES`** is `['query', 'effect']`, and the distinction is
+load-bearing:
+
+| Mode | Meaning | May its result feed the same transaction? | Rollback-capable? |
+| --- | --- | --- | --- |
+| `'query'` | Observes the external system; does not intentionally mutate it. | Yes — bound into scope, resolved before the transaction opens. | N/A — nothing to roll back. |
+| `'effect'` | May mutate or cause an irreversible external consequence. | No — its outcome reaches state only through a follow-up action invoked from a dispatched event. | **No.** See [`EFFECTS.md`](EFFECTS.md). |
+
+`clientSafe` defaults to absent, which means server-only. Client safety is never inferred
+from the absence of a declared secret — it is stated, or it is not granted.
+
+## Calling an operation
+
+Two new `Operation` kinds, added to `OPERATION_KINDS`; both are legal only at an action's
+top level, never nested inside a `for-each`:
+
+```ts
+{ kind: 'integration-query', operationId: NodeId, arguments?: Record<string, Expression>, bindAs: NodeId, timeoutMs?: number }
+{ kind: 'integration-effect', operationId: NodeId, arguments?: Record<string, Expression>, idempotencyKey?: Expression, succeededEventId?: NodeId, failedEventId?: NodeId }
+```
+
+`integration-query` calls its adapter and binds the (type-checked) result into scope:
+later operations in the same action refer to it as `ref(bindAs)`, the same way a
+`for-each`'s `scopeId` introduces the current member — except the whole result is bound,
+not a collection member. Resolution happens **before the transaction opens**, ahead of
+every guard: guards are validated against the scope as it stood before any
+`integration-query`, so a guard can never reference `ref(bindAs)` — that is checked
+statically, not merely documented. Full operation semantics: [`ACTIONS_TRANSACTIONS.md`
+§ `integration-query`](ACTIONS_TRANSACTIONS.md#integration-query).
+
+`integration-effect` is described in [`EFFECTS.md`](EFFECTS.md).
+
+## Expression purity is unaffected
+
+`Expression` evaluation stays pure with respect to external systems: nothing in
+`EXPRESSION_KINDS` performs I/O, and this is unchanged by 0.8. An integration query is
+reached only through an explicit `Operation`, never through an `Expression` — there is no
+`fieldDisplay.value = queryWeather()`. A pure `Expression` remains deterministic over
+semantic state alone.
+
+## Result typing
+
+A provider's response is checked against `resultType` at the adapter boundary. A response
+that does not conform is never handed to the application as `unknown` — it is rejected as
+`INTEGRATION_RESULT_INVALID` (a runtime diagnostic; see [`RUNTIME.md`](RUNTIME.md)) before
+`ref(bindAs)` would ever resolve to it.
+
+## Registering an adapter
+
+```ts
+import { createAxiomServer, createFakeIntegrationAdapter, createHttpIntegrationAdapter } from '@cynodia/axiom-server';
+
+const server = createAxiomServer({
+  ir: compileToServerIR(graph),
+  integrations: {
+    [INTEGRATION_DEVICE_PROVIDER]: createHttpIntegrationAdapter({
+      baseUrl: 'https://devices.example.com/',
+      operations: {
+        [OPERATION_FETCH_STATUS]: { method: 'GET', path: 'devices/{deviceId}/status' },
+        [OPERATION_REBOOT]: { method: 'POST', path: 'devices/{deviceId}/reboot' },
+      },
+    }),
+  },
+});
+```
+
+`createAxiomServer.start()` refuses to start if any integration the Server IR requires has
+no registered adapter (`INTEGRATION_ADAPTER_MISSING`) — checked once, at startup, never
+deferred to the first request that happens to need it.
+
+`createHttpIntegrationAdapter` is a generic, lower-level reference adapter for an arbitrary
+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.
+
+## Validation
+
+| Code | Raised when |
+| --- | --- |
+| `UNKNOWN_INTEGRATION` | An `IntegrationOperationDef.integrationId` that does not resolve to an `integration` node. |
+| `UNKNOWN_INTEGRATION_OPERATION` | An `integration-query`/`integration-effect` operation's `operationId` that does not resolve to an `integration-operation` node. |
+| `INTEGRATION_OPERATION_MODE_MISMATCH` | An `integration-query` naming an effect operation, or the reverse. |
+| `INTEGRATION_ARGUMENT_MISMATCH` | A missing required argument, or one the operation declares no parameter for. |
+
+Full table: [`VALIDATION.md`](VALIDATION.md#integrations-effects-triggers-and-events).
+
+## Runtime diagnostics
+
+| Code | Meaning |
+| --- | --- |
+| `INTEGRATION_UNAVAILABLE` | An `integration-query` operation ran, but no host capable of executing one is configured. |
+| `INTEGRATION_TIMEOUT` | A query did not answer within its declared `timeoutMs`. |
+| `INTEGRATION_RESULT_INVALID` | A provider's response did not conform to `resultType`. |
+| `INTEGRATION_QUERY_FAILED` | A query failed for any other reason. Never carries a provider secret. |
+
+Full table: [`RUNTIME.md`](RUNTIME.md#diagnostic-codes).
+
+## AgentAPI
+
+```ts
+agent.listIntegrations();                          // IntegrationDef[]
+agent.listIntegrationOperations(integrationId?);    // IntegrationOperationDef[]
+agent.getActionsUsingIntegration(integrationId);    // ActionDef[]
+agent.getExternalDependencies();                    // { integrations, operations }
+```
+
+`getExternalDependencies()` is the machine-discoverable manifest spec §115 asks for — what
+an application requires before it can be deployed.

package/docs/LOCATIONS.md

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

package/docs/PRESENTATION.md

@@ -1,6 +1,6 @@
 # Presentation
 
-Axiom 0.7.0-alpha.2. Presentation is **semantic UX intent**, expressed as data on a UI
+Axiom 0.8.0-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.7.0-alpha.2. The runtime executes an `ApplicationIR`. It is domain-independent: it
+Axiom 0.8.0-alpha.1. The runtime executes an `ApplicationIR`. It is domain-independent: it
 contains no knowledge of any application.
 
 ## Constructing
@@ -50,9 +50,15 @@ interface HostEnvironment {
   uuid(): string;
   storage?: { read(key): string | null; write(key, value): void };
   report?(message: string): void;
+  queryIntegration?(operationId: string, args, options: { timeoutMs? }): Promise<IntegrationQueryOutcome>;
 }
 ```
 
+`queryIntegration` is only ever called by the authoritative runtime executing an
+`integration-query` operation. A browser host never implements it: no client-compiled
+action ever contains one, because integrations default server-only. See
+[`INTEGRATIONS.md`](INTEGRATIONS.md).
+
 Memory-host helpers for driving and inspecting a rendered tree: `findAll`, `findByNodeId`,
 `findByTag`, `textOf`, `typeInto`, `toggle`, `click`, `submit`. Every rendered element
 carries `data-node="<node id>"`.
@@ -72,12 +78,14 @@ carries `data-node="<node id>"`.
 | `clearDiagnostics()` | — | Empties the running log **and** every recorded action outcome. |
 | `getActionOutcome(id)` | — | The outcome of that action's most recent invocation. See below. |
 | `getMutationLog()` | — | Every attempted mutation, with source, path and outcome. |
+| `getEffectIntents()` | — | Every `integration-effect` intent recorded so far — a log distinct from the mutation log, because an effect is not a state mutation. See [`EFFECTS.md`](EFFECTS.md). |
 | `registerNativeOperation(id, fn)` | — | Registers an implementation for a `native` operation. |
-| `invokeActionAsync(id, args?)` | **yes** | Awaits the outcome, including an authority's answer. |
+| `invokeActionAsync(id, args?)` | **yes** | Awaits the outcome, including an authority's answer. For an action with a top-level `integration-query` operation, this is also what awaits the query itself — see [`INTEGRATIONS.md`](INTEGRATIONS.md). |
 | `syncAuthoritativeState()` | — | Loads the authoritative snapshot and applies it. Idempotent; may be called at any time. See [`AUTHORITY.md`](AUTHORITY.md). |
 | `authoritativeStateLoaded()` | — | Whether a snapshot has been applied. `false` also after a failed load, which is why it is not the same question as "is this collection empty". |
 | `settled()` | — | Resolves when no remote invocation is outstanding. An action started by a click or a form submit leaves no promise for a caller to hold; this is how to wait for it without guessing a delay. |
 | `evaluate(expression)` | — | Evaluates in the root scope, reporting rather than throwing. A pure read. |
+| `evaluateWithBindings(expression, bindings)` | — | Evaluates with extra ids bound in scope, keyed by id. How a trigger's `arguments`/`enabledWhen` resolve `ref()` of the trigger's own id to read an event payload. |
 
 ### `hydrateState` bypasses semantic enforcement
 
@@ -214,6 +222,10 @@ interface RuntimeDiagnostic {
 | `NATIVE_OPERATION_MISSING` | No implementation registered for an `implementationId`. | `native` operation | — |
 | `REMOTE_ACTION_UNAVAILABLE` | An action belonging to the authority was invoked with no gateway configured, or the transport failed. | remote invocation | — |
 | `AUTHORITY_UNREACHABLE` | **Warning.** `start()` could not load authoritative state: no answer from the authority. The page renders with what it has, and `authoritativeStateLoaded()` stays false. | startup | — |
+| `INTEGRATION_UNAVAILABLE` | An `integration-query` operation ran, but the host has no `queryIntegration` capability configured. | `integration-query` | — |
+| `INTEGRATION_TIMEOUT` | An integration query did not answer within its declared `timeoutMs`. | `integration-query` | `operationId` |
+| `INTEGRATION_RESULT_INVALID` | A provider's response did not conform to the operation's declared `resultType`. | `integration-query` | `operationId` |
+| `INTEGRATION_QUERY_FAILED` | An integration query failed for any other reason. Never carries a provider secret. | `integration-query` | `operationId`, `retryable` |
 | `UI_NODE_MISSING` | A child id that is not a UI node in the IR. | render | — |
 | `UNSUPPORTED_UI_NODE` | An unknown UI node kind. | render | — |
 | `PERSISTED_STATE_UNREADABLE` | **Warning.** A stored value could not be parsed; the initial value was used. | startup | — |

package/docs/SEMANTIC_CONTRACT.md

@@ -1,6 +1,6 @@
 # Semantic contract
 
-Axiom 0.7.0-alpha.2. Runtime guarantees, stated formally. This file defines behavior; it
+Axiom 0.8.0-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.7.0-alpha.2. A `StateDef` is a named application value: stored, or computed from
+Axiom 0.8.0-alpha.1. A `StateDef` is a named application value: stored, or computed from
 other state.
 
 ```ts

package/docs/TRIGGERS.md

@@ -0,0 +1,165 @@
+# Triggers
+
+Axiom 0.8.0-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.
+
+## The model
+
+```ts
+interface TriggerDef {
+  id: NodeId;
+  kind: 'trigger';
+  actionId: NodeId;
+  when: TriggerSpec;
+  arguments?: Record<string, Expression>;
+  enabledWhen?: Expression;
+}
+
+type TriggerSpec =
+  | { kind: 'interval'; everyMs: number; overlap?: 'skip' | 'queue' }
+  | { kind: 'delay'; afterMs: number }
+  | { kind: 'lifecycle'; event: 'application-start' | 'runtime-ready' | 'route-enter' | 'route-leave'; routeId?: NodeId }
+  | { kind: 'event'; eventId: NodeId };
+```
+
+`TRIGGER_KINDS` is `['interval', 'delay', 'lifecycle', 'event']`. `everyMs`/`afterMs` are
+plain numbers, never expressions — scheduling stays static; only `enabledWhen` is dynamic,
+evaluated each time the trigger would otherwise fire. This is deliberate (spec §62): a
+rapidly-changing interval would be a scheduling platform, which 0.8 is not (spec §58).
+
+## A trigger invokes an action exactly as any other caller does
+
+**There is no weaker execution path for a triggered action** (spec §102). The same
+`invoke` pipeline the client's `InvokeRequest` uses runs it: the same argument checking,
+the same authorization evaluation, the same guards, the same transaction, the same
+constraints and transition constraints. A constraint violation from a triggered action
+rolls back exactly like one from a client request does.
+
+The one thing that differs is who is asking: a triggered invocation runs under
+`ExecutionContext.principal: null`, `source: 'system'` — no credential is authenticated,
+because there is no caller to authenticate (spec §68). An action whose `.authorization`
+can only be satisfied by a real, authenticated principal is correctly refused when a
+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.
+
+## Where a trigger executes
+
+Derived from where its target action executes, not declared:
+
+| `when.kind` | Runs | Because |
+| --- | --- | --- |
+| `interval`, `delay` | server, if the target action is server-authority; otherwise client | either authority can run a timer |
+| `lifecycle: 'application-start' \| 'runtime-ready'` | server | these are authority startup moments |
+| `lifecycle: 'route-enter' \| 'route-leave'` | client | routes are a client-IR concept |
+| `event` | server | only the server dispatches events |
+
+`event` triggers targeting a client-authority action, and `route-enter`/`route-leave`
+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).
+
+## Interval semantics
+
+```ts
+{ kind: 'interval', everyMs: 5000, overlap?: 'skip' | 'queue' }   // overlap defaults to 'skip'
+```
+
+- First execution is `everyMs` after the trigger runtime starts — there is no
+  fire-immediately option.
+- `overlap: 'skip'` (default): a tick that fires while the previous invocation of the same
+  trigger is still running is discarded — reported as `TRIGGER_OVERLAP_SKIPPED` — never
+  queued and never run concurrently with it.
+- `overlap: 'queue'`: one pending tick runs immediately after the in-flight one finishes.
+  Never more than one queued at a time.
+- A failed invocation (a refused guard, a rolled-back constraint) is reported the ordinary
+  way and does not cancel the schedule; the next tick still fires.
+
+## Lifecycle triggers and startup order
+
+`application-start` and `runtime-ready` triggers fire once, in that order, as the last
+step of `AxiomServer.start()` — after persistence has loaded, effect resumption has begun,
+and every required integration adapter has been validated present, and before any request
+is accepted:
+
+```text
+load IR → initialize persistence → restore state → initialize adapters →
+validate required capabilities → runtime-ready triggers run → accept requests
+```
+
+(`application-start` triggers run first, ahead of `runtime-ready`, within that same step.)
+
+## Event triggers and the payload scope
+
+```ts
+{ kind: 'event', eventId: EVENT_DEVICE_STATUS_CHANGED }
+```
+
+An `event`-kind trigger's `arguments`/`enabledWhen` may `ref` **the trigger's own id** to
+read the event's payload — the same mechanism a `for-each`/`map`'s `scopeId` provides,
+except the whole payload is bound, not a collection member:
+
+```ts
+graph.addNode<TriggerDef>({
+  id: TRIGGER_STATUS_CHANGED,
+  kind: 'trigger',
+  actionId: ACTION_APPLY_STATUS,
+  when: { kind: 'event', eventId: EVENT_DEVICE_STATUS_CHANGED },
+  arguments: { [String(PARAM_STATUS)]: ref(TRIGGER_STATUS_CHANGED) },
+});
+```
+
+Full event semantics: [`EVENTS.md`](EVENTS.md).
+
+## Enablement
+
+```ts
+enabledWhen?: Expression
+```
+
+Evaluated each time the trigger would otherwise fire; a `false`/unevaluable result means
+this occurrence does not run, but the schedule continues. This is the mechanism for
+"poll only while the integration is enabled" (spec §61) — dynamic enablement, never a
+dynamic interval.
+
+## A deterministic test clock
+
+```ts
+const host = createDeterministicServerHost();
+const server = createAxiomServer({ ir, host, integrations });
+await server.start();
+
+host.advance(5000);   // fires every timer due within the next 5000ms, in due-time order
+```
+
+No test verifying interval/delay behavior needs to wait on a real second (spec §85,141).
+`advance(ms)` fires every host timer that becomes due, re-scheduling intervals, in the
+order they would fire on a real clock.
+
+## Validation
+
+| Code | Raised when |
+| --- | --- |
+| `TRIGGER_ACTION_NOT_FOUND` | `actionId` does not resolve to an action. |
+| `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. |
+
+Full table: [`VALIDATION.md`](VALIDATION.md#integrations-effects-triggers-and-events).
+
+## AgentAPI
+
+```ts
+agent.getTriggersForAction(actionId);        // TriggerDef[]
+agent.getTimedTriggers();                    // TriggerDef[] — interval and delay only
+agent.getActionsTriggeredByEvent(eventId);    // ActionDef[]
+```
+
+"What runs automatically" and "what happens every 5 seconds" (spec §78) are answerable
+without reading source.

package/docs/UI.md

@@ -1,6 +1,6 @@
 # UI
 
-Axiom 0.7.0-alpha.2. Eleven semantic UI node kinds describe **what exists and what it does**.
+Axiom 0.8.0-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.7.0-alpha.2. Validation is authoring-time structural checking. It is not the same
+Axiom 0.8.0-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.
 
@@ -36,7 +36,7 @@ non-numeric collections, and obviously incompatible assignments.
 
 ## Codes
 
-55 codes, exported as `VALIDATION_CODES`. Every one is reachable.
+72 codes, exported as `VALIDATION_CODES`. Every one is reachable.
 
 ### Ids and references
 
@@ -115,6 +115,22 @@ Recursive, with a `path` naming the position.
 | `MISSING_IDENTITY_FIELD` | A transition constraint on an entity that declares no `identityFieldId`. |
 | `UNSUPPORTED_CONSTRAINT_SCOPE` | A constraint scope the runtime cannot evaluate. |
 
+### Integrations, effects, triggers and events
+
+Full model: [`INTEGRATIONS.md`](INTEGRATIONS.md), [`EFFECTS.md`](EFFECTS.md),
+[`TRIGGERS.md`](TRIGGERS.md), [`EVENTS.md`](EVENTS.md).
+
+| Code | Raised when |
+| --- | --- |
+| `UNKNOWN_INTEGRATION` | An `IntegrationOperationDef.integrationId` that does not resolve to an `integration` node. |
+| `UNKNOWN_INTEGRATION_OPERATION` | An `integration-query`/`integration-effect` operation's `operationId` that does not resolve to an `integration-operation` node. |
+| `INTEGRATION_OPERATION_MODE_MISMATCH` | An `integration-query` naming an operation whose `mode` is `'effect'`, or an `integration-effect` naming one whose `mode` is `'query'`. |
+| `INTEGRATION_ARGUMENT_MISMATCH` | A missing required argument to an integration operation, or an argument it declares no parameter for. |
+| `TRIGGER_ACTION_NOT_FOUND` | A `TriggerDef.actionId` that does not resolve to an action. |
+| `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). |
+
 ### UI and routing
 
 | Code | Raised when | Severity |

package/package.json

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