@cynodia/axiom 0.8.0-alpha.1 → 0.8.1-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.1-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.1-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.1-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:
@@ -605,12 +605,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,7 +631,7 @@ 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
@@ -639,6 +640,8 @@ agent.getActionsUsingIntegration(id) / agent.getEffectsForAction(actionId);
 agent.getTriggersForAction(actionId) / agent.getTimedTriggers();
 agent.getActionsTriggeredByEvent(eventId) / agent.getWebhookEvents();
 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:
@@ -651,8 +654,9 @@ Portable artifacts, for a runtime written in another language:
 ```
 
 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
 

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.1-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.1-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:
 
@@ -725,7 +768,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.1-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.1-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,10 @@ 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).
+
 ## Effect status and observability
 
 ```ts
@@ -107,12 +111,37 @@ mutation, and mixing the two would misrepresent what actually happened (spec §7
 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):
+
+```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) });
+```
 
-- **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.
+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.

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.1-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,

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.1-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.1-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.
 

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.1-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,22 @@ 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.
+
 ## Registering an adapter
 
 ```ts
@@ -113,9 +129,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.1-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.1-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.1-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.1-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.1-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.1-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,16 @@ 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.** The browser runtime implements no trigger kind at all today
+(`BROWSER_TRIGGER_CAPABILITIES.supportedTriggerKinds` is empty), so `validateGraph`/
+`compileToIR` 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. 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 +156,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 +181,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 +192,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.1-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.1-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. |
 
 ### UI and routing
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cynodia/axiom",
-  "version": "0.8.0-alpha.1",
+  "version": "0.8.1-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.1-alpha.1",
+    "@cynodia/axiom-runtime": "0.8.1-alpha.1",
+    "@cynodia/axiom-compiler": "0.8.1-alpha.1",
+    "@cynodia/axiom-agent-api": "0.8.1-alpha.1"
   },
   "scripts": {
     "build": "tsc -b tsconfig.json"