Car planning, CWA and monotonicity

The production policy of a car manufacturer is that a particular car starts being built as soon as it is ordered (if it could not be sold from the available stock). Default rules determine how the manufacturing capacity is to be used, beyond that specific case (that is, what cars have to be built for stock): these rules decide, in particular, what is the color mix needed to replenish the stock (which is an important factor, as it severely affects car sequencing). The rules are updated from time to time, based on market and stock data, and published by the marketing dept towards the production units. At production unit U, the production plan is prepared once a day, then production is scheduled accordingly. Prior to start sequencing, the scheduler fills in the specifications for the cars to be produced, from the order list and the rules.

One morning at unit U, the rules might look like this:

for all cars x to be produced that day, ordered(x) -> (orderColor(x, y) -> makeColor(x,y))
for all cars x to be procuded that day, ~ordered(x) -> makeColor(x,black)

and U's order list contains:
ordered(001), ... ordered(006)
orderColor(001,green), ... orderColor(006, blue)

Initially, like every morning, the specification list only contains (U's daily production capacity is 100): car(001),...car(100)

So, the scheduler initialises the specs, and then starts sequencing 6 colored cars and 94 black ones, when the order list is updated by the sales dept, adding:
ordered(007), orderColor(007,yellow)..

If the scheduler is capable of non-monotonic reasoning, it will be able to repair the sequence to replace the production of one of the black cars by the production of a yellow one. If not, it will just ignore the update, and deal with it the day after (units have different schedulers and thus different ways to deal with that issue).

Every night, the cars produced in the day are compared to the specifications in the ordered list, and delivered if they fit one order or stocked if they do not (or thrown away if they do not fit the spec of any car in the prod list either) and the order list is reinitialised for the next day (in the case where car001 to 006 have be produced according to orders, the list is reinitialised to: ordered(001), orderColor(001, yellow) etc; dependeing on the orders received that day).

Discussion:
The negation in ~ordered(x) in the second rule is a NAF, scoped to U's order list of the day. Suppose any unit can access the order lists for all the order units as well, the scope of the NAF must be made explicit when publishing the rule, lest a naive unit looks everywhere it can for ordered cars, including in other units order lists.
The whole system is nonmonotonic, since orders can be added to the list at any time. The retrieving application needs or need not care about that nonmonotonicity, depending whether it schedules monotonically, based on a snapshot of the order list once a day, or  whether it is able to reschedule dyanmically, repairing the current schedule when it is falsified by a new entry in the order list.