One governed action boundary for every recovery actor

ARC built one governed action surface for people, agents, integrations and background services. It records the exact proposal, the applicable rule and the approval for each actor, so a lender can inspect what happened on a case without a tour of four systems.

Challenge

Recovery work involves people, agents, integrations and background services acting on the same assignment. If each actor gets its own mutation path, policy becomes difficult to reason about and even harder to prove later.

The problem is sharper around stops and approvals. A customer stop may arrive before an assignment. An approved address may change. A useful dashboard may be mistaken for live clearance. Each of these is an authority problem before it is an automation problem.

The desired boundary requires every business mutation to use current authorization, policy, idempotency, required approvals and auditable events. Urgent stops keep independent fences and delivery obligations. Analytical projections never provide live clearance.

Strategy

Use one governed action surface for every actor. Make the assignment's authority and restrictions explicit, and keep the decision separate from the sequence of work.

Rules decide and workflows sequence, so the architecture separates those jobs. Temporal provides durable execution, and the governed action surface applies current identity and policy. The local implementation uses PostgreSQL and a Temporal development server; production identity and environment conformance remain deployment work and are never implied.

The domain language also had to become precise. A dispatch proposal records a request and grants no physical authority by itself. A context envelope contains bounded evidence and grants no permission by itself. An observation remains a candidate fact until validation promotes it.

Solution

The assignment carries its own authority, holds, evidence and lifecycle. Each actor crosses the same policy and event boundary, whether the trigger came from an operator, an agent, an integration or a background job.

A dispatch proposal names the exact assignment version, authority epoch and address. The policy result and its reason are recorded. If the facts change, the old proposal doesn't silently become a new instruction.

Customer stops use independent fences keyed to the exact source order. Durable receipt, enforced stop, recipient delivery and personal acknowledgment remain separate outcomes. Acknowledgment doesn't release the restriction.

Evidence is bounded by actor, subject, task and purpose. Where each record came from, its freshness, omissions and conflicts stay visible. An observation becomes authoritative only through the applicable validation and promotion decision.

Results

The resulting architecture gives a recovery operator one way to review authority across every actor. A lender can inspect the assignment, trigger, reason and outcome without reconstructing the decision from disconnected systems.

It also creates explicit limits. Live vendor access, client cloud and region, production identity provisioning, model gateway, compliance rule packs and recovery objectives remain deployment decisions. Local demonstration data doesn't prove those integrations.

The design leaves agents a bounded role. They can reconcile evidence and propose or perform permitted work, but they can't turn a prompt into authority or reason around an independent stop.

What other recovery teams can take from it

Start by naming the actions that change the assignment. Put every actor through the same current policy and approval check. Give stops an identity of their own, and make the exact proposal the unit of review instead of a generic approval flag.

That groundwork makes agent autonomy easier to evaluate because the team can compare what an agent proposed with what the same boundary would allow a person to do.

The boundary also gives a reviewer somewhere useful to look when an action needs defending: the exact assignment, the rule that applied, the person or policy that decided, and the evidence and event that followed. Every actor leaves the same kind of record.

Take an illustrative agent proposal and a human proposal for ARC-1042. Both enter the same action surface with the assignment, trigger and reason attached. If the client's current policy requires a person, neither proposal can proceed without that approval. If the address changes, both need a new proposal. The actor changes, but the evidence and policy question do not. That is what makes their records comparable.

The useful test asks whether the same boundary produces a decision the recovery operator can defend, with the assignment, trigger, reason and outcome all available to the next reviewer. The boundary makes the actor's confidence irrelevant to the proof.

That record also shows the limit of automation. A model can explain its preferred action in polished language, but the operator still needs the exact authority, current restrictions and evidence behind it. The action surface keeps those facts attached to the decision, whether the proposal came from a model or a person. A reviewer can examine the assignment and understand the action in the client's own terms, with the trigger, reason, current restrictions and eventual outcome still connected. Evidence carries authority.

Frequently asked questions

Does one action boundary eliminate human judgment?

No. It makes required judgment visible because the reviewer sees the exact proposal and evidence, and records the decision under their identity.

Are production vendor integrations already proved?

No. The supplied product records distinguish the local implementation from production acceptance work. Live vendor access and environment conformance remain explicit deployment tasks.

Can a context envelope authorize an agent?

No. It is a bounded collection of permitted evidence for a task and purpose. Authority still comes from current grants, policy, required approvals and independent stops.