> ## Documentation Index
> Fetch the complete documentation index at: https://docs.capcells.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Decisions
> How an application is evaluated, what a decision records, and which refusals are decisions at all.
A **Decision** is what the Platform answers about one application: refuse, approve with terms, refer, or not offered. Every decision is recorded whole, beside the inputs it was decided on, before it is answered.
Deciding needs a policy version adopted for the configuration the application names. See [Credit policy](/lending/credit-policy) for what a policy is and how you adopt one for a product.
## The application
You submit a registered client, a configuration version, a requested principal, a reference of your own, and a value for every declared attribute the adopted version reads.
| Field | What it is held against |
| - | - |
| `client_id` | Your own client registry. One you never registered is refused |
| `configuration_id`, `configuration_version` | The configuration version's principal bounds, its currency, and its rate corridor |
| `principal` | Those bounds and that currency |
| `submitted_on` | Every declared value's own `as_of` day |
| `attributes` | The vocabulary, each attribute's bounds, and the states its frame admits |
`submitted_on` is stated rather than taken from a clock. The Platform supplies no today, so how stale your own facts are allowed to be is measured against a day you name.
Every declared value carries the day you hold it to be true. A value dated after `submitted_on` is refused, and one older than its attribute's maximum age is refused naming the attribute, the day and the bound. Without it, an income last confirmed two years ago is indistinguishable from one confirmed this morning, and a decision that cannot say how old its inputs were cannot be judged later on whether it was reasonable when it was made.
## Evaluation order
Evaluation is a pure function of the application as read and the version named. It reads no clock and no store, so the same application under the same version yields the same score, the same trace and the same outcome whenever it is decided.
Once, up front, from the declared values and the requested principal. They are recorded beside the declared ones.
All of them, not only up to the first that fires. A refusal names every knockout that fired, because which cause was preponderant is unanswerable if evaluation stopped early. Where several fire, `refuse` wins over `not_offered`, and `not_offered` over `refer`.
The score is the integer sum of the points awarded.
That band's outcome is the answer, unless a knockout already settled it.
A request above the approving band's principal ceiling becomes a refusal naming the ceiling. The score is still the band's.
A rule the Platform cannot evaluate is neither skipped nor counted as having passed. The application is decided `refer`, and the trace names which rule could not be evaluated. Content the Platform validated before serving should make that unreachable, and an inability to evaluate is never presented as an evaluation.
### Outcomes
| Outcome | What it says | What it carries |
| - | - | - |
| `refuse` | The policy decided, and the answer is no | A moratorium, where the band or the knockout carries one |
| `approve` | The policy decided, and the answer is yes | The requested principal as approved, and the band's exact annual rate |
| `refer` | The policy declines to settle this application either way | Its score and its full trace, and no terms |
| `not_offered` | The product is not sold to this applicant — not yet, or not through this channel | Its score and its full trace naming the rule, and no terms and no moratorium |
**Refer** exists so that an application the Platform will not settle is never dressed as one it settled against the applicant. A person nobody assessed does not acquire a refusal in the record.
**Not offered** exists for the same reason from the other side. "A first loan is the short product only" is a statement about what you sell, never about the person, and a policy that could only refuse would put an adverse record on every first-time client who asked for the product they are not yet sold. A `not_offered` Decision bars nothing, no count of refusals includes it, and no surface presents it as a refusal or a referral. Only a knockout may answer it, never a cutoff band. Your integration reads it by stating `outcomes: four` on the application; one that has not is refused before anything is read rather than answered a word it was not built to parse.
A `refer` becomes something else in one way only: a person at your tenancy [resolves it](#resolving-a-refer). Otherwise it is the final answer to the application that received it; gather what was missing and submit a new application under a new reference, which is decided on its own inputs and recorded on its own.
## Resolving a refer
An administrator of your tenancy may settle a `refer` at the [console](/authentication/console), as a person: `POST /console/v1/tenants/{tenant_id}/credit-decisions/{decision_id}/resolution`. A tenant API key cannot, and neither can an agent. A resolution is a credit judgement somebody signs.
| Resolved as | It states | It is held to |
| - | - | - |
| `approve` | `approved_principal`, `rate`, `basis` | A principal no greater than the application asked, inside the configuration version's bounds, and no greater than the highest ceiling any approving band of the policy version carries. A rate inside the configuration version's corridor |
| `refuse` | `basis`, and `moratorium_days` where it binds | A moratorium of at least one day, where stated |
The resolution is its own record beside the decision. The decision reads exactly as recorded, still `refer`, with its score, band and trace, and carries the resolution next to it: who, when, why, and the zone the moment is read in. A decision states `awaits_resolution`: `true` for a `refer` nobody has resolved, `false` for everything else.
| You send | The Platform answers |
| - | - |
| A resolution of an unresolved `refer` | `201` with the decision and the resolution beside it |
| A second resolution of the same `refer` | `409` `already_resolved`, naming the resolution that stands |
| A resolution of a decision the policy settled | `409` `not_a_refer`, naming its outcome |
| Terms the application, the product or the policy would not admit | `422` `invalid_resolution`, and nothing is recorded |
A resolved approval grants a [Facility](/lending/facilities) on the resolution's principal and rate. A resolved refusal with a moratorium bars the client exactly as a refusing decision does, counted from the day of the resolution.
A refusal is never resolved. Departing from an outcome the policy settled is a different act, and calling it a resolution would be the override the record exists to keep out.
The Platform makes no counter-offer. When the score lands in a band whose ceiling is below what you asked for, the answer is a refusal naming the ceiling, which tells you exactly what a new application should ask.
## Invalid inputs
A refusal about the applicant is a decision. A refusal about the request is not, and nothing is written for it.
| The Platform answers | Recorded | The reference |
| - | - | - |
| A knockout fired | Yes | Consumed |
| The score fell below the cutoff | Yes | Consumed |
| The request exceeded the approving band's ceiling | Yes | Consumed |
| The policy declines to settle | Yes, as `refer` | Consumed |
| A rule says the product is not sold to this applicant | Yes, as `not_offered` | Consumed |
| An attribute is missing, out of bounds, stale, or in a state its frame does not admit | No | Stays free |
| The application states an attribute the vocabulary does not define, or one the Platform derives | No | Stays free |
| The client is not registered, or the configuration version does not exist | No | Stays free |
| The principal is outside the configuration version's bounds, or in other money | No | Stays free |
| The approving band's rate lies outside the configuration version's rate corridor | No | Stays free |
| The decision could not be written | No | Stays free |
The distinction is the record's honesty. A client refused because the request was malformed was not refused credit, and a record that cannot tell the two apart turns every typo into an adverse fact against a person.
A malformed application names everything wrong with it at once, so correcting it takes one round trip rather than several.
The corridor refusal is worth its own sentence: a policy and a configuration that disagree about the price are two of your own documents in conflict, not a fact about the applicant, and recording it as a credit refusal would put somebody's name on a configuration mistake.
## References
Every application carries a reference you choose, unique within your tenancy, with the grammar of a client identifier: 1–64 characters of `a–z A–Z 0–9 - _`.
| You submit | The Platform answers |
| - | - |
| A new reference | `201` with the decision it recorded |
| A recorded reference with the same application | `200` with the decision already recorded |
| A recorded reference with a different application | `409`, and the recorded decision stands unchanged |
| A reference whose earlier application was refused as invalid | `201`, the refusal recorded nothing, so the reference was never taken |
A retry after a lost response is the same application named twice, and it answers the same decision. Two decisions under one reference is a which-did-you-mean the Platform will not answer on your behalf.
## One purchase, several products
One purchase that may be sold under several Configurations is one application, decided [across a menu](/api-reference/credit-decisions/menu). The application is read once — every declared value validated once, every Source read once under the one consent — and decided under the policy version adopted for each Configuration named. One Decision is recorded per Configuration, each whole, all under your one reference, and answered together: approved on the short product, `not_offered` on the long one. Deciding per product one call at a time would spend a consulta per product under a consent that authorised one.
A Configuration with nothing adopted refuses the whole menu, and nothing is recorded. A repeat answers the recorded Decisions only when it names the same Configurations in the same order.
## A facility in the same act
An application may state a `facility` window. Where the Decision is an approval, a [Facility](/lending/facilities) is created from it in the same request, exactly as a separate creation would create it, and answered with the Decision; anything else grants nothing, and the answer says `granted: false`. The window is held to the same bound a separate creation is, before any Source is read, so a window beyond it costs nothing. Creating the Facility separately afterwards answers the one already created.
## What is recorded
A decision is recorded whole and never altered. It carries everything needed to explain it without anything else being fetched.
| Recorded | Why it is there |
| - | - |
| The application as read, every attribute, declared and derived, with its state and its day | So the decision can be judged on what it actually saw |
| The policy, its version and that version's digest | So which content decided it is checkable, not merely labelled |
| Every knockout's evaluation, with the rule's own text, its bound and the value it saw | So a refusal explains itself with no access to the policy version |
| Every scorecard entry's points, the score and the band | So where the score came from is readable |
| The outcome, its terms where it has any, and its moratorium where it carries one | So what was answered is not reconstructed from anything |
| The list of external credit-information sources it read | One entry per source, with the authorisation that permitted reading it, the source's own reference, the mapping the payload was read under, and the attempt that joins to your ledger. Empty where the adopted version reads none, and present rather than absent so the two are different answers. Where a source was reached and did not answer, the entry says so and names the posture that settled it |
An outcome, once recorded, is never altered. Any future way of departing from what a policy decided, a campaign uplift, a manually granted exception, will be a separate recorded act naming the decision it departs from, and it will change only the terms offered, never the recorded score, band or outcome.
A decision belonging to another tenancy answers exactly as one that never existed.
## Moratorium and bar
A refusal decided under a cutoff band or a knockout that carries a moratorium binds against re-application for that many whole days. Where several fired knockouts carry one, the longest binds. `mx-base` version 1 attaches 30 days to its below-the-cutoff band.
The bar counts from the decision's `bound_from`: the application's `submitted_on` where that day is earlier than the day the decision was recorded on, and the recording day otherwise. A book written in the past, a sandbox's or a migrated portfolio's, bars and lifts as the dates it states.
Ask whether a client is barred on a day, and the Platform answers from the recorded decisions rather than from anything stored beside the client, so the answer cannot disagree with them. Where several refusals bar a client at once, the answer is the latest day any of them lifts.
A `refer` a person resolved as a refusal with a moratorium bars the same way, counted from the day it was resolved. The bar names the decision the resolution settled.
Whether deciding consults the bar is your choice per configuration, stated on the adoption.
| Adoption | A barred client's application |
| - | - |
| `enforce_bar` omitted or `false` | Decided and recorded exactly as any other. What you do with it is your own affair |
| `enforce_bar: true` | Refused with `409 client_barred` before any source is read, naming the day the bar lifts and the refusal. Nothing is recorded, so the bar does not restart |
## What it binds
A decision binds nothing on its own. Issuance does not read one, and a loan can be issued on terms no decision approved.
What turns an approval into something issuance honours is a [Facility](/lending/facilities): you create one from an approving decision, or from a `refer` resolved as an approval, and every loan drawn under it is held against the amount, the price, the client, the product and the window that decision fixed.
A loan may also name a decision directly, with or without a grant. That reference binds nothing at all. It exists so that what became of a loan can be joined to what decided it.
| Not built | What it means today |
| - | - |
| No route lists or searches decisions | Read one by its identifier |
| No re-scoring happens anywhere | Every decision is the one evaluation that binds, and a facility re-reads nothing between the grant and a draw |
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.