Repleni Flow moves invoices, purchase orders, and payment records between systems. That means it operates under a rule that most software never has to think about: it is not allowed to fail quietly. A crashed dashboard annoys someone. A silently dropped invoice costs someone money, and they find out weeks later.
That rule shaped how we build everything else. A few habits stuck.
Fail loudly, and in one place
Every pipeline run ends in one of three states: completed, needs review, or failed. There is no fourth state, and nothing is allowed to disappear between states. When a run fails, a human gets told, in the channel where they already work. The worst failure mode in automation isn't an error. It's an error nobody hears about.
Make every step safe to repeat
Networks drop. APIs time out. Accounting software goes down for maintenance on a Tuesday afternoon for no reason anyone can explain. When a step gets retried, it has to be safe to run twice. Otherwise a retry books an invoice twice, and the automation has created work instead of removing it. We design every step so that running it again is always harmless. That single constraint prevents a whole category of disasters.
Know when to hand it to a human
Extraction is probabilistic. Most documents are routine, some aren't. Early on we made a decision that felt like a compromise and turned out to be the product: when the system isn't confident, it stops and asks. A pipeline that handles the routine work automatically and routes the odd cases to a person is enormously more useful than one that guesses. Nobody trusts a system that's confidently wrong once.
Choose boring parts
The AI in Repleni Flow is the interesting bit, so everything around it is deliberately dull: a relational database, a job queue, plain retries with backoff, logs you can actually read. When something misbehaves at 6 a.m., you want the search space to be small. Novel infrastructure is a tax you pay during exactly the incidents when you can least afford it.
What it adds up to
None of this is machine learning. That's the point. The model is maybe a fifth of the work; the rest is the unglamorous engineering that makes people comfortable letting software touch their books. Reliability isn't a feature of the system. It's the reason anyone turns it on.