23 September 2026

Rifat Jumagulov · How this is checked

One Accident, Several Laws, One Answer

An insurer pays 730,000 tenge. The payment is twelve days late. Following the rules from the insurance statute to the Civil Code produces another 4,020 tenge—and a record of how that amount was reached.

The money has arrived. Has the insurer finished paying?

In this fictional motor-insurance case, the insurer receives the required documents on 22 July 2026 and pays 730,000 tenge on 24 August. Arxo computes the payment deadline as 12 August. Payment was late; under the stated calculation inputs, the late-payment penalty is 4,020 tenge.

Each part of that answer comes from somewhere different. The insurance statute supplies the payment period and the obligation to pay a penalty. The Civil Code supplies the rule for that penalty. A National Bank rate and an official calendar supply dated values. The case supplies the payment events and an explicit assumption needed for the arithmetic.

A single bank transfer has led us across several sources. The useful result is an answer whose steps can be inspected together.

Start with events

The example belongs to a collection of five fictional cases about Kazakhstan’s compulsory motor third-party liability insurance, known as OGPO VTS. The main case is deliberately small:

The 730,000-tenge insurance payment is an input in this example. The calculation begins after that amount has been established. It does not reconstruct repair costs from photographs or decide the disputed facts of the accident.

There is no input labelled “the insurer paid late.” That is one of the questions the rules must answer.

This distinction matters when building a legal application. If a person supplies the conclusion and the software merely repeats it, the central reasoning remains outside the computation. Here, the case supplies two events: receipt of documents and payment. The model must connect them through the applicable deadline.

A deadline has dependencies

Article 26(1) of the motor-insurance statute provides the general period used in this case: fifteen working days from receipt of the documents specified in Article 25.

For documents received on Wednesday, 22 July, the recorded calendar and counting policy place the deadline on Wednesday, 12 August. The payment on 24 August comes after it. The late-payment period runs from 13 through 24 August, twelve calendar days.

The two intervals use different clocks. Working days establish when payment falls due. Calendar days measure this period of delay. A calculation that treats both intervals as the same kind of duration can get the amount wrong even when its multiplication is correct.

The calendar is therefore part of the case’s supporting data. Someone checking the deadline needs the calendar used for the calculation, alongside the date and the rule.

The insurance law sends us to the Civil Code

Article 26(4) imposes a penalty for late payment and refers to Article 353 of the Civil Code for its procedure and amount. The payment-day calculation used here takes the National Bank base rate applicable on the day the obligation is performed.

In the recorded case, that annual rate is 16.75%. With the explicitly supplied divisor of 365, the arithmetic is:

730,000 KZT × 12 days × 0.1675 ÷ 365 = 4,020 KZT

The amount is exact for these inputs. The case also establishes that the obligation to pay the late-payment penalty is active.

The saved analysis below compares this case with payment on the deadline itself. Both have the same deadline, 12 August; payment on 24 August establishes lateness. Open the analysis to inspect the 4,020-tenge result and the penalty obligation. The interface is available in English; the case questions are in Russian.

The implementation preserves the division of responsibility between sources. The insurance rule creates the obligation; the Civil Code provides the referenced basis; dated rate data supplies a value; an accrual calculation applies it. The connection between those parts does not introduce another legal rule of its own.

That is what makes the cross-reference useful to software. A reader can follow it. An executable model can carry a result across it while retaining its origin.

Remove one assumption

The divisor of 365 deserves its own line in the input table. Article 353’s payment-day rate provision does not specify the annual-to-daily conversion convention. This model requires that convention to be supplied explicitly.

Remove the divisor from the same case. The payment is still late: the dates and calendar are unchanged. But the model no longer derives a penalty amount.

That outcome keeps two questions separate:

• Was payment late? Established.
• What penalty amount follows from these inputs? No amount derived.

A zero in the second field would erase that distinction. So would silently inserting a familiar financial convention. The saved explanation identifies the amount rule as unestablished; it does not itself trace the missing divisor through every intermediate calculation. The paired cases show exactly which input was removed.

Now make a different change: supply both 24 and 26 August as the single payment date for the same claim. Those assertions conflict with the field’s uniqueness requirement. The evaluation is marked NON_EXECUTABLE. Any amount retained in its diagnostic output must be read with that status; it is not an accepted answer to the conflicting case.

Move the case across a holiday

Another case in the collection moves receipt of documents to 19 October 2026 and payment to 10 November. In the recorded calendar, Republic Day falls on Sunday, 25 October, with the day off transferred to Monday, 26 October.

The deadline is 10 November. The alternative date, 9 November, is not established; payment on 10 November does not establish lateness. The saved analysis also contains the missing-divisor and conflicting-date variants.

These are small changes to one case, but they exercise different parts of the reasoning: date calculation, sufficiency of inputs, and consistency of assertions. A single “valid” checkbox would lose information the reader needs.

The rest of the accident has its own sources

The deadline-and-penalty example sits within a wider motor-insurance model. Following a case from policy purchase to a dispute brings further sources into view:

These are branches with their own conditions. A dispute does not, by itself, establish eligibility for every procedure. A change in the insurer’s status calls for a fresh check of the guarantee conditions. The five cases shown here exercise the payment deadline and penalty branch.

A software package can connect provisions from several acts, while one act can contribute to several stages. Regulations, annual tables and calendars matter alongside statutes. Each rule and value retains its source as the case moves between them.

What one answer contains

For the main case, a useful answer keeps four results together: the deadline is 12 August; payment on 24 August was late; the stated inputs yield a 4,020-tenge penalty; the penalty obligation is active. It also preserves the facts, rules and assumptions behind those results.

The displayed analyses are saved evaluations. In a local check on 23 September 2026, all sixteen case-and-question evaluations in the captured collection matched their saved command-line evaluation documents byte for byte when run through the local WebAssembly engine. That checks reproduction on those fixed inputs; the legal interpretation and the evidence for the case remain separately reviewable.

Arxo executes the canon. Models formalize; Arxo executes and proves. In this example, the practical payoff is that a reviewer can follow the path from two payment events through a deadline and a statutory cross-reference to an additional obligation.

The bank transfer answers whether money arrived. The connected rules answer what that payment leaves owing.