Human control in AI-assisted production scheduling

Separate a candidate suggestion from the adopted plan

One calculation can produce several sequences, resource choices, and expected completion dates. They begin as candidates for comparing due-date risk, resource conflicts, material dependencies, and schedule movement. A generated result has not yet been adopted by the factory or released to shop-floor execution.

SAP PP/DS lets users save simulation results without changing the current planning version, while Siemens describes what-if simulation and impact analysis in its scheduling product. These are vendor-specific controls that demonstrate separation between a candidate and the current plan. They do not define one approval status shared by every APS product.

Kavop currently produces comparable schedule options for planner adjustment and confirmation. A first round can read company-provided ERP exports, spreadsheets, SQL data, the current schedule, and operating rules. The first round stays read-only, with candidates kept outside production systems for review. They do not automatically write back to ERP or MES or become customer commitments or production releases.

Give the planner the reason behind this version

A review first fixes the data cutoff, time zone, order scope, current schedule, candidate version, and rule version. When orders, routings, resource calendars, materials, and shop-floor progress come from different times, the planner cannot tell whether a difference came from the scheduling method or from a stale input.

An order-level view should include the required milestone, candidate completion date, relevant operations and resources, critical materials or dependencies, moved work, unresolved constraints, and limits outside the current model. Oracle scheduling products can expose late orders, resources, pegging, and manual adjustments. The actual fields still depend on the customer system and represented scope.

An explanation helps a planner trace the evidence, but it does not establish that the result is correct. The voluntary NIST AI Risk Management Framework recommends documenting how outputs are used, knowledge limits, and human oversight. The team still needs to reconcile the candidate with real orders, master data, and operating rules.

Recheck related impact after a manual adjustment

A planner may accept, reject, request more data, or change a priority, date, resource, or operating rule. Each change should retain the old value, new value, editor, time, and reason so the next reviewer can understand why the version moved.

In Oracle Production Scheduling, a user can move operations on the Gantt chart, select an alternate resource, and run Repair. A new Solve recalculates the schedule and can discard existing manual operation adjustments. That behavior shows why dragging and saving one operation records an edit but does not establish that the complete set of dependencies remains feasible.

Microsoft documentation also separates planned-order edits, the optional Approved status, and a later master-planning run. Recalculation behavior varies by product, so a public control process should still require another review of related operations, resources, materials, and affected orders after an edit.

Send an exception to someone with the authority to decide

A rush order, protected-horizon move, overtime decision, alternate resource, split, subcontracting option, or critical-material substitution can carry consequences beyond the planning scope. Planning can assemble the affected orders and comparable options, while a designated owner decides whether to accept the cost, quality, customer, or operating risk.

An exception record should identify the trigger, affected orders, baseline, candidate change, unresolved risk, required decision, and deadline. The customer date communicated by sales, the protected work that operations will allow to move, and the objects a system may update can belong to different owners.

The NIST AI RMF recommends distinguishing human-AI configurations, oversight roles, overrides, and escalation responsibility. It is a voluntary risk-management reference. It does not require a PMC team, sales lead, plant manager, or any fixed occupation to approve every manufacturing schedule.

Do not hide four decisions behind one confirm button

Selecting a schedule candidate, approving an operating exception, making a customer commitment, and publishing to execution answer four different questions. A manufacturer can assign authority according to its organization, but the record should identify who decided, within which scope, and against which version of the evidence.

Microsoft Approved is an optional manual status for a planned order before firming. It means the planned order is approved for firming. It remains a planned order and has not thereby created an actual purchase, transfer, or production order. The term cannot stand in for another vendor's review status.

Microsoft also supports manual, automatic, and query-based firming. Auto-firming requires an explicitly configured time fence, while query-based bulk processing can be previewed. These controls show that calculation, a manual status, and order conversion can be governed separately. They do not establish one mandatory approval design for every manufacturer.

Select a schedule version

Minimum evidence includes baseline and candidate differences, due-date risk, hard constraints, and unresolved exceptions. The responsibility record names the person the company authorizes to select a version, the selected version, decision time, and reason for accepting or rejecting it. The system must not make the highest-scoring candidate the formal plan automatically.

Approve an operating exception

Minimum evidence includes protected-horizon work and the effect of overtime, changeovers, alternate resources, split batches, and subcontracting on orders and operations. The responsibility record names the person the company authorizes to approve the exception, its scope and conditions, the decision time, and the reason. Without an explicitly approved exception, the system must not automatically move protected-horizon work or alter work already in progress.

Confirm a customer date

Minimum evidence includes the shipment or arrival milestone, quantity, proposed date, affected customers, and residual risk. The responsibility record names the person the company authorizes to make the customer commitment, the approved version, decision time, and scope allowed for external use. The system must not turn a model date directly into a customer promise.

Publish to an execution system

Minimum evidence includes the target system, order scope, fields, operating permissions, rollback method, and notification recipients. The responsibility record names the release operator and approver designated by the company, the run ID, execution time, and result. The system must not write back to ERP or MES in bulk without an explicit scope.

Retain the version and the evidence behind each decision

A complete record connects the input snapshot, current schedule, candidate, order-level delta, manual changes, exception decisions, and final result. A new result should not overwrite the prior version, and failed, skipped, conflicted, or rolled-back release actions should remain attached to the same run.

The NIST AI RMF Playbook lists histories, audit logs, human overrides, errors, exception escalation, and go or no-go decisions as suggested actions. The organization still determines the fields, retention period, and access rights for its risks, systems, and regulatory setting. The list is not a universal manufacturing compliance rule.

A log shows who did something and when. It does not prove that inputs were complete, constraints were correct, or a candidate was executable. Any public case result or performance figure also needs its own baseline, calculation method, and customer permission.

Define the object, fields, and consequences before release

The first use of release should say whether it means a file export, manual handoff, plan-version adoption, actual-order creation, status change, or ERP or MES field update. Previewing the selected orders, target system, fields, permissions, and rollback method makes the consequence of an action reviewable.

Vendor actions are not equivalent. Microsoft firming converts a planned order into an actual purchase, transfer, or production order. SAP adoption merges simulation changes into a planning version and does not itself mean shop-floor release. Oracle Production Scheduling Release can update documented work-order and operation dates, resource assignments, and configuration-dependent statuses, while some scheduling overrides do not write back.

Kavop currently supports export, while controlled release remains limited in scope. It does not replace an ERP or MES. Public evidence does not yet establish a specific interface, approval workflow, electronic signature, write-back field set, or failure behavior. The first round therefore stays read-only, with a planner or authorized person confirming the result before any later handoff or release design is agreed.

Bring execution feedback into the next review

After a formal plan enters execution, actual start and completion, quantities, time, material consumption, downtime, shortages, and quality events can change the original conclusion. Microsoft production-feedback documentation describes records for time, materials, quantities, statuses, and errors. Those facts need a timestamp and source when they enter the next planning cycle.

Oracle Refresh updates work orders, attributes, capacity, and availability data from Manufacturing and discards the current scheduling solution. Refresh, solve, and human review remain separate actions. The team needs to establish what the new data covers before keeping the current plan, repairing part of it, or generating another candidate.

Feedback can improve the inputs used in later reviews. It does not prove that a system automatically trains, rewrites operating rules, or continuously improves. Kavop's current boundary remains the generation of candidates from existing data, risk explanation, and planner confirmation. How shop-floor data enters, how often it refreshes, and who can initiate rescheduling are project-specific decisions.