Action request gateway

The action gateway is the boundary between deciding work and changing the system of record. Humans, deterministic workflows, and AI workers use the same typed contract; no worker receives a hidden bypass.

Lifecycle

LifecycleGoverned action request

PREPAREDtyped payload and context frozen

›

APPROVAL_REQUIREDmaker complete

›

APPROVEDchecker authorizes exact payload

›

SUBMITTEDsystem of record accepts

›

COMPLETEDauthoritative result recorded

PREPARED→APPROVEDpolicy permits straight-through execution

APPROVAL_REQUIRED→REJECTEDchecker declines with reason

APPROVED→CANCELLEDcancelled before submission

SUBMITTED→PENDING_EXTERNALaccepted, completion asynchronous

SUBMITTED→MANUAL_REQUIREDbinding requires specialist execution

SUBMITTED→FAILED_ACTION_REVIEWunknown or divergent result

Typed actions, not raw commands

Every request has an actionType from the published catalog and a schema specific to that type. Callers cannot submit arbitrary command names, URLs, or unvalidated payloads.

The catalog includes payments, autopay changes, external-payment records, contact-consent updates, restrictions, re-aging, re-amortization, rescheduling, interest treatment, charges, refunds, recovery payments, write-off, charge-off, fraud flags, SCRA adjustments, contract termination, and closure. See Servicing actions.

Decide, then prepare

There is no preview endpoint on the built-in Lending Core and no preview token. For a schedule-changing or balance-changing action, decide from authoritative reads—GET /v1/loans/{loanId}?associations=repaymentSchedule,transactions and GET /v1/loans/{loanId}/summary—and attach the before/after comparison the decision rests on to the case. Preparation freezes the typed payload and context:

{
  "actionType": "re_amortize",
  "loanRef": "7204",
  "parameters": {
    "interestHandling": "default"
  },
  "context": {
    "caseId": "case_CEDAR_HARDSHIP_4",
    "reasonCode": "temporary_income_reduction"
  }
}

Approval binds to the hash of that frozen request. If material facts change before submission, the execution-time gate fails the request closed and the decision must be remade from fresh reads.

Operational context is mandatory

Every state-changing action links to one of:

• a case it serves;
• a controlled administrative exception with approver and expiry; or
• a named system trigger with policy version.

The context is not a free-form note. It carries structured reason, origin, source interaction or task, evidence references, and actor. This makes the chain traversable from ledger transaction back to decision.

Execution-time gate

Immediately before submission, the gateway re-reads critical facts and reruns policy. Approval from yesterday does not override a bankruptcy restriction received today. Possible outcomes are:

Decision	Meaning
ALLOWED	Execute under the resolved policy.
ALLOWED_WITH_WARNING	Execute and preserve named warnings.
APPROVAL_REQUIRED	Stop until the required role approves the frozen action.
BLOCKED	A known rule prohibits the action.
UNAVAILABLE_DUE_TO_MISSING_FACTS	Required facts are absent or stale; fail closed.

The result stores rule IDs, jurisdictions, effective versions, facts and freshness, and any override—not merely a boolean.

Approval and separation of duties

Approval policy can consider action type, amount, balance effect, customer vulnerability, source worker, and tenant thresholds. Maker and checker must be distinct where dual control applies. A checker sees the same before/after comparison, evidence, warnings, and action hash that execution will use.

AI can prepare and recommend an action within its work packet. It cannot supply human approval, change its own autonomy level, or alter the action after approval.

Idempotent submission and acknowledgement

The gateway derives a stable execution key from tenant, action request, and attempt. The system of record must return the same acknowledgement for a retry.

For the built-in Lending Core, execution is in process rather than a call to a generic actions API: a typed executor resolves the loan’s facts and capabilities, applies the governed native command—case context attached, maker-checker parking respected—and records the case effects and governance record. A bring-your-own-core binding submits the same typed action over its documented HTTP contract.

{
  "actionRequestId": "act_CEDAR_RA_81",
  "status": "completed",
  "result": {
    "coreCommand": "reAmortize",
    "resourceId": 7204,
    "governanceId": 903,
    "effectiveDate": "2027-08-20"
  },
  "requestedHash": "sha256:2a7f…12ce",
  "appliedHash": "sha256:2a7f…12ce"
}

Normalized execution results are COMPLETED, PENDING_EXTERNAL, REJECTED, MANUAL_REQUIRED, FAILED, and CAPABILITY_UNAVAILABLE. Provider-native detail remains available in restricted evidence.

Divergence and manual execution

If the applied amount, date, treatment, or resulting state differs from the approved request, the gateway records both, marks FAILED_ACTION_REVIEW, and opens reconciliation work. It never labels the requested value as applied.

For a MANUAL_REQUIRED binding, an approved specialist records the authoritative reference and applied facts. Manual completion passes the same reconciliation checks; it is not a free-form “done” button.

Undo is a compensating action

Supported undo operations—dedicated commands such as undowriteoff, undo-charge-off, undoReAge, undoReAmortize, and undoContractTermination on the built-in core—create a new action linked to the original. They verify that the target is still reversible and that no later dependent transaction makes undo unsafe. The original action, approval, and evidence remain immutable.