Materials First: Why the AI Either Runs the Whole Production Cycle or Stops
A firm that makes something has a recipe, a shelf of ingredients and a customer waiting. What it usually does not have is a single place where those three meet. The recipe lives in someone's head or in a spreadsheet, the ingredients are counted by eye, and the question of whether the job can start today is answered by walking to the back and looking. The accounting is even further away: it records what was bought and what was sold, and has no idea that the raw material was consumed last Tuesday to build a product that does not exist yet.
In Firmspace that recipe is called a specification, and it is a first-class record rather than a note. A specification for a product lists its components with a quantity per single unit and an optional waste percentage, a set of operations with a name, a duration in minutes and a cost per hour, and an overhead percentage that is added on top of labour to cover everything that is not a material and not a wage. Both the product and every component have to exist as stock items of the goods type before they can be used, which sounds pedantic until you have tried to cost a product whose main ingredient was never created as an item.
Specifications are versioned instead of edited. Saving a new specification for the same product creates the next version and leaves the older one in place, and an order that was already planned keeps being costed by the version it was built on. That single rule is what makes a price quoted last month still explainable today: the numbers behind it have not quietly changed underneath the order. A product also cannot be listed as a component of itself, and a specification with neither materials nor operations is refused outright, because it would produce a cost of nothing and a product out of air.
Real products are usually not one level deep. A crate contains a frame, the frame contains cut parts, and the cut parts contain timber, so the specification has to be exploded: the system recurses through the components that have specifications of their own and sums up the raw materials and the operations needed for the whole batch. Components without a specification are treated as purchased items, which is exactly what you buy from a supplier rather than make. If two specifications refer to each other in a circle, the calculation does not fall over and it does not silently pick one of them — it reports the cycle, because a loop in a bill of materials is a data error that someone has to see and fix.
Once specifications exist, the missing-number question has an answer. The material requirements view takes the open orders, works out what each still has to produce, explodes their specifications, and lists every material with three figures side by side: required, in stock, and the difference that has to be bought. That is the difference between a purchasing decision and a guess. It is also computed from your own movements and your own orders, so it reflects the firm as it actually is rather than an industry average that describes nobody.
Creating a production order plans a quantity and a due date, works out the materials and the planned cost, and stops there. Launching is a separate, deliberate act with a real consequence: the materials of that order are reserved on the warehouse, which means nobody else can spend them while the job is in progress. Reservation is the step that turns a plan into a commitment, and it is why the order has a status at all rather than being a line of text. If a firm skipped it, two jobs could promise the same kilogram of material and both would be wrong.
Recording output is where the warehouse finally moves. The materials are released from the reserve and written off into production at their average purchase cost, and the finished product is put onto the warehouse balance at its real production cost, not at zero and not at a hopeful sale price. Labour comes in from the actual time recorded against the operations, and overhead is applied as a percentage of that labour. The unit cost is the full cost of the batch divided by the quantity produced, and scrap carries its share rather than being quietly forgotten — which is why a batch that went badly does not look cheap. When that product is sold later, its margin is calculated against a cost that came from the workshop instead of from someone's optimism.
The assistant's behaviour around all of this is the interesting part, because it is built to finish rather than to chat. When it is asked to make a quantity of something and put it on the warehouse, it treats that as one job: check for a specification and create one if it is genuinely missing, create the production order, launch it so the materials are reserved, and record the output. It is explicitly told not to stop at the order, not to stop at the launch, and not to ask whether it should now proceed — the request to proceed has already been made. This matters more than it sounds, because the most common failure of a helpful assistant is a chain of small confirmations that leaves the work in a state nobody asked for.
The same code is equally explicit about the moment it must refuse. Before anything is reserved, the materials of the order are checked against the warehouse with what has already been reserved for that order taken into account. If anything is short, the order is not launched, the stock does not move, and the answer names each missing material with both numbers: what the recipe needs and what is actually there. Nothing is half-executed and nothing is approximated. You get a shopping list instead of a broken production order, and that list is built from the same warehouse figures the rest of the CRM uses.
Shortage is a detour, not a dead end. The missing lines can be turned into a purchase order for a supplier, and once the goods are received the stock balance changes, which changes the answer to the same question. Run the production again and it either completes or reports a smaller gap, and this loop can be repeated as often as needed without any cleanup in between, because a failed attempt never wrote anything. That property is worth more than it looks: an assistant that leaves no debris when it cannot finish is an assistant you can point at real work on a Monday morning.
Two smaller decisions keep the numbers honest. Materials may be written off only from items that are genuinely stock items of the goods type, so a service cannot be consumed by a workshop that never had it — the system refuses and says which card to check. And every one of these actions still asks for confirmation unless a robot has been set up to act on its own, so the autonomous-sounding full cycle is autonomous in the sense that it does not interrogate you five times, not in the sense that it bypasses the owner. The assistant plans, reserves, posts and computes; the decision to make the thing remains a human one, which is the correct division for anything that consumes real material.
The reason this belongs in a discussion about AI in business processes is that production is where a soft answer is most expensive. A chat assistant that is vague about a customer's question wastes a minute. A system that is vague about whether a job can start wastes material, ties up a machine and breaks a delivery date. The design response here is not a smarter paragraph of text but a smaller number of possibilities: a specification that has to exist, a reservation that has to happen, a check that either passes or returns the exact shortfall, and a cost that has to be assembled from real movements. The intelligence is welcome, and the discipline is what makes it usable.