Where does the deal fall outside our rules?
Evaluate the file against your lender-defined thresholds, conditions and exceptions so the team can see exactly what passed, what failed and what needs judgment.
Whose rules
One file, three policies, and three different answers.
Four criteria, each on a measured scale, carrying one observation from the file and three lenders’ lines drawn across it. Read across a row and you are reading the borrower; read down a column and you are reading a lender.
- 01
- Borrower file
- 03
- Lender policies
- 03
- Different answers
Average monthly deposits$0 — $120K
Average daily balance$0 — $50K
Time in business0 — 36 months
Returned items · 90 days0 — 12 events
Filled mark · the observation from the file · Open marks · each lender's own line
- 01Average monthly depositsThe same deposits figure clears the first two lines and stops at the third. Nothing about the borrower is different in those three sentences.
- 02Average daily balanceA balance that two lenders treat as comfortable and a third treats as short of its floor.
- 03Time in businessFourteen months is a young business or an established one depending entirely on who is reading it.
- 04Returned items · 90 daysThe one criterion where the line is a ceiling rather than a floor, and the only one this file clears for a single lender out of three.
What the engine brings, and what it does not
- The arithmeticOurs
- The thresholdsYours
- A default policyNone shipped
- A recommended lineNever
Cevrynt ships no starting thresholds and suggests none. A policy engine that arrived with opinions about where a line belongs would be a lender with extra steps, and the three policies above are illustrative configurations rather than tiers on offer.
One file, three policies, three answers — and the file never changed between them. That is the whole of what a policy engine is for: the thresholds belong to the lender, the arithmetic belongs to us, and nobody's deal is measured against a number we invented.
When the rule changes
Same file, same lender, and a policy that moved underneath it.
One revision, three thresholds moved, two outcomes flipped in opposite directions — and the borrower did nothing in either case. What a deal keeps is the version that actually decided it.
- 04
- Criteria on the file
- 03
- Thresholds that moved
- 02
- Outcomes that flipped
Average monthly deposits$0 — $120K
PassStop
Returned items · 90 days0 — 12 events
ExceptionPass
Average daily balance$0 — $50K
PassPass
Time in business0 — 36 months
PassPass
What the version is for3 of these thresholds moved and 2 outcomes flipped, in opposite directions, without the borrower doing anything at all. A deal evaluated under 3.3 keeps 3.3 attached to it for good — the engine does not re-judge a decided file against a rule written afterwards, because a file whose answer changes every time somebody edits a threshold is not an answer anybody can defend later.
- 01Average monthly depositsThe committee tightened deposits in the spring. The same $84.6K that cleared the old line sits below the new one, and the file it belongs to was decided months earlier.
- 02Returned items · 90 daysLoosened in the same revision, and in the opposite direction. An exception that needed a reviewer under 3.3 would not be raised at all under 3.4.
- 03Average daily balanceThe line moved and the outcome did not. Worth recording anyway: the next file along may sit in the gap between the two.
- 04Time in businessUntouched by the revision, and the only line on this chart where the two versions sit on top of each other.
What travels with a decided deal
- The policy versionRetained
- Each threshold as it stoodRetained
- Re-judged on a later ruleNever
- Who changed the ruleRecorded
A policy change applies to what comes next. It does not reach back through files that have already been worked, and the version that evaluated a deal stays attached to that deal for as long as the record exists.
Two outcomes flipped in opposite directions and neither borrower did anything. The version is not bookkeeping — it is the only reason anybody can answer the question every credit file eventually gets asked, which is not what the rule says now but what the rule said then.
Where a rule stops
A pass, a stop, and the gap in between that belongs to a person.
Most criteria a credit team runs are not one line but two: a point below which the file stops, a point above which it clears, and a band in between that no threshold settles by itself.
- 04
- Criteria on the file
- 02
- In the band
- 00
- Resolved by the engine
Two lines, not oneChoose a criterion to see what happens to it. A file above the clearing line is stated and the reading attached; a file past the far line stops against the lender's own rule; a file in the band is raised for a person, and the engine writes nothing into that gap.
- 01Average monthly depositsTwo lines rather than one: a floor the file cannot fall below, and a higher point at which it clears outright. This file is above both, which is the only case a single threshold describes honestly.
- 02Average daily balanceComfortably above the floor and comfortably short of the clearing point, which is the honest description of most real files and the one thing a single threshold can never say.
- 03Time in businessFourteen months is not a number that decides itself. Where the band sits and how wide it is, is a decision the credit team makes once; applying it the same way to every file afterwards is the part we take on.
- 04Returned items · 90 daysThe one criterion whose scale runs the other way: fewer is better, so the pass region sits at the bottom of the track and the stop region at the top. Six returned items is past both lines.
What the engine does with the band
- Computes a verdict for itNever
- Raises it for a reviewerBy name
- The reading behind itAttached
- Both lines it sits betweenShown
The band is the part of a policy that is deliberately unfinished. Cevrynt does not close it, weight it or turn it into a score — it hands the reviewer what it read and the two lines the lender drew, and the lender retains final authority over what happens next.
A policy with one line per criterion pretends every file is cleanly on one side of something. Real policies have two, and the space between them is not a gap in the rules — it is the part of the work that was always going to need a person.
What a rule cannot hold
Three of these can be written down. Six of them go to a person.
Nine conditions a credit team applies to a file, sorted by what a policy engine can honestly do with each one — state it, surface it without weighing it, or leave it alone entirely.
- 09
- Conditions on this list
- 03
- The engine can state
- 06
- Go to a person
Average monthly deposits over the statement period
A number with a direction and a floor. The engine reads it from the statements, states it against your line, and shows the line it used and the pages the figure came from.
Time in business from the filing date
A date, a subtraction and a source. There is nothing here to interpret, which is exactly why it belongs in a rule rather than in front of somebody.
Returned items in the last ninety days
A count against a ceiling. The only judgment in it is what counts as a returned item, and that definition is yours — the engine applies the one you wrote rather than one of its own.
Deposits that mostly come from one payer
The engine can show that the concentration exists and which payer it is. Whether a single large customer is this borrower's strength or its entire risk is a judgment about that industry, and it does not become one by being multiplied by a weight.
A second position appearing mid-statement
Detectable, and worth putting in front of somebody the same day. What it means depends on terms that are not in the file, so the engine reports what it saw and leaves the reading open.
A seasonal shape in the deposits
The engine can describe the shape and show you the months. It cannot tell you whether this borrower's slow quarter is ordinary for the trade or the beginning of something, and it will not guess.
The owner's explanation for a bad month
A sentence from a person about a situation. It is attached to the file as a reviewer note, in their words, and it is never converted into a number or a modifier.
Whether this is a relationship worth keeping
Renewal history, how the last advance was serviced, what the broker is like to work with. Real considerations, and none of them underwriting arithmetic.
Whether to make the exception anyway
The decision this whole platform exists to support and the one it never takes. Cevrynt is not a lender, no exception is closed here, and the authority to fund or decline stays where it already is.
The engine answers
Stated against your threshold, with the direction you set and the source reading attached to the statement.
3 of 9
A person answers
Raised for a named reviewer with everything the engine saw attached, a record of who it went to, and nothing decided on their behalf.
6 of 9
Why the list is this shape
Most of what a credit team knows was never a threshold. It is a sense of an industry, a read on an owner, a memory of how the last three deals like this one performed — and none of it survives being turned into a number without losing the thing that made it worth knowing.
So the engine states what can genuinely be stated, surfaces what it can see but cannot weigh, and leaves the rest alone entirely. The third group is not a roadmap item. It is a description of where this platform stops on purpose.
What an exception carries when it is raised
- Who it was raised forNamed
- What the engine concludedNothing
- The reading behind itAttached
- Closed automaticallyNever
An exception is a routing instruction, not a verdict held back. Nothing in the record claims an outcome the engine did not produce, and the reviewer's own note is what closes it.
Three of these nine can be written down. The other six are the reason a person is still reading the file, and a platform that quietly converted them into a score would be making underwriting decisions it has no standing to make.
Conditions, not thresholds
Some rules only exist because another rule fired.
Half of what a credit team wrote down is conditional: a requirement that appears only because something else happened, and one that quietly never applied because it didn’t. Both belong on the record.
- 04
- Conditions on this policy
- 03
- Armed by this file
- 01
- Did not fire, still recorded
A policy is not a flat listChoose a chain to see what it added to the file. Each one starts with something the file actually did, and what follows exists only because of it — including the last chain, which never fired and is on the record anyway.
- 01The guarantee chainThe longest chain here, and the clearest case for conditions being a separate thing from thresholds. Nothing in steps two and three is a number — they are requirements that came into existence because a number went one way.
- 02The sign-off chainA chain that ends after one step, which is what most conditions actually do. Padding it out to the width of the grid would make the policy look deeper than it is.
- 03The cash-flow note chainWorth noticing where this one starts: on the criterion from section 03 that the engine refused to settle. Conditions attach to what happened, not to what was decided.
- 04The seasonality chain, which never firedA policy run that only showed the rules that fired would be hiding half of what it did. The rule that stayed quiet is recorded with the same detail as the three that did not, because the question later is never only what applied.
What a chain writes into the file
- The rule that armed itNamed
- Conditions that did not fireRecorded
- The requirement itselfAdded
- Satisfied by the engineNever
An armed requirement is a thing the file now needs, not a thing the engine then provides. It appears on the checklist, it names the rule that put it there, and it is closed by whoever actually does the work.
Thresholds are the part of a policy that demonstrates well. Conditions are the part that makes it a policy — and the one that never fired is on the record for the same reason the other three are, which is that somebody may one day need to know what this file was measured against.
Documented overrides
A reviewer can go past the rule. The record does not forget that they did.
Overrides are most of the reason to have a policy engine — a lender who cannot depart from their own rule has a cage rather than a policy. What matters is what survives afterwards.
- 04
- Criteria in this run
- 03
- Reviewer entries
- 00
- Engine outcomes changed
Two lanes, and one of them never movesChoose a row to read the reason that was entered with it. The left lane is what the engine produced and it is fixed; the right lane is what a person added afterwards. Nothing on the right rewrites anything on the left.
Why it is appended rather than applied
An override that edited the finding would leave a file that looks like it always passed, and a policy engine whose output can be quietly rewritten is worth less than no policy engine at all — because everybody would know the record had been made to agree with the outcome.
So both survive. The engine's finding stays exactly as it was produced, the reviewer's entry sits beside it under their name with their reason in their own words, and the version of the policy in force at the time stays attached to both.
What the override record keeps
- The policy version in forceRetained
- The engine's own outcomeUnchanged
- Who entered itNamed
- Their reason, in their wordsVerbatim
- Editable afterwardsNever
Cevrynt is not a lender and takes none of these decisions. The reviewer's entry is the decision; everything the platform does around it is keeping an honest account of what the rule said, what the file showed, and who departed from which.
An override is not the engine being wrong and corrected. It is a person taking a decision the engine was never allowed to take — and the only thing that makes it defensible six months later is that anybody looking can still see the rule, the reading, the name and the reason, exactly as they stood.
Founder-led
Bring the rule nobody can write down.
Every credit team has one: the condition everybody applies and nobody has put into words, the exception that gets made for a particular kind of deal, the threshold that is really two thresholds depending on the season. Describe one of those and we will work out together whether it belongs in a policy engine or in front of a person.