Production tracker architecture: the decisions that matter

Situation: Changing a BOM under a running order makes traceability and cost wrong and fails audits.

Choice: Edits create a new draft version under engineering change control; release makes it immutable with an effective date; work orders store the version they started with.

• Rejected: Editable BOM with history log: can be bypassed and confuses open orders.
• Rejected: Copy BOM per order: heavy and loses the engineering lineage.
• Consequence: Where-used and version comparison screens are required.
• Consequence: Emergency changes still go through an expedited review, not an edit.

Situation: Recall tracing must work in hours and must survive later edits to orders.

Choice: Record every consumption as an edge (input lot, output lot, quantity, order) in the same transaction as the report; trace by bounded recursive queries over indexed edges.

• Rejected: Derive genealogy from order BOMs: wrong when substitutes or rework occur.
• Rejected: Graph database: another platform to run for a query Postgres handles.
• Consequence: Operators must scan or select input lots when material is lot-tracked.
• Consequence: Edge table grows with production and is partitioned.

Situation: Writing to machines creates safety and liability exposure that a cloud app cannot carry.

Choice: Gateways push signed batches; the service stores and analyses them and never issues commands.

• Rejected: Bidirectional control: out of scope and a safety risk.
• Rejected: Operators type every count: low data quality.
• Consequence: Real-time control stays in PLCs and local systems.
• Consequence: Latency of insight is bounded by gateway batching.

Situation: Plant Wi-Fi drops; operators resubmit; double counting corrupts yield and inventory.

Choice: Tablets queue reports locally with client report ids; the server inserts exactly once per (operation, client id).

• Rejected: Online only: blocks production on network faults.
• Rejected: Server-generated ids only: duplicates on retry.
• Consequence: Clients must persist ids across restarts.
• Consequence: Out-of-order replays need server-side ordering by reported_at.

Indexes are chosen from the questions the app asks most often. Each line below names a table and the question its main index answers.

• sites: unique (org_id, name) — site names unique within a tenant.
• work_centers: unique (site_id, code) — one code per work center in a site.
• items: unique (org_id, sku) — SKU unique per tenant.
• boms: unique (parent_item_id, version) — one row per BOM version.
• bom_lines: (bom_id, position) — ordered lines of a BOM.
• routing_operations: unique (routing_id, seq) — operation order is unique within a routing.
• work_orders: unique (org_id, number) — work order numbers unique per tenant.
• work_order_operations: unique (work_order_id, seq) — one row per operation.

Forge64 matches your description to one of 25 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.

This is a reference design for the category, not a promise that every item is generated today. Built-ins such as background jobs, file uploads and search are rolling out; email sent from your app is coming soon, so anything here that needs it is something you add yourself for now.

What is the most important architecture decision for a production tracker?

Released BOMs and routings are immutable versions; work orders freeze their version. Edits create a new draft version under engineering change control; release makes it immutable with an effective date; work orders store the version they started with.

Do I have to make these decisions myself?

No. Forge AI plans them from your description and writes the decisions into the project as architecture records you can read and change.

What do the alternatives cost me?

For example, for "Genealogy as insert-only edges between lots": Derive genealogy from order BOMs: wrong when substitutes or rework occur. Graph database: another platform to run for a query Postgres handles.

• How to build a production tracker
• Example prompt for a production tracker
• Production tracker security checklist
• Production tracker scaling checklist
• Often combined: inventory system
• Often combined: approval workflow app
• All app types