The robot factory received its bolts three times

In one line

An FDE's first deliverable is not a fast script but a contract that turns the customer's words into business rules that can be checked.

Why this was needed

A message comes in from a fictional robot factory. "I uploaded the order file again and the warehouse got the same reservation twice. I thought it had failed, so I just pressed it once more." The customer says to get rid of the duplicates. But what is a duplicate? The same row in the file, the same event, or the same order? If the order number is the same but the quantity changed, is it an amendment or a wrong input? If you write code without answering these questions, you quickly build the wrong automation.

In this course, you are an engineer who delivers a small integration together with a customer. We assume you can read Python functions and dictionaries, CSV, and HTTP requests. If they are still unfamiliar, go through the earlier FDE data and API labs first. This is not a reenactment of a real logistics incident but a teaching scenario built with synthetic data and a fictional warehouse. There is no real shipment, payment, or inventory movement.

How it works

First, split the customer brief into three questions. What is the automation allowed to change? What information may be sent? Who decides when a judgment is ambiguous? The scope this time goes only as far as the warehouse reservation. Instructing delivery, or having an engineer pick one of the conflicting quantities, is out of scope. The email address is in the source but is not needed for the reservation, so it is not sent.

A row's event_id is the number of the delivery event, and order_id is the number of the business order. Even if the same order arrives again as a different event, it does not become a new purchase. Conversely, if you merge different orders just because the SKU is the same, you lose a normal order. So the duplicate criterion agreed with this customer is order_id and the contents of that order. This does not mean it is a universal key that applies to every company. A company that needs split shipments or order amendments first needs a contract about versions and shipment numbers.

The distributed CSV has seven data rows. Counting the header as row 1, they are classified as follows.

Data row	Observation	Handling
2·3·4	Three different normal orders	Each is a send candidate
5	Same order, SKU, and quantity as row 4, different event	Recorded as a redelivery
6	The quantity is two	Held as invalid
7·8	Same order but the quantities are 1 and 3	Both rows held as a conflict

The result is 3 candidates, 1 redelivered row, and 3 held rows. You do not send seven rows seven times. "We removed the duplicates, so we threw away three" is also a wrong explanation. A hold is not a deletion but a state of waiting for a person's judgment, and the row number and the reason must remain.

If you read one line at a time and send right away, you send row 7 and then discover the conflict in row 8. You cannot cancel what was already reserved by simply removing it from the CSV. That is why you validate the whole file first, gather all the rows of the same order and judge them, and only then send. If there is even one invalid row under a valid order number, you hold that whole order. An invalid order number is not copied into the report as it is, and is found through null and the row number.

For the quantity, only the CSV characters 1–5 are accepted. Correcting 02 or 2.0 to the number 2 looks convenient, but it is an input correction the customer did not allow. The maximum of 100 rows and 256KiB is also an input contract of this exercise. To handle a bigger job, you would have to redesign streaming validation, batch boundaries, the retention period of duplicate records, and so on.

Rows you may send and orders you must send

Let us think of one more row as an exercise. ORD-EXTRA ordered two ROBOT-BOLT, and another order, ORD-SECOND, also ordered two bolts in the same way. If you compare only SKU and quantity, they look like the same row, but there are two business orders, so both are candidates. On the other hand, if only the event of ORD-EXTRA comes in again under a new number, you do not increase the candidates. Writing these two examples side by side lets you confirm with a colleague the different meanings hidden in the single phrase "remove duplicates".

Another mistake is quietly skipping a wrong row. If an order the customer expected does not appear, they may upload the file again after the run finishes. Then even the orders that were processed normally get repeated. Leaving the row number and a short reason in the hold list is not decoration on an error report but information that decides the next business action. You do not need to put the whole original text of a held row into the log. You keep the original and the report only points to where to check.

Before implementing, write three sentences. "The same content of the same order is reserved only once." "If there is a conflict or an invalid row, do not send that whole order." "Leave the hold reason but do not carry over unnecessary customer information." Each one turns into a test that checks the candidate list, the hold list, or the actual requests. If the customer does not agree with these sentences, you have to fix the contract before the implementation details of the code.

What it looks like in the field

The OpenAI FDSWE job posting that we checked on 2026-09-11 covers understanding customer needs, iterative implementation, and writing the scope of work for a PoC and a production deployment. The Palantir FDSE job posting describes work that continues from an ambiguous problem through design, prototyping, and data integration. This course turns part of that work into a small exercise. It is not a hiring exam or a guarantee of acceptance, and the two postings are examples of specific roles in the United States and do not represent the whole Korean hiring market.

What to check next

In the next quiz, you distinguish the boundaries to agree on before sending and the criteria for a hold. Before implementing, try explaining in one sentence "what result would let the customer confirm it is right". In this lab, the criterion is that only the orders that were not held are confirmed as exactly one reservation each, and the rest remain with their reasons.