Skip to main content

Chain-level governance

A Chain is Arclasp’s workflow-level governance unit. Instead of treating every governed action as an unrelated API call, Arclasp keeps ordered state across the actions recorded in the same Chain. That lets later decisions use the workflow context accumulated so far.

Why this matters

Consider three governed financial actions:
Each action is below a $5,000 single-action approval threshold. Together, they reach $11,000. With a $10,000 cumulative Chain threshold, the third governed financial action crosses the boundary even though the individual amount is only $4,000.

Configure a per-Chain cumulative threshold

Use add_financial_threshold() before the Chain starts:
Under the current financial semantics, Arclasp extracts financial exposure from top-level amount_usd, amount, or value fields. The final governed event pushes the Chain’s recorded financial exposure from $7,000 to $11,000 and crosses the $10,000 cumulative threshold.

What contributes to Chain state

Only activity that is instrumented and recorded through the Chain can contribute to Arclasp’s workflow state. Arclasp does not automatically see every action an agent takes outside the SDK. Current Chain state can include information such as:
  • event sequence and status;
  • agents involved;
  • cumulative financial exposure;
  • recorded LLM token usage and estimated cost when supported token/model fields are provided;
  • approval state;
  • runtime counters used by auto-pause behavior;
  • receipt linkage after completion.

Backend authority

The current governed path is backend-authoritative. record_agent_action() sends the governed event to Arclasp, and the backend evaluates it against policy and accumulated Chain state. Legacy local-evaluation helpers remain in the package for compatibility, but they are not the authority for current governed execution.

Chain lifecycle

A typical Chain moves through states such as:
Denial, timeout, or auto-pause can move a Chain into states where new governed events are not accepted until the product’s corresponding recovery/resume path permits them. Do not catch a denial and assume you can continue writing events to the same Chain.

Idempotency is not tool execution exactly-once

Arclasp uses scoped idempotency to prevent duplicate governance/evidence rows in supported retry cases. That does not guarantee exactly-once execution of customer-side tools. Your application still owns the side effect and its own idempotency strategy.