Correctness isn’t a review step.

It comes from where the rules live. Here’s how we build.

Fig. 1.0

Instrument → Parameterise → Enforce

  1. Instrument

    The prakas, sub-decree or law is read in Khmer, in full, and recorded as a dated source with its issuing authority.

  2. Parameterise

    Rates, ceilings, bases and effective dates become versioned data, never constants in code.

  3. Enforce

    Every product reads the same parameters. One change propagates everywhere, with a test proving it.

The same three steps, drawn. Each instrument recorded once, read by everything that depends on it.

Source instrument
Prakas 449/2017 LV/PrK
NSSF contribution rates.
Source instrument
Prakas 075 MEF.Prk
E-invoicing submission.
Product
IustumHR
Payroll, NSSF, seniority
Product
IustumBill
E-invoice submission
Integration
Client systems
Whatever you already run
Fig. 2.0

What we hold ourselves to

  • Row-level security designed in from the first migration, not added afterwards
  • Every schema change is a reviewed migration; nothing is edited in a production database by hand
  • Adversarial test fixtures — we test with data designed to break it, not data designed to pass
  • Money is tested to the unit
  • Every regulatory parameter cites its instrument and carries a review date
  • Nothing ships undocumented
Fig. 3.0

What we don't do

  • We don’t take projects we can’t test.
  • We don’t build things we can’t hand over.
  • We don’t take work where the deadline requires skipping the review.
  • We don’t advise on technology we wouldn’t run ourselves.