Guardrails & approvals
Bounded discretion is written as policy the platform enforces, so an out-of-policy proposal reaches an approver with its evidence frozen — and a hard stop stays unapprovable.
Guardrails are what let the workforce agree terms with a borrower on the call without asking anybody, and send anything outside the lender’s written policy to a named approver with the evidence frozen. Without bounds there is no line an agent can be trusted up to; with an approval on every deviation the workforce stops at the first non-standard borrower. A guardrail is the line between them: written policy saying how far an otherwise permitted actor may go alone, and where the approval path begins. It never substitutes for permission, consent, compliance, fresh facts, or action eligibility.
- Latest commitment — 45 days from agreement
- Minimum total — 40% of current amount past duecovers 100% of $517.14
- Maximum installments — 3two
- First installment — within 10 daysseven days
The six layers an action must pass
authenticated actor and permission
+ action capability
+ fresh subject facts
+ compliance eligibility
+ guardrail bounds
+ approval / separation of duties
-----------------------------------
= executable action
Each line is an independent test, and the action needs all of them. A permission proves who somebody is, not that the borrower may be contacted; a compliance pass proves the contact is allowed, not that these terms are within a supervisor’s discretion. Collapsing the stack into one answer is how a well-permissioned worker — agent or person — ends up agreeing a settlement nobody authorized.
Maya’s two installments, inside the bounds
Suppose the lender configures this illustrative early-collections policy. Each bound stops one specific thing: an unsupported long-horizon promise, an immaterial arrangement that suppresses work, a plan with too many parts to follow, and an arrangement that asks nothing of the borrower this week.
Out of bounds, the path is supervisor review, which preserves discretion with the evidence attached. Creating the promise does not move money either way: its outcome later derives from posted payment facts.
The approver accepts that exact request
An approval-bound request preserves normalized payload, financial/schedule preview, request hash, facts and versions, policy/guardrail result, evidence, creator, and expiry. Any material edit creates a new hash and requires a new decision — otherwise the terms an approver read and the terms that executed could differ by one date, and the approval record would still look clean.
Nobody approves their own request
The creator cannot approve their own request where separation applies. Eligibility also depends on role, amount/action threshold, legal entity, case type, and current delegation. Approver comments supplement a structured reason code rather than replacing it: a reason code can be counted, sampled, and compared across a quarter, and a paragraph cannot.
Which results an approval can change
| Result | Can ordinary approval change it? |
|---|---|
| Within guardrail | No approval required unless another policy requires it. |
| Outside guardrail | Yes, through the declared approval path. |
| Missing facts | No; obtain or resolve facts first. |
| Non-overridable block | No ordinary servicing override. |
| Exceptional policy route | Only if the rule explicitly defines scope, authority, and evidence. |
A screen can present a non-overridable block however it likes; the result is resolved by policy, and the button stays refused. What the interface calls a control is a design choice, and what the engine does with it is not.
Money still moves through its owning endpoint
Guardrails can bound refunds, fee adjustments, contact intensity, hardship offers, AI actions, and data exports. Contract changes and money movement still travel through the servicing or Lending Core endpoint that owns them. An allowed result executes there; only a genuine approval, deferred, manual, external, or unavailable result opens an action request.