TRUST / DETERMINISTIC CALCULATIONS

Deterministic calculations: AI reads the file, rules compute the number

The most important design decision in Olycor is a boundary: AI is allowed to interpret your data, and it is never allowed to compute a number a lender relies on. Those numbers come from a rules engine.

DIRECT ANSWER

Deterministic means the same inputs and the same rule versions always produce the same output, with no probabilistic step in between. In Olycor, AI handles data interpretation, mapping columns, matching obligors, reading PDFs, while eligibility, advance rates, reserves, and concentration limits are computed by a versioned rules engine configured to your credit agreement.

THE TWO-JOB SPLIT

Two jobs, two tools, one hard boundary.

Receivables data is messy in ways only judgment can fix, and lending math is exact in ways judgment must never touch. Most tools blur the two. Olycor splits them.

JOB ONE: INTERPRETATION

AI reads what humans produced

  • Maps a CSV whose headers say TranDate, Cust, and Amt Rem to invoice date, obligor, and open balance
  • Matches "Meridian Components", "Meridian Components LLC", and "MERIDIAN COMP" into one obligor group
  • Extracts invoice tables from a PDF statement a subsidiary emailed at close
  • Classifies a negative line as a credit memo rather than a negative invoice
  • Attaches a confidence score to every interpretation and routes doubt to a human
JOB TWO: CALCULATION

Rules compute what lenders rely on

  • Eligibility tests: aging, cross-aging, jurisdiction, currency, disputes, contras
  • Concentration limits per obligor group, with excess concentration deducted
  • Advance rates applied to the eligible pool as the agreement defines them
  • Reserves: dilution, loss, yield and servicing, and any bespoke formula in your documents
  • No model, no sampling, no temperature. Configuration in, number out

The handoff between the two jobs is inspectable. Every interpretation the AI makes is recorded as a decision with a confidence score, anything uncertain goes to a person, and only confirmed, structured data enters the calculation. That record is part of the lineage described in source-level auditability.

WHY THE BOUNDARY EXISTS

Why probabilistic math is unacceptable for lending numbers

A borrowing base certificate is a signed compliance document. A servicer report feeds amortization triggers. The numbers on them create legal consequences: a materially wrong certificate can be a default under the credit agreement, and an overadvance discovered later usually must be repaid immediately. A number with those consequences cannot come from a system that might answer differently tomorrow.

Language models are probabilistic by construction. Ask one to sum a 4,000 row aging file and it will usually be right, which is precisely the problem: usually is not a standard any treasurer can sign under, and an error rate you cannot bound is worse than one you can. An occasional wrong digit in a $27,800,000 borrowing base is not a rounding issue. It is a misreporting event.

So the rules engine contains no model at all. An invoice is 91 days past due or it is not. An obligor group is over its 15 percent concentration limit by $312,000 or it is not. Arithmetic on facts, per the agreement, every time.

REPEATABILITY

Same inputs, same rules, same output, every time

Every calculation run gets an ID and records exactly three things: the input snapshot, the rule versions, and the output. Rerun the June certificate in November, during a field exam, with the same inputs and versions, and you get the same result to the cent. Reviewers can test this whenever they want, and skeptical reviewers should.

Repeatability is also what makes review meaningful. When the preparer and the approver look at a run, they are looking at the same deterministic artifact, not two refreshes of a live spreadsheet that may have shifted between them. And when a number changes between two runs, the cause is always identifiable: the inputs changed, or a rule version changed. There is no third possibility, which is exactly the property a variance question needs.

RULE VERSIONING

Rules are configured to the credit agreement, and versioned

Deterministic does not mean generic. Two facilities can define the same concept differently: one excludes receivables 90 days past invoice date, another 60 days past due date; one caps any single obligor at 10 percent, another at 20 percent with named exceptions; cross-aging thresholds range from 25 to 50 percent. Olycor encodes your definitions from your documents, so the engine computes your facility, not an industry average of one.

Every configuration is versioned. An amendment that moves the advance rate from 85 to 87.5 percent becomes a new rule version with an effective date, an author, an approver, and a note pointing at the amendment. Old reports keep the versions that produced them. The rule set is auditable history, the same way the data is.

SECURITY POSTURE

Where our security program stands, stated plainly

Olycor is an early-stage product handling sensitive financial data, and we would rather be precise than impressive. Certifications such as SOC 2 and ISO 27001 are on our roadmap and are not yet attested; we do not claim them, and you should not accept the claim from any early-stage vendor without a report. What exists today: encryption in transit and at rest, role-based access with separation between preparer and approver, tenant isolation, and audit logging of user and system actions. We share our current control documentation and roadmap with prospective customers under NDA, and we expect your security team to ask.

Frequently asked questions

Does AI ever calculate a number on my certificate?+
No. The boundary is architectural, not a policy. AI runs in the interpretation layer: mapping columns, matching obligor names, extracting data from PDFs, classifying credit memos. Its output is structured data plus confidence scores, and low-confidence interpretations become exceptions for a person. Every calculated figure, eligibility, concentration, reserves, availability, is produced by the rules engine, which contains no model and no randomness.
What happens when my credit agreement is amended?+
The configuration is updated to match the amendment and saved as a new version with an effective date, the change, who made it, and who approved it. Reports run after the effective date use the new version; historical reports keep the version that produced them. When a lender asks why April and May treated the same obligor differently, the answer is a documented rule change, not a mystery.
Can I verify the determinism myself?+
Yes, and you should. Rerun any historical report: same inputs, same rule versions, same output, to the cent. Run the same file twice in a row and diff the results. This is also the honest limitation to understand: determinism means the rules run exactly as configured, so if a rule is configured wrong it will be wrong consistently. That is why configuration is reviewed against the credit agreement and every version is auditable.
How is this different from a spreadsheet, which is also deterministic?+
A formula is deterministic until someone edits it, and spreadsheets are edited constantly, without versioning, review, or any record of what changed. The practical failure is not randomness, it is drift: a filter left on, a pasted-over formula, a tab that no longer sums. Olycor's rules are code with versions, approvals, and an execution log, so the determinism survives contact with month end.

RELATED READING

Or browse the full receivables finance glossary and the eligibility rule library.

Last updated July 9, 2026. Olycor does not provide legal, tax, accounting, or credit advice. Facility terms, eligibility criteria, and reserve mechanics vary by credit agreement; your agreement governs.

Numbers you can sign. Twice in a row, if anyone asks.

Olycor is onboarding borrowers who want AI on the messy part of the job and code on the part that gets signed.