DEV Community: Seven Billion Analytics

MRP Is Correct and Still Wrong: A Worked Example

Seven Billion Analytics — Wed, 14 Oct 2026 13:02:56 +0000

If you work on ERP integrations, you will meet MRP sooner or later. It is worth understanding exactly what it computes, because its blind spot explains a lot of support tickets from the shop floor.

Take an illustrative snack maker. The master production schedule says week 3 needs 11,000 cases of a 200 g pack. That figure came from a 12,000-case forecast, minus 2,000 in stock, plus a 1,000-case buffer.

MRP now runs three steps:

Explode the BOM. Each case needs 24 pouches of film, so 11,000 cases need 264,000 pouches.
Net against stock. There are 64,000 pouches on hand, leaving 200,000 to buy.
Offset by lead time. The supplier needs two weeks, so the purchase order releases two weeks before week 3.

Clean, deterministic, and correct. Now notice what is missing. Nothing in that calculation checks whether the packing line can run 11,000 cases in that week alongside everything else. Nothing knows that two big orders share a due date and pile onto Tuesday. Nothing prices the changeovers between flavours. MRP assumes infinite capacity and fixed lead times, on purpose.

Most ERPs add a rough-cut capacity check by work center and week. It might say packing is at 90%, which looks fine, while one day inside that week is badly overloaded. RCCP tells you a week is too full. It does not tell you which order to move.

Takeaway for developers: if you are building reports or alerts on ERP data, do not treat MRP planned orders as a schedule. They are material timing. A schedule needs a finite model where every resource has a calendar and setups are sequence-dependent. Label your dashboards accordingly and you will avoid a whole class of confused users.

That finite layer is what our finite capacity production scheduling accelerator adds, reading from the ERP and writing back only approved plans.

Full comparison of MPS, MRP and APS: MRP vs APS vs MPS: What Each Layer Decides

Scheduling Is a Constraint Problem Before It Is an AI Problem

Seven Billion Analytics — Wed, 14 Oct 2026 13:01:51 +0000

If you are a developer handed a "make our factory schedule smarter" ticket, the first instinct is often to reach for a model. Resist it for a moment. Production scheduling is mostly a constraint satisfaction problem, and the hard part is getting the constraints right.

Here is the shape of it. Inputs come from the ERP: production orders, routings, bills of materials, work-center calendars and stock. Then come the limits. Line capacity, shifts and operator skills, maintenance windows, tooling, material arrival dates, and sequence-dependent changeover times from a changeover matrix. Then the odd plant-specific rules. One dairy plant we built for had to respect blast-freezer curves, because a run that clashes with freezer capacity simply cannot happen.

The solver underneath is a constraint-programming and mixed-integer model (CP-SAT or MILP). Its job is not to find one perfect answer. It returns several feasible plans that trade changeovers against overtime against late orders, fast enough for a person to compare them. In that dairy case, a week of plans comes back in 90 seconds.

The key concept is finite capacity. Basic ERP logic usually assumes every machine has unlimited capacity, so it can load three weeks of work onto a line that has two. A finite model only places an operation where a resource actually has room, which is why its output can run as written.

Takeaway for builders: the most valuable artifact in these projects is often not code. It is the written list of rules that until now lived in a senior planner's head. Many of them have never been documented anywhere. Spend your first session extracting and encoding those rules, and the solver work gets much easier.

The approved plan then goes back to the ERP or MES with an audit trail, and the ERP stays the system of record. Our AI production scheduling page shows how that integration is structured.

Full walkthrough, step by step: How to Schedule Production with AI: A Guide

Designing RAG for Lawyers: Refusal Is a Feature

Seven Billion Analytics — Wed, 14 Oct 2026 13:01:36 +0000

Building retrieval-augmented generation for a law firm teaches you something general chat products tend to hide: the most important output is sometimes "I can't answer that."

The pattern itself is familiar. Ingest the firm's corpus (briefs, memos, contracts, matter files, playbooks), usually from SharePoint, iManage or a document store. Group it into matter workspaces. At query time, retrieve passages by meaning, then generate an answer only from what was retrieved, with a numbered citation per claim that links back to the source paragraph.

Three design choices matter more than model choice:

Semantic retrieval. Lawyers ask questions the way a partner would. "Who carries the risk if the platform leaks customer data" should surface indemnity and confidentiality clauses even if neither contains the word "leak." On one SEC filing search project, plain-English queries ran 3.4x faster than the 256-character Boolean strings analysts had been writing.
Hard refusal. If retrieval does not support an answer, the system says so and stops. Filling gaps with something plausible is exactly the behaviour you are designing out.
Human gate in the pipeline. Drafts come back as tracked changes with Accept or Reject per change. Nothing is filed or sent until an attorney signs off, and that event is logged.

Corpus condition also beats corpus size. Clean case law ingests quickly. Twenty years of scanned matter files need cleanup first, and that work shows up in the estimate.

Takeaway for engineers: write your evaluation set before you tune anything. Use research the firm's team already did by hand, measure precision and recall against it, and add missed-case audits on live work. Those numbers, not demo impressions, should decide whether the system goes to production.

For scope, integrations and how a build runs, see our custom legal AI for law firms service page.

Full step-by-step architecture: Custom Legal AI for Law Firms: How It Works