Event Interposition

Event Interposition is a primitive class of hooks that fire at lifecycle boundaries and can modify or block the transitions they observe.

Mechanics

An interposition hook attaches to a named lifecycle event -- session start, tool invocation, response emission, session end -- and executes synchronously at the boundary. The distinguishing property is not merely observation but the capacity to intervene: the hook can mutate the payload, suppress the action, or halt the transition entirely. This separates interposition from passive logging or post-hoc auditing.

Two known members of this class, both changelog-derived:

• Skill hooks -- hooks scoped to a skill's own lifecycle events, which instance-of Event Interposition.
• once: true hooks -- hooks configured to fire exactly once per lifecycle scope, which also instance-of Event Interposition.

The once: true variant enforces single-fire semantics: after the first execution the hook deregisters itself, making it useful for setup actions that must not repeat on subsequent boundary crossings.

Forced by Silent Failure

The primitive class exists because a weaker design -- side-effect callbacks with no blocking capacity -- proved insufficient under failure conditions. When a lifecycle boundary completes silently (no error surfaced, no audit trail written, no downstream signal emitted), a non-blocking observer cannot intervene. The runtime cannot distinguish "transition completed cleanly" from "transition completed with a suppressed fault." Interposition hooks solve this by making the boundary itself the enforcement point: if the hook does not pass, the transition does not complete.

This is the "forced by silent failure" constraint named in the summary. The class was not introduced for observability; it was introduced because observability alone failed.

Epistemic Status

This article is changelog-derived and not runtime-verified. All claims above reflect what the changelog records about the design intent and member instances of this primitive class. No claim here has been confirmed by live runtime inspection or test execution. The mechanics described should be treated as the recorded specification, not as a proven operational fact. Independent verification against a running agent runtime would be required before treating any specific behaviour -- hook ordering, blocking semantics, once: true deregistration timing -- as authoritative.