Deposit Dispute and the case for deterministic arithmetic

Security-deposit disputes look simple until you try to automate one. A person uploads a lease, some messages, a move-out note, and a list of charges. Then they ask a system what the evidence supports. The hard part is not the subtraction. The hard part is separating factual extraction from legal or contractual interpretation, then showing your work.

Deposit Dispute is a useful example of this split. Its description is concise: models rule on evidence, the contract does the arithmetic. That design choice matters. If you mix free-form model judgment with monetary calculation, you lose auditability fast. If you isolate the contract terms and turn them into explicit math, you give the reader a path to verify every step.

For practitioners, this pattern reaches beyond landlord-tenant issues. Any workflow with unstructured evidence and structured payout rules faces the same problem. Claims intake, invoice disputes, chargebacks, and compliance exceptions all need a boundary between what a model infers and what deterministic code computes.

Keep evidence judgment and money math separate

The core engineering decision here is decomposition.

One layer reads evidence. It extracts statements, dates, amounts, conditions, and conflicts. It weighs whether a charge appears supported by documents or contradicted by other records. This is where model behavior belongs, because the inputs are messy. They contain PDFs, screenshots, text fragments, and inconsistent wording.

A second layer reads the governing contract. It identifies the clauses that control deposits, deductions, deadlines, cleaning obligations, damage standards, notice requirements, and any itemization rules. Then it converts those terms into explicit variables and formulas.

A simple mental model looks like this:

Evidence layer
- What damage is claimed
- What proof exists for each claim
- What dates and notices appear in records
- What amounts are requested
- What contradictions appear

Contract layer
- Which deductions are allowed
- Which conditions must be met first
- Which deadlines affect the outcome
- How the final amount is computed

Why this split matters:

• You reduce hidden reasoning inside one opaque answer.
• You make arithmetic reproducible.
• You localize disputes. A reviewer can challenge the evidence read, the contract parse, or the formula, instead of the whole output.
• You keep the model from inventing numbers during narrative synthesis.

This class of system often goes wrong when teams ask one model prompt to do all of it. The result sounds fluent, but the money trail is hard to inspect. A charge gets accepted because the explanation seems coherent, not because each precondition was met.

Inspect the contract as executable policy

“The contract does the arithmetic” is the strongest signal in the description. It implies the governing document is not treated as background context. It is treated as a source of rules.

In practice, you want a contract representation with fields like these:

• Deposit amount
• Permitted deduction categories
• Excluded categories
• Notice or itemization deadline
• Required documentation for deductions
• Grace periods or cure windows
• Move-in and move-out condition references
• Formula inputs for any caps, offsets, or prorations

You do not need a full legal expert system to get value from this. You need a constrained extraction target and deterministic evaluation after extraction.

For example, the pipeline might look like this:

1. Parse the contract for relevant clauses.
2. Normalize clauses into a schema.
3. Map evidence items to each clause condition.
4. Compute allowed and disallowed deductions.
5. Produce a ledger with every subtotal and reason.

The verification step is key. A reader should be able to trace each line item to:

• the contract clause it depends on
• the evidence record it cites
• the arithmetic expression used

If you are building a similar system, inspect whether clauses are handled as text spans only, or converted into typed fields. Text spans help with explainability. Typed fields help with execution. You often need both.

Common failure modes here are mundane:

• A clause is extracted, but the exception attached to it is dropped.
• A deadline is read, but time zone or date format changes the result.
• A cleaning fee appears in a charge sheet, but the contract only allows cleaning deductions under narrow conditions.
• A cap or offset is missed, so a valid deduction is overstated.

These are not language-model problems alone. They are schema and validation problems.

Verify claims with a ledger, not a paragraph

Narrative explanations help people read the result. They do not help much with validation. For validation, you want a ledger.

A good dispute output should break the result into units like these:

• Charge name
• Claimed amount
• Evidence support status
• Contract basis
• Preconditions met or unmet
• Allowed amount
• Reason for reduction or rejection

That structure does two things. First, it forces the system to commit to a line-by-line view. Second, it prevents a common error where the top-line answer looks plausible while one or two unsupported charges slipped through.

A reviewer should be able to test the output with a small checklist:

• Does every deduction have a cited contract basis.
• Does every deduction have supporting evidence.
• Are the dates consistent across lease, notices, and move-out records.
• Is each subtotal reproducible from visible inputs.
• Does the final amount equal the sum of allowed line items and offsets.

This is where deterministic arithmetic earns its place. Once the allowed deductions are decided, the remaining work is bookkeeping. Bookkeeping should not be probabilistic.

A system like this also benefits from explicit handling of uncertainty. Instead of one blended answer, it should surface where evidence is incomplete or contradictory. Examples include missing receipts, ambiguous photos, or a charge sheet with no matching clause. Those are signals to investigate, not places for the model to smooth over gaps.

Read the weak signals in the evidence pipeline

The phrase “models rule on evidence” points to another engineering concern. Evidence is rarely a clean table. It arrives as documents with OCR errors, screenshots with partial context, and messages with implied timelines.

What should you inspect in such a pipeline?

Provenance

Each extracted fact should carry its source. If a date came from a move-out email, the system should say so. If an amount came from an attached invoice, the line should point there.

Conflict handling

When two records disagree, the system should preserve the conflict. It should not merge them into a neat middle ground. If one message says the carpet was replaced and another says it was cleaned, both claims matter.

Missingness

Absence is data. If no receipt supports a repair charge, the system should record the gap. Silence should not be treated as confirmation.

OCR and parsing confidence

Amounts and dates are brittle fields. A single digit error changes the whole outcome. Good systems isolate low-confidence reads for review instead of feeding them straight into formulas.

Where this class of system often fails is overconfidence. A document parser extracts “$180” from a blurry scan. The downstream model treats it as solid fact. The final arithmetic looks precise, but the source was unstable from the start.

One way to contain this is to require typed facts with source citations before any formula runs. If a required fact lacks a stable source, the line item should remain unresolved.

Design for appeal and re-computation

Disputes do not end at first output. People challenge facts, upload new records, and contest clause interpretation. So the system should be built for recomputation.

That means:

• Facts are stored as discrete items, not buried in a summary blob.
• Contract terms are versioned as extracted fields plus source spans.
• Arithmetic is rerun when any prerequisite changes.
• Explanations are generated from the current ledger, not hand-written once.

This matters because appeals often target one narrow point. A new receipt appears. A move-out date is corrected. A clause exception is found. You should be able to update one node and recompute the result without re-litigating every other line.

It also improves testing. You can write unit tests for formulas, regression tests for clause extraction, and fixture-based tests for evidence conflicts. Without this separation, quality work collapses into prompt tweaking.

The broader lesson is simple. If the output affects money, treat the model as a reader of messy records, not as the calculator of record.

What to watch next

The next step for systems like this is better visibility into failure points. Watch for whether the product shows source-linked facts, clause-to-formula mapping, and unresolved conflicts before it shows a final total. Those signals tell you whether the system is built for inspection or for presentation.

Deposit disputes are a narrow domain. The engineering pattern is not. When evidence is ambiguous and the rules are structured, you want models for the first part and code for the second.