Sandbox. Records here are not production authority.
DAL-X│
← Back to DAL-X

Jochanni Labs · Decision Governance

DAL-X
At The Execution Boundary

Two illustrative payment scenarios. One enforcement pattern: no DAL-X authority, no execution.

01 · Financial Services02 · Insurance
Scroll to explore

About These Examples

These are illustrative scenarios, not customer deployments. The people and companies in the conversations are hypothetical. The code shows where the DAL-X gate call is placed and how verification reaches the final execution system. Today DAL-X binds payment actions: action, target, amount, currency, recipient, recipient account reference, and payment type. A reviewer authorizes those values, the gate refuses a request that declares different ones, and receipt verification compares them again at the downstream boundary. Both scenarios on this page are payment actions. DAL-X does not bind other kinds of action today.

A production integration maps these calls to the actual data model, key scoping, execution infrastructure, and retry mechanisms of the target system. These scenarios exist so you can evaluate whether the enforcement pattern fits your architecture before any integration work begins. DAL-X is not a drop-in library. It is an authority layer that must be wired to the specific execution boundary you are protecting.

Before You Write Code

Set these up in the DAL-X web application first. Three are required. The fourth is optional.

  1. 1

    Required to submitRegister the agent. DAL-X accepts runtime output only from an agent it knows by its agent key.

  2. 2

    RequiredCreate three keys. A submit key for the agent, an enforcement key for the gate service, and a separate enforcement key for the downstream system. No key holds both scopes.

  3. 3

    Required for the gateRegister and activate the enforcement contract. One contract per execution target. The gate rejects every attempt against a target with no active contract. Activation is a separate step, taken by a second administrator where the workspace has one.

  4. 4

    OptionalRegister a webhook destination. A webhook delivers a notice that a decision was made. It establishes no execution authority and the gate does not depend on it. Without one, a scheduled check resumes the saved work.

01/Financial Services

Treasury Payment Agent

treasury-payment-agent-v1→payments-api·vendor_payment
Illustrative ScenarioAlex Chen · Sr. Engineer, Treasury Systems · hypothetical

Illustrative Conversation

AC
Alex Chen
We have treasury-payment-agent-v1 running in production. It generates wire transfer instructions and posts them directly to our payments API. 200 to 300 transactions a day.
JL
DAL-X
Walk me through the execution path. Where does the agent output actually touch the payments API?
AC
Alex Chen
The agent formats a wire object, signs it with our service key, and POSTs to /api/payments/wire/initiate. Fully automated. No human ever sees the wire before it goes out.
JL
DAL-X
That route is the interception point. We put the DAL-X enforcement gate there. The agent still runs - but execution is blocked until a reviewer grants authority and a token is issued.
AC
Alex Chen
So the gate call goes inside that route handler?
JL
DAL-X
Yes. The agent submits its output to DAL-X ingest first. DAL-X evaluates it, blocks it, and puts it in the queue. The agent saves the pending wire and its task ends, so nothing sits running while a reviewer decides. When a reviewer approves, DAL-X issues a single-use authorization and notifies your webhook. The agent's resume step picks up the saved wire and passes the authorization ID to your payments route, and the route presents it at the gate with its own key. The agent never holds that key. Your payments API then verifies the receipt before it sends the wire, and confirms what it sent.

Integration Code

typescript
Next.js Route Handler
// app/api/payments/wire/initiate/route.ts
 
export async function POST(req: Request) {
  const wire = await req.json()
 
  // No authority check - agent output goes directly to execution
  const result = await paymentsClient.initiateWire(wire)
 
  return Response.json(result)
}

Execution Authority Chain

Agent Output

ingest-agent-output

Execution Blocked

default state

Review Queue

human reviewer

Authority Granted

decision record

Gate Cleared

authorization consumed

Receipt Verified

downstream boundary

Executed

outcome confirmed

02/Insurance

Claims Adjudication Agent

claims-adjudication-agent-v1→claims-processing-api·approve_claim_payout
Illustrative ScenarioPriya Sharma · Engineering Manager, Claims Platform · hypothetical

Illustrative Conversation

PS
Priya Sharma
We automated claims adjudication last year. The agent evaluates claims under $25K, applies coverage rules, and issues payouts via our payment processor. About 2,000 claims a week.
JL
DAL-X
When the agent issues a payout, is there any record of who authorized it?
PS
Priya Sharma
The agent logs its decision. But there's no human authorization record. Our compliance team flagged it in the last audit cycle.
JL
DAL-X
That's the gap DAL-X closes. Every governed payout needs a decision record, and that record names the human reviewer who approved it and their reason. DAL-X writes a tamper-evident authority record before execution. No payout is released without one.
PS
Priya Sharma
We're TypeScript. How do we wire this into the adjudication flow?
JL
DAL-X
The adjudication agent stops calling the payout processor. It submits the proposed payout to DAL-X, saves it, and its task ends. When a reviewer approves, DAL-X notifies your webhook and the agent's resume step hands the authorization ID to a payout service that holds the enforcement key. The agent never holds that key. The payout service calls the gate, and the payout processor verifies the receipt before it disburses and confirms what it paid. A receipt is written whether the gate accepts or rejects.

Integration Code

typescript
TypeScript Payout Service
// claims/adjudicate.ts
 
async function adjudicateClaim(claim: Claim): Promise<void> {
  const decision = await claimsAI.evaluate(claim)
 
  if (decision.approved) {
    // AI approval goes directly to payout processor
    // No authority record. Compliance gap.
    await payoutProcessor.initiate({
      claimId:  claim.id,
      amount:   decision.approvedAmount,
      currency: 'USD',
      payee:    claim.claimant,
    })
  }
}

Execution Authority Chain

Agent Output

ingest-agent-output

Execution Blocked

default state

Review Queue

human reviewer

Authority Granted

decision record

Gate Cleared

authorization consumed

Receipt Verified

downstream boundary

Executed

outcome confirmed

One Enforcement Pattern

The sequence does not change.

Submit to DAL-X. Execution is blocked. A reviewer grants authority. The downstream system presents the authorization at the gate. The receipt is verified. Execution happens and is confirmed. The timeline proves the chain.

Request AccessLearn More