Topics/Hook Composition

ADPS Topic Study

Hook Composition · Make hidden callbacks a readable control structure

Compose orchestration, governance, observation, and recovery at lifecycle events with explicit order, idempotency, and failure semantics.

Hooks place deterministic code at stable lifecycle events. A hook can shrink context before a model call, check authority before a tool call, start the next agent after an artifact is accepted, record trace data, save a checkpoint, or release resources.

A hook is a mechanism. Its role comes from the event, the state it reads, the authority it holds, and its failure semantics.

Four roles

Role Typical events Actions
Orchestration artifact accepted, stage completed start stage, route task, gather results
Governance before tool, before commit identity, policy, approval, quota, argument checks
Observation model/tool/step completed events, versions, state deltas, receipts
Recovery failure, timeout, cancel checkpoint, compensation, lease release, escalation

Composition

before_model → context_policy → prompt_trace
before_tool  → identity_check → policy_decision → approval_if_needed
after_tool   → receipt_capture → state_diff → next_stage_or_recovery

The runtime should display the effective order. When two hooks rewrite arguments, order changes behavior. When an audit hook fails, the design must state whether business execution blocks or observation degrades.

For a payroll commit, before_tool first verifies the caller, then reads policy and determines whether approval is required. After resume, before_commit rechecks employee state and the Intent digest. Following a successful call, after_tool records the receipt and after-read. A telemetry failure may degrade a low-risk read, while a production write normally blocks. Order and failure semantics belong to the composition and cannot depend on accidental plugin registration order.

HookSpec

hook_id: payroll.before_commit.policy
event: before_tool
priority: 200
reads: [principal, intent, tool_digest, resource_scope]
writes: [policy_decision]
idempotency_key: run_id + intent_digest
on_failure: deny
emits: [policy.decided]
owner: security-platform
version: 7

Relation to G5

G5 keeps its historical identifier and focuses on deterministic governance enforcement. Hook Composition spans a wider set of responsibilities, so no new collaboration pattern has been added.

Common failures

Review questions

  1. Which event triggers each hook, and what state does it read or write?
  2. Are order and conflict rules explicit?
  3. Are retry, resume, and duplicate events idempotent?
  4. Does failure fail open, fail closed, or escalate?
  5. Can a run show the effective hook set and versions?

Source

The Governance workshop separated policy source, decision, enforcement, and evidence. The Collaboration workshop added stage transitions, cross-agent triggers, and recovery. This topic joins both discussions while retaining G5 as the historical governance entry.

Suggested citation: ADPS, Hook Composition · Make hidden callbacks a readable control structure, ADPS Topic Study, 26 August 2026.

Topic index · Collaboration workshop · CC BY 4.0

Chronicle

Recorded source
Workshop and case records cited in the article: Collaboration workshop ()
Source date
First published on ADPS

View in the ADPS Chronicle