Manufacturing planning development preview

Work brought from the former 0.67 branch into the planned 0.71.0 release includes manufacturing input validation, material reservation, routing, native execution and component result validation. The complete browser planner is still under development. The selected enterprise record service now previews retained JSON and CSV inputs through native authorization and its fixed API facade. The browser can preview and retain an exact input selection, explicitly calculate and save a scenario, reopen its verified summary, saved result tables and Calendar/Gantt, and compare it with another saved scenario, revise its inputs, and submit or decide an independent review of the exact retained result, and download its approved JSON/CSV package. Administrators can preview and clean up abandoned saves. Backup/restore and complete live acceptance remain unfinished; no published planner capability is claimed.

The intended workflow is to import a versioned snapshot, compare production scenarios, inspect shortages and delays, and obtain independent review of an exact plan. The enterprise model access guide describes the shared access, record and review controls. The current code reuses Grid's existing material requirements planning (MRP) and finite scheduling contracts.

Snapshot example

The canonical source example is examples/manufacturing/minimal-snapshot.json. It describes two finished units, a bill of materials requiring 1.50 kg of raw material per finished unit, 3.00 kg on hand, a separate confirmed receipt, and a 30-minute production operation. That duration applies to one production lot, not to each unit. A receipt is identified separately from stock and retains its availability minute.

Snapshots pin exact item, bill-of-materials and routing revisions. Quantities are decimal strings with each item's declared precision, from zero to six fractional digits. Values are not rounded into that precision. Operations use integer minutes relative to an absolute origin and name a display timezone. Each machine has an explicit calendar; an empty calendar means an outage.

The prepared JSON preview rejects unknown or duplicate fields, stale references, cyclic dependencies, invalid calendars, unsupported quantities and unrecognized timezones. Its report separates the digest of the exact imported bytes from the digest of the canonical snapshot. Selection must match both reviewed identities. A fixed-table CSV preview uses the same snapshot admission and report-selection contract. The protected preview interface returns the report; a separate explicit selection command retains the exact accepted snapshot. Neither operation solves or approves a plan.

Protected import preview

The selected enterprise record service accepts manufacturingImportPreview at POST /api/enterprise/models/records. The normal envelope supplies the current security revision, model identity and source digest. Each input source names table, recId, version and artifactId within that model. A JSON input has format: "json" and one source; a CSV input has format: "csv", a manifest source and thirteen tables, each containing its fixed name and source. The native response echoes these exact sources with the import report.

Use the existing upload and record-attachment commands to retain each file before previewing it. A staged upload alone cannot be imported. Files may come from different records or historical revisions; this preserves the existing eight-attachment limit per revision. The whole import is limited to 16 MiB, checked from retained references before payload reads. Native storage verifies current committed metadata, sensitivity, content size and hash. No caller-supplied path, URL, role, report or snapshot identity is trusted as input authority.

Preview requires current View and Edit permission on a general model. Care Operations models cannot use this manufacturing route. The native service binds the request to the current model source, records signed audit intent/completion, and rechecks authority before publishing the report. The response contains validation results and counts, not downloadable source files. Ordinary attachment downloads retain their separate Export and destination controls.

An accepted report means these bytes satisfy the input contract. It is not an approved plan, an independent review, a solve, or a durable scenario selection. Historical bytes remain reconstructible after detachment and restart. The full scenario workflow remains under development.

Selecting inputs in the browser

Open a general model, choose Records, then Manufacturing inputs. Upload and attach each source file to a record with a reason. Only committed attachments can be selected; an unfinished upload does not appear as an input. Open the required record version and choose Use for manufacturing beside each file. The input panel can be collapsed while gathering files across tables and records.

Choose JSON snapshot and a single snapshot file, or CSV tables and manifest and assign one manifest plus all thirteen table names. Matching filenames are assigned automatically; assignments can be changed explicitly. Duplicate roles, missing tables and imports above 16 MiB cannot be previewed. The basket holds at most fourteen distinct retained files. Removing a basket entry does not detach or delete its record attachment.

Choose Preview manufacturing inputs to have the native service validate the exact retained versions. The screen shows counts, the planning horizon and time zone, or the field and location needing correction. An accepted preview enables Retain snapshot selection after you enter a reason. Changing the selected input invalidates the displayed preview. Saving uses both identities returned by the native preview and does not calculate or approve a plan.

If the save response is uncertain, the screen freezes the request and offers Retry same snapshot selection. It does not automatically submit another command. Retry before leaving the model: the browser keeps the pending request only in this view, without browser storage or background recovery. Native committed selections survive restart independently of that browser state.

Keep the selection reference shown after a confirmed save. Open a saved selection retrieves its retained identity and input versions under current View permission, including after returning to the model. A selection from older model source is labeled historical. Preview and new selection require Edit; ordinary file downloads retain their separate Export and destination controls.

Retaining a previewed snapshot

After preview, manufacturingImportSelect accepts the same input and a selection containing commandId, reason, inputSha256 and snapshotSha256. Both hashes must match the accepted preview of the currently verified retained files. Current View/Edit permission, source binding and signed audit govern selection. A changed input or model source requires a new command identity.

The native owner retains the canonical snapshot, original report and selection manifest as immutable model-local artifacts. The manifest binds the actor, reason, exact input references and model source. One atomic commit makes all three visible together. If an attempt stops before commit, its staged contents remain hidden; an explicit exact retry can complete it after restart. If commit already succeeded, the same request returns the existing selection. Reusing that command ID with a changed reason, input or source is refused.

The returned selectionId identifies the retained selection. Use manufacturingSelection with that ID to inspect it under current View permission. The native owner verifies the retained manifest and both contents before returning identities. The stored source can be historical; it is not silently rebound to the currently edited model. A lower current sensitivity cannot disclose a more sensitive retained selection. This is selection metadata, not a snapshot download.

A selected snapshot is not a solved scenario or an approved plan. The canonical snapshot is bounded to 16 MiB; reports and selection manifests to 12 KiB each. The selected namespace allows 1,024 artifact records and 256 MiB of managed content per model. Exact retries retain the original immutable records; failed staging is retained for retry and counts toward those limits until explicit abandoned-work cleanup. Broader retention and backup administration remain unfinished. There is no automatic cleanup or promotion of incomplete attempts.

Calculate and reopen a scenario

After retaining or opening a snapshot selection, use Calculate a scenario in the same manufacturing panel. Both View and Run permission are required. A historical selection can still be inspected but cannot be calculated against a newer model source. Retain a selection for that source first.

Enter a reason and choose Calculate and save scenario. The optional Calculation limits section controls bounded material work and scheduling search. The defaults are 100,000 material steps and 1,000 search nodes. Material work must be between 1 and 1,000,000; search nodes may be between 0 and 100,000. Zero search nodes permits the initial scheduling attempt without further search. A work limit can leave the result incomplete; it does not prove infeasibility.

The native response supplies the saved scenario reference, outcome, material coverage, scheduling status, author, source revision and exact retained evidence. The summary distinguishes feasible, partial-coverage, fixed-allocation infeasible and budget-exhausted results. Optimality and infeasibility apply to the declared problem and allocation. None of these statuses constitutes independent approval. Expand Calculation identity and retained evidence for the input selection, engine identity, settings and result-part hashes.

If a response is lost, inputs remain frozen and Retry same scenario calculation reuses the exact command. There is no automatic retry. Stop waiting cancels the browser wait but does not undo a saved result. Retry before leaving this model; the pending request is held only in the current view and is cleared when the model/session changes. Keep the confirmed scenario reference and use Open a saved scenario to inspect it later with current View access. Historical results show their original source revision and a visible historical label.

Inspect saved results

Choose Orders, Material requirements, Shortages, Reserved supply, Operations, Machine utilization or Waiting constraints below the saved scenario summary. Each explicit read requires current View permission and verifies the original saved result graph. Use Previous result rows and Next result rows to page through larger results. Pages contain at most eight rows and 12 KiB of detail data. Opening the summary does not automatically read every table.

Orders show material coverage, release/due times and available completion and lateness. A work-limited order is Not processed; an absent completion is Not available, not zero or proof of infeasibility. Material requirements separate gross demand, external supply and proposed production. Shortage amounts are suggested purchases, not receipts. Reserved supply preserves the exact stock, confirmed-receipt or hypothetical-receipt reference and its availability time. Operations show retained machine assignments and processing/setup times; an unassigned operation has no invented start or completion.

Quantities retain exact decimal strings and their units. Times are minute offsets from the displayed snapshot start; durations and lateness are minutes. The snapshot time zone is shown as context. Wide tables scroll horizontally, including on phones. Leaving the model or changing sessions clears the displayed details. Historical scenarios keep their original source identity.

Machine utilization measures the checked scheduled subset over each machine's open calendar within the snapshot horizon. Processing and setup both consume capacity: a 30-minute operation demanding two capacity units uses 60 capacity-minutes. Utilization divides used capacity-minutes by available capacity-minutes and rounds to 0.01%. A machine with no available capacity has no percentage. A plan without checked assignments has unavailable usage; a checked stock-only result can have zero usage. Missing or unprocessed demand is not a forecast of future utilization.

Waiting constraints shows order release, allocated external-material availability, producer completion and predecessor completion. Combined readiness is their latest bound. Producer edges also appear among predecessors, so these bounds overlap and must not be added. Flow and predecessor counts distinguish an absent constraint from a real zero-minute bound.

Between combined readiness and the start of machine occupancy (setup first, if required), the view counts closed-calendar minutes first, then open minutes where the saved assignments leave insufficient capacity for this operation. Remaining time is Other delay: it can include a window too short for uninterrupted work, setup sequencing or solver choices. The calculation holds other assignments fixed. It neither identifies a unique cause nor proves that a better schedule is impossible. No assignment means no waiting-duration estimate. Expand the calculation notes above each table for these definitions; scroll across a wide table for its remaining bounds and counts.

Read the saved Calendar/Gantt

Choose Operations in a saved scenario's Planning results. Its protected page also opens the saved schedule. Gantt displays native minute offsets; Calendar timeline displays dates in the snapshot's saved time zone. Switching presentation or range uses the loaded page and performs no additional read or calculation. This presentation reuses the existing Calendar/Planning renderer.

Fit this page spans the loaded assignments, including setup. Full horizon shows zero through the snapshot horizon. Solid bars show processing; striped bars show setup. Operations that overlap on the same machine occupy separate rows so neither is hidden. A row represents an operation, not a capacity slot. Bars retain their proportional duration; exact values remain in the operation table. On narrow screens, scroll within the chart; operation labels stay visible.

The chart labels which operations are loaded, with at most eight per protected page. Use Previous result rows and Next result rows to inspect others. Empty space in a chart is not evidence that a machine is available: other pages and the machine's open/closed calendar windows are not drawn. The utilization and waiting views provide the retained capacity and calendar-delay figures. Unassigned operations get no invented bars or dates. A no-production result means no operations were scheduled for the covered subset; it does not establish that all requested demand was covered.

Calendar dates add the native elapsed minutes to the saved Unix-minute origin, then format that instant in the saved time zone. UTC offsets distinguish repeated local times at the end of daylight saving. Expand Calendar dates for loaded operations for exact setup, processing and end dates. The browser's local time zone never replaces the saved one. If the browser cannot format that zone or date range, Calendar timeline is unavailable with an explanation; Gantt and the original minute-offset table remain available. Display formatting is not a new scheduling path and does not edit or approve the saved scenario.

Compare saved scenarios

Open the saved scenario you want to inspect, then enter another saved scenario's reference from the same model under Compare with a baseline. Choose one of the seven result views and select Compare with baseline. Current View permission is sufficient; comparison does not run either calculation again. Changing the view requires another explicit comparison. Previous comparison pairs and Next comparison pairs follow the actual returned page boundaries.

Each comparison verifies both complete saved result graphs and their original input selections. Historical scenarios retain their original source, input, engine, settings and time base. Expand Scenario identities and assumptions to inspect these details. A changed source revision is visible even when the source text is identical. The enclosing model/session authorization remains current. Access changes or unavailable/corrupt saved evidence refuse the read.

Rows are paired by structured authored identities, so inserting an unrelated item does not turn a changed generated operation ID into an added/removed job:

View	Identity used to pair rows
Orders	Order
Machine utilization	Machine
Material requirements and Shortages	Order and item
Reserved supply	Order, item, supply kind and supply reference
Operations and Waiting constraints	Order, item and operation

The native response contains at most four pairs and 12 KiB per page. Added and removed rows remain visible. Not present means that side has no matching row; Not available means a retained row lacks that result. Highlighted fields show differing reported values. These labels do not normalize units or dates, rank plans or approve a result. Quantities retain their original units; time values are minutes relative to each snapshot's origin. Read the displayed origin, time zone and horizon before interpreting offsets, particularly when the time-base notice appears. Identical offsets under different origins do not establish identical dates. Waiting bounds overlap and must not be summed; delay explanations still hold the saved assignments fixed.

Comparison reads are explicit, cancellable and held in memory. Stop comparing discards a pending result; session/model/scenario changes clear the comparison. There is no automatic retry or browser persistence. To compare changed inputs, retain a new JSON/CSV import or revise a saved selection and calculate another scenario.

Revise a saved input selection

Open a saved selection, then use Inspect and revise saved inputs. Item references, Demand, Inventory, Receipts and Machines read at most eight rows at a time. Read calendar shows one machine's open windows; use the previous/next controls for more rows. Wide tables scroll horizontally. These are the original saved inputs, not a merged view of your draft.

With Edit permission, choose Edit or Remove … in draft on a demand, stock or receipt row, or add a new entry. Existing entry IDs stay fixed while editing. Item IDs/revisions, quantities, priorities and minute offsets are explicit fields. Quantities remain decimal text in the item's declared unit; Item references shows each unit and precision. Times are whole minutes from the displayed snapshot origin in its saved time zone. Hypothetical receipts remain assumptions, not confirmed supply.

From Machines, Add outage subtracts a half-open interval from existing availability. Replace calendar replaces every window for that machine, including windows outside the displayed page. Add all intervals to retain; leaving the replacement empty makes the machine unavailable. A revision supports up to 64 distinct targets and 128 replacement windows, within the native request and retained-descriptor byte limits. Another edit to the same entry or machine replaces that draft change.

Choose Add to revision draft, inspect the listed changes, and then Preview revised inputs. Native admission verifies the exact base selection and ancestry, applies the edits and checks references, units, quantities and calendars. A rejection remains visible for correction. Changing the draft invalidates its preview. Enter a reason and choose Retain revised snapshot only after a successful preview. The original selection remains unchanged; the new selection retains its parent, exact edit request and canonical snapshot/report. It becomes the selected input for Calculate and save scenario. Saving alone does not calculate or approve a plan.

If a save cannot be confirmed, use Retry same input revision to recover the identical command; conflicting controls remain frozen. Keep the displayed change reference before leaving. Drafts and pending requests live only in the current view and are cleared when its model, session, selection or permission scope changes. There is no automatic retry or browser storage. Retained revision lineage identifies the original selection and snapshot digest after reopening.

Review a saved scenario

Open a retained scenario, inspect its result tables, and choose Open scenario review. The history loads only on this explicit navigation. An unsubmitted scenario shows Saved scenario — not submitted. Enter a reason and choose Submit scenario for review. An independent human reviewer can then enter a reason and choose Approve saved scenario or Reject saved scenario. A reviewer needs current View and Approve permissions; Edit is required to submit, not to review. An optional explicit delegation reference is checked natively. Current-role eligibility hints do not establish independence or grant authority.

Review covers the exact saved calculation, retained input versions, full input ancestry and model source. Native provenance includes input uploaders, prior record writers, selectors/revisers, scenario authors and eligible submission role origins. Those contributors cannot independently approve their own work, directly or through delegated authority. Native policy and current identity decide every command. History shows the submitted and decided reasons, actors, native times, delegation and role origins. Expand Review identity and contributors to inspect the exact retained review reference, subject, input selection and policy identity.

An approval is labeled Approved saved scenario. Changing the model source or selecting a different input snapshot displays a historical warning and removes further decision controls. Approval does not transfer to revised inputs or a new calculation, and it does not release work to machines. Reopening a saved scenario without selecting current inputs inspects that scenario only; it does not establish that all operational records are current. Current policy is rechecked on each save.

If a change cannot be confirmed, the browser freezes conflicting scenario/input controls and retains the unchanged request in this view. Retry same scenario review change recovers its original outcome when current authority permits it. There is no automatic retry. Alternatively, Reload scenario review inspects current history; successful inspection retires the pending request. A failed inspection keeps it. A confirmed save whose history cannot be loaded is reported separately from an uncertain save. Leaving the view clears its in-memory request and does not undo a durable decision. Use the saved scenario reference to reopen and inspect its history after returning.

History is paged and displayed only after complete hash and identity verification. Changed page bindings, cancellation, malformed data or access failure hide the partial result. Retained history remains readable when new manufacturing reviews are disabled, subject to current access and archive health. The controls reuse record review's history and decision fields; they introduce no browser authority, workflow reducer, persistent credentials or background polling.

Backup/restore, live CSV planning acceptance and the complete live-provider/browser/native/restart planning journey remain unfinished. A connected local native check now covers CSV manifest/table upload, exact retained input revisions, calculation, independent review, both report formats and reopening after restart. It verifies all fourteen source files even after their current attachments are removed. The input author and separate submitter cannot approve; an independent third person approves the saved result. Browser readers consume the resulting native history and package bytes. Provider/archive setup and engine identity remain synthetic; these checks do not establish full live acceptance.

Download a reviewed plan (development preview)

The native owner can now prepare a ZIP package for one exact approved scenario, using JSON or CSV for its seven complete result tables. The protected service now supports export commands, retained receipts and verified download pages. The browser connects these operations from the saved scenario review. This remains a development preview, not a published planner capability. Unsubmitted or rejected scenarios, a different approval reference or subject, corrupt original inputs and insufficient sensitivity refuse preparation.

The package contains manifest.json, review.json, execution.json, the exact canonical snapshot.json, and orders, requirements, shortages, reservations, operations, resources and waiting tables. The manifest identifies the scenario, review/subject, source, engine, solver settings, result-part digests, saved clock, requesting actor/reason and every data file's size/hash/row count. It declares approval of the exact saved scenario only. The compiled model is identified by its retained artifact and digest; executable model bytes are not included. This package is a report, not execution authority or an independently signed offline certificate.

JSON retains native result rows and decimal quantity strings. CSV uses UTF-8, CRLF records and quoted text with doubled quotes. A formula-like or apostrophe-leading text value receives one extra leading apostrophe; removing one leading apostrophe from exported text recovers the original value. The manifest declares this reversible escape. Missing results remain JSON null or empty CSV fields, never inferred zeros. Complete report tables are exported; browser pagination does not truncate them. Output is bounded to 16 MiB per data file, 32 KiB for the manifest and 128 MiB for the package; exceeding capacity refuses the whole preparation. No partial package is published.

The native owner now retains the exact ZIP and a compact receipt in one atomic commit, linking the scenario and approval as shared history. An exact retry by the same actor and command ID recovers the original package after restart; changing that command refuses. A higher current classification does not rewrite the original package, and a lower classification cannot read it. Interrupted writes remain hidden until the receipt and package commit together. Staged bytes still consume quota. The native owner now supports a cleanup preview and guarded commit for abandoned staging. A changed artifact inventory invalidates the preview; committed selections, scenarios, approvals, exports and their shared history remain retained. The protected records API now requires a current human security administrator with both View and Edit access to preview or commit cleanup. A commit names the exact preview digest and a nonempty reason of at most 1,024 UTF-8 bytes without control characters. Signed audit binds that request and the native summary. Changed inventory refuses the commit; an uncertain outcome requires a fresh preview, not an automatic retry. The Your models → Open model → Records → Manufacturing inputs workspace shows Clean up abandoned work to security administrators with model Edit access. Native authority is checked again for each request. Choose Preview abandoned work, review the artifact/file counts and recoverable bytes, then enter a reason and choose Confirm cleanup of abandoned work. Cancel closes the preview without requesting deletion. Saved plans and their shared history remain retained; record uploads have their own cleanup controls.

While a cleanup preview is open or its request is running, other manufacturing changes in that workspace are disabled. There is no request on mount or automatic cleanup. Stopping a commit only stops waiting; deletion may already have happened. Any uncertain response clears the old preview and requires a fresh one before another commit. Changing model, source, session revision or availability discards that view and suppresses late responses. Nothing is kept in browser storage. Backup/restore coverage remains unfinished.

Export packages share the private manufacturing store's 256 MiB physical quota and 1,024-record limit. Only selected export access admits a 128 MiB package; ordinary snapshot/result access keeps its 16 MiB limit. Native reads return at most 8 KiB and verify fresh disk bytes, retaining only a bounded cache of page hashes. The protected API requires current View and Export permission for creation, receipt inspection and every download page. It also requires an explicitly registered destination browser-download:<configured browser origin>, channel download, purpose manufacturing-planning, identified mode and a classification ceiling covering the current model. An attachment-download registration alone does not authorize manufacturing exports. Historical approval does not grant current download permission.

The service signs intent bound to the exact request, destination/purpose and export receipt before storage or page retrieval, then records terminal completion before returning a guarded response. Revocation invalidates prepared responses and future requests, including warmed download pages and exact command retries. Restart requires fresh identity-provider validation and archive health before access. Retained exports stay historical when the model source changes: the response identifies the current source separately from the package's original approved source. Export does not require Edit or a new approval of an unchanged saved plan.

The existing model-record endpoint accepts manufacturingExportCommand with a command ID, reason, saved scenario ID, approved review ID, subject digest and json or csv format. manufacturingExport retrieves its compact receipt by export ID; manufacturingExportPage retrieves at most 8 KiB by export ID and byte offset. Every request also binds current security revision and model source. These operations use the fixed protected facade, never ordinary artifact access. In Review saved scenario, an approved scenario offers Download reviewed plan. Choose JSON or CSV, enter a reason, then select Prepare reviewed export. The browser verifies every page against the retained receipt, checks the complete ZIP hash, and rechecks current access before showing Save verified ZIP. Saving checks access again immediately before handing the file to browser downloads. Keep the export reference to use Reopen a retained export later. A changed source or input selection displays a historical-plan notice; downloading never substitutes the current inputs for the approved saved scenario.

If the command's outcome is unknown, Retry same export request repeats its exact identity and fields. Conflicting review/input controls stay frozen until that uncertainty is resolved or the view is explicitly cleared. If retention is confirmed but transfer fails, Retry retained download retrieves that same package without creating another export. Stop export transfer cancels waiting and discards partial assembly; it cannot undo server retention. Clear export view drops local state without deleting the retained package. Leaving the view also discards pending requests; there is no automatic retry or browser storage.

Only a fully verified package becomes a downloadable file. Invalid, changed, corrupt, cancelled or denied responses produce no partial file. Browser object URLs are created only at Save and revoked shortly afterward or when the view changes. A file already handed to browser downloads cannot be revoked. Local fixture-driven browser checks do not establish the full live-provider journey.

CSV snapshot example

examples/manufacturing/minimal-csv contains the same snapshot as the JSON example. Supply manifest.json and all 13 named tables below. A table with no data still requires its header: an empty machine-calendar.csv explicitly represents unavailable machines, while a missing file is refused. No file name is interpreted as a path or URL by the adapter; its caller supplies the bytes.

The manifest contains only schemaVersion, id, revision and clock, using the JSON snapshot meanings. Table headers must match the following names and order exactly. Child rows refer to the exact parent ID and revision.

File	Columns, in order
items.csv	id,revision,unit,precision,supplyKind,bomId,bomRevision,routingId,routingRevision
boms.csv	id,revision,itemId,itemRevision
bom-components.csv	bomId,bomRevision,id,itemId,itemRevision,quantityPer,consumeAt
routings.csv	id,revision,itemId,itemRevision
operations.csv	routingId,routingRevision,id,durationMinutes,capacityDemand,setupClass
operation-machines.csv	routingId,routingRevision,operationId,machineId
operation-predecessors.csv	routingId,routingRevision,operationId,predecessorId
machines.csv	id,capacity
machine-calendar.csv	machineId,start,end
machine-changeovers.csv	machineId,from,to,durationMinutes
stock.csv	id,itemId,itemRevision,quantity
receipts.csv	id,itemId,itemRevision,quantity,availableMinute,kind
orders.csv	id,itemId,itemRevision,quantity,priority,releaseMinute,dueMinute

Use purchased or manufactured for supplyKind. Purchased rows leave all four BOM/routing reference columns empty; manufactured rows supply both references. An empty setupClass means no class. Every eligible machine and predecessor has its own row; list-valued cells and inferred references are unsupported. Receipt kinds are confirmed and hypothetical. Purchase suggestions are not an importable supply kind.

The format accepts UTF-8 without a byte-order mark, comma separators, LF or CRLF record endings, and double-quoted fields with doubled internal quotes. The parser preserves spaces and embedded newlines; snapshot validation still rejects control characters or outer whitespace in identifiers. Blank records, extra columns, alternate headers and malformed quoting are refused. Integer fields use decimal digits, without leading zeros, signs on unsigned fields, exponents or whitespace. Negative order priorities and clock origins retain their signed meanings. Quantities remain decimal strings and use the item's precision; they never pass through floating-point CSV conversion.

CSV v1 permits at most 16 MiB across the manifest and tables, 100,000 data rows in total, and 512 decoded UTF-8 bytes per field. Existing snapshot limits also apply. Limits are checked during parsing and assembly. Refusals identify a fixed field/table and location without quoting imported values.

The input identity binds the exact manifest and each named table's bytes; reordering supplied files does not change it. Reformatting a file changes that identity. Canonical snapshot identity can remain equal across JSON, CSV, quoting, line endings and input row order when their admitted meaning is equal. The report is a local preparation result; it is not a saved or approved scenario.

Materials and timing

Orders reserve material in priority order, then by due minute and stable order identity. Smaller priority numbers come first. Finished and intermediate stock reduce the production that must be planned. A materially blocked order retains its shortage explanation but reserves no stock, so a smaller later order can still use that stock.

Confirmed and explicitly hypothetical receipts may contribute to a scenario. Every reservation retains its receipt identity and date. Purchase suggestions are separate results and never count as received material. A materially covered order can still be impossible to schedule or finish late.

Routing preparation delays each consuming operation until its allocated receipts are available. Manufactured material cannot reach a consuming operation until every terminal step of its producer has finished. The prepared scheduling problem preserves eligible machines, capacities, outages, precedence and unary machine changeovers. Stock-only orders retain a completion date without adding fictional production operations.

The current scheduling objective remains the existing scheduler's makespan objective. Order due dates are retained for completion and lateness reporting; the adapter does not claim to minimize total order lateness. Any eventual optimality statement must be limited to the declared fixed material allocation and scheduling problem.

Current limits

The native execution API uses Grid's existing Planning calculation engine. It retains the canonical snapshot, allocation, routing projection, executable model, schedule and independent validation report as separate parts bound by a manifest. Settings and the selected native engine identity are also included. A changed input, setting or engine identity changes the run identity. These parts are prepared computation results. An internal native scenario owner now retains them together with the exact input selection, command, actor, source and settings. One atomic commit makes the complete artifact graph visible; a committed command can be recovered after restart without solving again. Interrupted staging remains hidden and an explicit same-command attempt can resume it. Every retained part is checked again when the scenario is inspected.

Protected execution is available through the selected enterprise API at POST /api/enterprise/models/manufacturing/run. The request names the exact selection, an immutable command ID, a reason, and bounded allocation/search settings, alongside the current model, security revision and source digest. Current View and Run permissions are required. The native service supplies the actor and engine identity; caller-supplied identities are refused. It reserves signed audit before work, uses the existing single selected execution slot, and checks cancellation and current authority before committing and publishing. A source replacement invalidates pending work even when source bytes are identical.

Operators must explicitly select manufacturingExecution in trusted startup configuration, with the exact source revision and runtime executable SHA-256. Linux startup hashes the running executable through /proc/self/exe and refuses a mismatch before recovery can append durable records. The source revision is trusted deployment metadata, not an independently verified build attestation. Without that optional configuration, execution is unavailable and no executable hashing occurs. The operator startup instructions describe the deployment inputs.

The response contains the retained scenario and bounded execution manifest. Inspection uses manufacturingScenario with the scenario ID through the existing protected records API and requires current View permission. Historical scenarios retain their original source identity. Exact committed requests return the same checked result without another solve. A lost response may follow a successful commit: retry the unchanged command explicitly. Cancellation does not undo an already committed scenario, and startup never automatically replays a solve.

The browser offers explicit calculation from a saved current-source selection, an unchanged-request retry, saved-scenario lookup, an outcome/identity summary and seven saved result tables, including capacity-weighted utilization and fixed-assignment waiting explanations, comparisons, independent review and reviewed JSON/CSV downloads. Local socket and browser tests use synthetic engine metadata or transport and do not establish a deployed Linux service or a live provider/browser planning journey.

The independent checker verifies material conservation and readiness, producer completion, authored precedence, calendars, capacities and changeovers against the original snapshot. It reports order completion and lateness while retaining shortages and unprocessed orders. Production makespan is separate from the completion date of stock-only orders. A stock-only result has no synthetic compiled model or claimed scheduling optimum. The checker establishes covered feasibility; it does not independently prove a solver optimality claim.

The quantity adapter evaluates BOM products in integer atoms at the declared item precisions, using the shared MRP algorithm for inventory netting and multilevel explosion. For example, a parent quantity of 0.00375 and a component requirement of 8.00 produces exactly 0.03 component units at precision two. It does not multiply by an approximate binary reciprocal and round afterward. Fractional atoms and quantities above the declared capacity are still refused. Independent conservation checks compare every accepted MRP quantity exactly; GRID_MANUFACTURING_MRP_EXACTNESS signals a mismatch, not an allowed tolerance. Ordinary numerical MRP retains its existing calculation contract.

Material allocation has deterministic work and report-size bounds. Routing expansion is limited to 4,096 activities and 32,768 counted relationships; oversized expansion is refused before returning a scheduling problem. Exhausted material work retains the unprocessed order identities and is not a proof of infeasibility. Schedule search has its own declared node budget.

The complete live planning restart journey, live CSV planning acceptance and backup/restore remain unfinished. Local component tests do not establish a complete production planning workflow.