Navix's IDP models now capture well over 99 % of the documents our customers process. But edge-case errors still crop up-often affecting a single customer or document type. We hear the frustration: "Can't you just fix it?"
1 Why a “Quick Fix” Isn’t Always Quick
Plain‑English version (skip this if you’d rather head straight to the nerd stuff):
- Think of traditional software like LEGO bricks. If one brick pops off, you click it back in and everything else stays put.
- Our IDP engine is more like a living sourdough starter. It “learns” from tens of thousands of past documents. If we change the recipe for one loaf, we have to make sure the whole batch still rises.
- In other words- we don’t “fix” things in the model, we change things in the model, and when we’ve reached this high a level of accuracy, the odds become greater that “fixing” one thing ends up breaking something else that’s working.
For those who speak tech‑nerd:
| Classic bug fix | ML model update |
|---|---|
| Edit deterministic code → rebuild | Collect fresh labeled data → retrain weights |
| Unit tests on affected path | Full regression across 40 k+ docs & 300+ fields |
| Fast rollback via feature flag | Model versioning + shadow deployment |
| Localized impact | Non‑linear effects across customers & doc types |
Bottom line: we batch edge‑case fixes into scheduled training cycles so overall accuracy keeps rising instead of trading one error for another.
| Deterministic code—change one line and re‑deploy | Probabilistic model—re‑train on thousands of samples to shift prediction weights |
|---|---|
| Impact is isolated to a single feature or path | A small change can ripple across fields, document types, and customers |
| Unit tests instantly verify success | We must re‑run a 40 k+ document regression suite to ensure no new errors emerge |
Because the model learns complex patterns, fixing one edge case without enough data can unintentionally lower accuracy elsewhere. That’s why we pace updates carefully.
2 Our Continuous‑Improvement Pipeline
3 What Happens After You Submit an Issue
| Step | What we do | Typical timeframe* |
|---|---|---|
| 1. Acknowledge | Confirm receipt; log details in our database | < 1 business day |
| 2. Pattern discovery | Look for similar cases across customers | 1–4 weeks |
| 3. Retraining window | Wait for sufficient examples & schedule sprint | 4–12 weeks |
| 4. Release & notify | Publish release notes; link to relevant tickets | Quarterly |
Actual timelines vary with complexity and data availability. Critical accuracy issues with a lot of examples can sometimes be delivered more quickly.
4 How You Can Help Us Move Faster
- Send original documents (PDF, image, EDI) instead of screenshots.
- Highlight the exact field(s) that were mis‑extracted.
- Provide multiple examples—even anonymised samples are valuable.
- Give Real Data - How often is this actually impacting your users?
The richer the dataset, the sooner we can safely retrain.
5 Our Commitment
- Every report is tracked. Nothing is ignored or deleted.
- Quality over speed. We only promote a model when it improves overall accuracy.
- Transparency. You’ll see IDP changes called out in our release notes and follow‑ups to your tickets.
- Faster edge‑case handling on the horizon. Our roadmap includes large‑language‑model (LLM) fallbacks and a flexible Business Rules Engine that will let us patch rare, one‑off issues quickly without risking model accuracy.
Thank you for your patience and partnership as we continue to push the boundaries of automated document processing together.