# SYN-FLOW-001 — Production flow and line balancing

**SYNTHETIC DEMONSTRATION.** All demand, production events, work assumptions, variability, staffing, buffers, scrap and results are fictional. This is an independent portfolio demonstration, not an employer/customer operation, safety approval, equipment acceptance or release decision. Version **flow-1.0**.

## Problem, scope and responsibility

Investigate staffing, queues and line balance for the same SYN-OPS-01 factory and SYN-LC-1000 product. Separate batch-machined SYN-VS25 valves from individual kit/assembly/test jobs. The work demonstrates operations research, material accounting, geometry integration, event modeling, statistical comparisons and software design. Existing supplier lots, 90 SPC measurements, 32-cut experiment, 720-batch ML history and FAT unit remain independent evidence populations.

The new orders are fictional, not the three original genealogy records. Purchased components are assumed available and already dispositioned for these orders. Original held supplier stock is never treated as available inventory. A production-complete event is a model flow exit, not actual FAT acceptance, a combined shipment-release gate or a customer result.

## Architecture

- Route: /engineering-lab/production-flow/.
- data/factory/flow.ts: versioned assumptions, six assembly tasks, two routing profiles, settings and input bounds.
- lib/factory/flow/balance.ts: precedence validation, cell work content and bounded exhaustive balancing.
- lib/factory/flow/context.ts: selected layout route geometry and compatible workstation timing; rejects infeasible or incompatible candidate assumptions.
- lib/factory/flow/engine.ts: stable event heap, FIFO resources, batch release, transfer reservations, blocking after service, material/order ledgers, exact event/interval snapshots and time integration.
- lib/factory/flow/experiment.ts: 20-run means, approximate intervals, paired comparisons and binary-search replay state.
- components/factory/FlowWorkbench.tsx and FlowCharts.tsx: controls, results, replay, resource/WIP plots, order Gantt, equivalent tables and exports.
- lib/factory/flow-session.ts: schema-6 tab preferences; schemas 1–5 migrate without losing previous work. Only settings/replay choices are saved, not large result traces; storage failure falls back to memory.

Static Next.js/React/TypeScript implementation with no backend, external simulation service or runtime package dependency. Engine code is loaded for this route; factory overview shows configuration only. Memoized comparisons recompute for settings, demand or context changes, not each replay tick. One selected replication retains full event traces; other replications retain compact numerical results. Source scripts reproduce static examples and verify numerical invariants.

## Operating clock and work assumptions

2,400 operating minutes represent one hypothetical week (five eight-hour equivalents). All processes use the same operating clock; there is no real calendar, night/weekend behavior, rest scheduling, shift boundary or unattended overnight continuation. Do not interpret the results as wall-clock lead times or qualified FAT soak schedules.

| Process | Nominal standard profile | Capacity |
|---|---|---|
| M1 valve machining | 10 min setup + 6 min/valve (existing machining+inspection assumption) | One fixed machine/operator |
| K1 complete kit | 45 min/skid | 1–2 dedicated kit workers |
| A1 assembly | 240 min/skid, incl. one 18 s equal-payload handling element | 1–3 dedicated serial cells/workers |
| T1 test | 180 operating min stand occupancy; 120 min nominal attended effort | 1–2 dedicated stand/technician pairs |

The added 10-minute batch setup and 180-minute test occupancy are new explicit assumptions, not inferred from prior loss records or FAT elapsed tests. A dedicated technician stays reserved during the 60 nominal unattended minutes; sharing that worker with another job is not modeled. Resource utilization for T1 is stand occupancy, not attended labor utilization. No phase-four cut-cycle result substitutes for the 6-minute machining-plus-inspection work content.

Standard and extended-validation routing profiles use exactly the same product and BOM. Extended assumes assembly ×1.20, test occupancy ×1.50 and attended effort ×1.25. Incoming material, machining and kitting remain unchanged. There is no new real SKU, delivered configuration or qualification. Expected extended share is editable; actual profile assignments use independent keyed draws and vary between replications. Attended effort is a documented nominal work-content distinction, not an independently scheduled/shared technician model.

## Assembly task precedence and balancing

| ID | Task | Standard min | Predecessors |
|---|---|---:|---|
| frame | Frame & fixture preparation | 30 | None |
| pumps | Mount pumps | 50 | frame |
| hx | Position heat exchanger | 40 | frame |
| pipe | Connect piping | 45 | pumps, hx |
| wire | Route harness & wiring | 35 | pumps |
| inspect | Mechanical build verification | 40 | pipe, wire |

All six tasks total 240 minutes. Tasks are assigned to ordered cells; every predecessor must be in the same or an earlier cell. Within a cell, the listed topological order is used. Skids pass occupied cells serially; different skids can work concurrently in different cells. A worker with no assigned task stays idle and remains in the staffing denominator. Cell transfers inside A1 have zero modeled distance.

Balancing enumerates at most 3^6=729 assignments, rejecting precedence violations while generating them, and minimizes maximum nominal standard-profile cell load. Ties retain the first lexicographic assignment. Exact largest-cell optima for these task assumptions are 240/120/85 minutes for one/two/three workers. Line-balance efficiency = total work / (workers × maximum cell work). It is not whole-factory utilization, a global factory optimum, or a physical space/safety approval for staffing.

## Queues, batching and event rules

M1 has an unbounded order-release backlog. Each downstream ready queue has 1–8 waiting slots; jobs in transit reserve those slots before leaving upstream work. Slots exclude jobs already in service. FIFO service uses the first available dedicated resource. Finite waiting slots count queued + reserved jobs; displayed mean queue measures ready waiting jobs only, excluding transit reservations.

M1 starts a full batch up to the chosen maximum (1–4 valves) when available, or a partial batch after the oldest queued order has waited 60 operating minutes. A one-valve batch needs no fill delay. One machine works on one batch at a time. Setup is paid for every batch, including partial batches. When service completes, downstream space must be available before transfer. Pending output keeps the machine/resource blocked, so it cannot start another job.

M1 outputs can be split into smaller loaded bin transfers up to available kit-queue space. Other inter-area transfers carry one kit/skid. Transfer groups reserve downstream capacity and free their upstream resource when all its outputs depart. Within-area cell transfer delay is zero. Every transfer is explicitly scheduled; no job appears at a destination without a matching reserved arrival. Dedicated unconstrained transport capacity is assumed; empty returns, congestion, vehicles, porter staffing and maneuvering are omitted.

The stable min-heap orders events by time, then warm-boundary priority, then completion/transfer priority, then arrival/wake priority, then serial ID. Zero-time transfers are settled by new events at the same time. Measurement uses the half-open window [warm-up, horizon). At the warm-up boundary, starting WIP is captured before same-time arrivals/completions; events at the final horizon are not processed. Empty-start, same-time and censoring boundaries are tested independently.

A 500-arrival, 20,000-event and 10,000-settlement-iteration safety bound prevents unbounded browser work. Valid UI settings remain well within these limits in the tested high-load scenarios.

## Demand, random draws and repeatability

Demand 1–24 skids per operating week is shared with factory planning. Leveled releases are spaced at 2400/demand minutes starting at zero. Weekly-batch releases put the weekly orders together at each week boundary. Exponential arrivals use -ln(U)×2400/demand; the actual request count then varies around the expected rate and is reported in each replication.

Fixed durations or symmetric triangular multiplicative variation with endpoints 1±.20 or 1±.40 are selectable. Triangular mean is 1. For width w, multiplier is 1-w+w sqrt(2U) for U<.5 and 1+w-w sqrt(2(1-U)) otherwise. Each assembly task has a separate keyed draw; changing task assignment does not change its underlying work sample. M1 batch duration uses a draw keyed by its first order, so changing batch grouping can change that aggregate service draw; comparisons are paired, not identical full event paths.

Replications 1–20 use seed 63241 + replicationIndex×104729. A 32-bit integer hash mixes seed, order index and draw tag with Math.imul constants 0x9e3779b1, 0x85ebca6b, 0x7feb352d and 0x846ca68b; shifts are 16,15,16; U=(unsignedState+.5)/2^32. Separate tags generate arrivals, profile, machining, kitting, each task, test and terminal scrap. Job-level exogenous arrivals/profiles/potential scrap outcomes are stable across reference/candidate policies. These are pseudorandom teaching inputs, not fitted distributions.

Terminal scrap probability 0–10% is a synthetic whole-skid, non-repairable exit rule after modeled test service. No rework loop is included. It is unrelated to supplier NCR, SPC defects or ML probabilities and does not establish a physical failure cause.

## Layout and workstation coupling

The declared one-meter route grid and actual selected feasible positions supply M1→K1, K1→A1, A1→T1 and T1→D1 loaded distances. Transfer minutes = metres/(60×speed_m_per_s), with speed .5–1.5 m/s. Paths avoid the same expanded footprints as the layout workbench. Dynamic simulation trip groups can differ from the fixed weekly movement comparison; route lengths are shared, not its presumed trip count or handling-cost model.

One 10 kg reference-payload bundle is handled per skid inside frame preparation. Its baseline 18 s is already inside the 30-minute task. The simulation replaces that element with the selected declared timing only: frameMinutes=30+(selectedHandlingSeconds-18)/60. The rest of the 240-minute assembly work is unchanged. Equal payload is required. An unsupported proposed workstation or different payload blocks coupling until repaired or explicitly replaced with baseline timing. A lifting index never becomes a time multiplier, workload approval or safety guarantee. Baseline manual risk remains a separate assessment.

Invalid task precedence, infeasible layout or incompatible selected handling blocks candidate simulation and stays repairable. Reference results remain available. Disabling a coupling explicitly selects its baseline context, not a fabricated valid candidate.

## Comparison and uncertainty

Reference policy uses one kit worker, one assembly worker, one stand/technician pair, two waiting slots, four-valve maximum batches, baseline geometry and baseline handling. Both policies retain the same selected demand, mix, release distribution, variability, scrap probability, speed and measurement/warm-up window. Task/staff/buffer/batch/context changes are the compared policy effects; changed exogenous demand is not labeled a policy saving.

Twenty independent seeded runs report sample mean and sample standard deviation. Approximate 95% confidence interval for each replication mean is mean ± 2.093024054408263×s/sqrt(20), df=19. Paired policy intervals use the 20 same-seed differences. These intervals concern simulation means, not individual-run predictions, real-factory forecast uncertainty or parameter uncertainty. With discrete, skewed or growing-backlog results, coverage is approximate; no steady-state or actual improvement is established. Interval bounds are not clipped to hide approximation.

Default warm-up is one operating week and the measurement window four weeks. Time-weighted WIP, ready queues and working/blocked fractions integrate current state over every event interval clipped to that window. Work + blocked + idle sum to resource capacity-time; blocked and active work are distinct. Warm-up mitigates empty-start bias without proving stationarity; overloaded queues can keep growing. Zero warm-up intentionally retains the transient.

Completed output counts all flow exits in the observation window, including jobs arriving during warm-up. Lead time is summarized only for orders born after warm-up and completed before the horizon, with its count and unfinished cohort separately shown. It is right-censored and can underestimate lead time in overloaded scenarios; unfinished records never receive zero duration. Replay and raw material totals cover the whole run, including warm-up, and are clearly distinguished from measured-window metrics.

## Material and order conservation

For every run:

- Whole run: arrivals = completed + terminal scrap + ending system WIP.
- Measured window: starting WIP + window arrivals = window completed + window scrap + ending WIP.
- Raw valves allocated = machined valves + valves still in backlog/machining.
- Machined valves = consumed in started kits + unconsumed machined valves (blocked/queued/transit).
- Each kit start consumes 1 valve, 1 harness set, 2 pumps, 1 heat exchanger and 1 frame. Purchased consumption is reported separately; it is not netted against original lot quantities.

System WIP includes arrived release backlog, queued work, processing, blocked output and transit. Queue counts and resource counts use different units (orders versus occupied resources); a four-valve machining batch occupies one machine, not four machines.

## Measurable synthetic example results

All examples use the baseline route geometry, default 25% extended mix, triangular ±20%, 2% terminal scrap, leveled demand, one-week warm-up and four-week measurement; they are **calculated synthetic outcomes**.

| Scenario | Requested / operating week | Mean flow-complete / week | Approx. 95% CI | Time-weighted WIP / orders |
|---|---:|---:|---|---:|
| baseline-eight | 8 | 7.8250 | 7.7105–7.9395 | 1.9391 |
| one-worker-sixteen | 16 | 9.3375 | 9.2158–9.4592 | 21.8295 |
| two-workers-sixteen | 16 | 11.6125 | 11.4135–11.8115 | 15.3624 |
| two-workers-two-test-stands | 16 | 15.6750 | 15.5006–15.8494 | 3.8881 |

Adding an assembly worker at low demand does not automatically create output: at eight requests/week the recorded mean remains 7.825. At higher demand, test capacity can become the limiting resource. Exact per-run metrics and conservation examples are in flow-manifest.json; the live workbench always recomputes from its actual scenario.

## Reproduce and validate

From the Site checkout (existing Node/pnpm dependencies):

```sh
pnpm docs:flow
pnpm check:flow
pnpm typecheck
pnpm build
```

The complete Site source includes the engine and test fixtures; no simulation dependency install is required. Static generation changes only the disclosed flow method/manifest. Browser export includes complete selected settings, layouts, handling context, reference/candidate replication metrics, paired differences and one selected replication's orders/events/intervals/transfers/snapshots. Event CSV identifies every row as synthetic and retains exact operating-time precision. Factory export includes settings only and directs readers to the detailed simulation record.

Verification independently reproduces a one-order 481-minute zero-transport schedule, an eight-order horizon/window case, transport and extended-profile arithmetic, equal-payload timing replacement, finite-buffer blocking, exact cell optima, seeded stochastic outcomes, resource/valve/order conservation, known-sample t intervals, invalid-context repair and schemas 1–5 migration. UI verification covers replay, staffing/assignments/precedence, distribution and mix controls, blocking, invalid contexts, exports, navigation, phone/touch/keyboard, both themes and accessibility.

## Lessons and limits

More staffing is useful only when the rest of the flow can support it. Bottleneck evidence comes from occupancy, queues and blocking, not just the largest nominal task. Warm-up and censored orders matter when queues grow. Every apparent benefit depends on invented service/distribution/supply assumptions. Real use needs time studies, validated arrivals/service distributions, actual calendar/resources, material availability, uncertainty, safe work design and independent quality authorization.

## Primary method references

[SimPy monitoring guide](https://simpy.readthedocs.io/en/stable/topical_guides/monitoring.html) provides process/resource/event monitoring concepts; this Site uses its own TypeScript event engine, not SimPy. [NIST confidence limits for the mean](https://www.itl.nist.gov/div898/handbook/eda/section3/eda352.htm) supports the sample-mean t interval. These references support general methods, not the fictional manufacturing inputs or real operational effectiveness.