Manufacturing Intelligence

RD-03 · Center Point Labs · Research white paper · Version 1.0 · 14 September 2026

Abstract

Manufacturing Intelligence is an ongoing research project and working capabilities demonstration: a way to investigate how relational manufacturing records can become useful operational answers without obscuring the data underneath. A real PostgreSQL database contains 5,412,559 synthetic operational records across 24 linked tables. The console connects order exploration, lot genealogy, material risk, quality evidence and bounded CSV integration. It is not a packaged ERP, a production deployment for a manufacturer, or a certified quality system.

Cypress Bend Manufacturing and all operational data in this demonstration are fictional. No real manufacturer's operational data or proprietary specifications are presented. Record volume is measured; commercial impact is not.

1. Architecture and research method

The browser runs a React 19 / TypeScript console built with Vite. A Node / Express 5 API issues parameterized PostgreSQL queries through a 12-connection pool. The seven areas are Overview, Order explorer, Lot traceability, Material risk, Quality, Dataset and CSV workspace. Keyset pagination bounds order retrieval; virtualization bounds rendered rows. Charts drill into records instead of substituting visual aggregates for traceable evidence.

The deployed topology is browser → HTTPS/Caddy → nonroot, read-only Node application → private Unix-domain socket → PostgreSQL 16. PostgreSQL has no network interface or published TCP port. Reference SELECT privileges are separated from visitor-workspace writes. The public host is an existing DigitalOcean Ubuntu 24.04.4 server with two shared vCPUs and approximately 4 GiB RAM; it is not the Ryzen workstation used for the detailed benchmark below. The application has a 512 MiB memory limit and the database 2 GiB. Bounded requests, timeouts, expiry and resource monitoring limit a public demonstration's working set; they do not establish enterprise availability or security certification.

The method is to define a causal fixture, generate deterministic records, validate relational and business invariants, build explicit query paths, inspect execution plans, and measure distinct database/API/browser boundaries. The completed reference passed 34 SQL integrity checks. Twelve API integration suites cover queries and real database-backed visitor workflows. Saved browser evidence includes desktop and touch-emulated mobile interaction, including actual CSV upload/download and dropped-response recovery. These are engineering checks, not an independent audit.

Materialized snapshots serve named aggregate views and carry refresh metadata. They are deliberately distinct from live base-table joins. No claim is made that every chart scans 5.4 million records on each request. The reference is frozen, with business-record timestamps spanning 2020-01-01 through 2026-01-10 UTC; it does not simulate a continuously changing factory.

2. Data model and provenance

Cypress Bend Manufacturing is fictional. No real customer, supplier, personnel, address, proprietary specification or certification data is used. The 180-person company size is a planning assumption, not a generated employee table.

Operational footprint

The exact immutable reference manifest is reference.manifest: 5,412,559 linked records in 24 operational tables. This count excludes the manifest, refresh metadata, materialized aggregate copies and all visitor data. Seed 73013, generator 1.2.0, fixed dates and deterministic integer arithmetic; no wall-clock dates in business records. The manifest/refresh timestamps and visitor IDs are intentionally nondeterministic metadata.

Causal process rules

• Six component preparation operations each consume 10 ea of a distinct frozen-BOM component and record 9 good + 1 scrap. They are independent component inputs, not serial transformations of the same ten pieces. Thus summing six operation outputs does not represent finished-assembly throughput. Final assembly availability is bounded by the smallest component-stage good output (9).
• 40,000 work orders have finished lots. Remaining work orders represent WIP/assembly or replenishment demand after component preparation. Completed operation timestamps are not a claim that every work order is finished. Active reservations represent remaining demand, not additional completed consumption.
• 60,000 raw lots are received in two ledger entries per lot, two days before their earliest component consumption. Procurement cohorts span the five-year history. PO order dates precede expected/actual receipts. 60,000 PO lines have no receipt yet; late and partially received lines are intentional.
• Final lots receive 9 ea, then ship 4 and 5 on separate shipments. Ordered line quantity remains 10, so these are genuinely partial orders, not falsely labeled fully fulfilled orders. The backlog is deliberately large: all 60,000 orders remain open or partial. This fixture emphasizes open commitments; it is not a representative backlog-rate estimate.
• Revisions A are frozen on historical orders. The 15,000 B revisions are future specifications effective 2026-01-01; historical orders do not silently adopt B. Some future revisions have no released BOM yet.
• BOM component revisions are lower-ranked leaf IDs; the complete graph obeys a strictly descending rank, proving it acyclic. A recursive cycle trigger rejects arbitrary cycle-creating inserts/updates. Only deterministic bulk BOM loading temporarily disables that one trigger; FKs remain enabled, the trigger is restored immediately, and full-graph integrity is tested afterward.
• Q4 demand is intentionally heavier; customer demand is concentrated in a small group, and WC-07 is skewed to high workload. All 36 centers are present, including zero load for any idle centers. All characteristics, defect limits and lead times are explanatory synthetic values, not engineering specifications.
• Timestamps are timestamptz, displayed in UTC date form. Physical quantities are NUMERIC(14,3) with part/unit context (ea in the reference); monetary values are integer USD cents with explicit currency='USD'. No floating-point monetary ledger.
• Inventory movements are authoritative. stock is a read-only derived snapshot; reservations reduce available stock only. No independently editable physical balance exists.

Known stories (tested against full data)

The raw-lot hold is retrospective: it opens after the affected historical shipments. The trace UI answers an investigation, not a claim that a currently quarantined input was deliberately released for production.

Metrics and dates

daily_production, daily_quality, order_summary, supplier_quality, center_load, stock, late_receipts are materialized snapshots, explicitly labeled. Exact refresh completion per view is recorded in aggregate_refresh; these reads are never represented as multi-million-row scans. Chart clicks use the selected month intersected with the active date range, then fetch matching base records with bounded keysets. Supplier/center drilldowns retain their explicitly all-history scope.

3. Useful investigation workflows

Supplier-quality investigation

Start with RAW-000001 in Lot traceability. Follow the supplier lot through consumption to ten affected work orders, then four finished lots and eight shipment lines totaling 36 units. The hold is retrospective: it opens after those historical shipments. This demonstrates how an investigator could scope exposure, not a claim of a validated recall process or automated release decision.

Material planning and purchasing

Use Material risk to separate physical on-hand from active reservations. The known fixture has zero on-hand and 60 reserved units, producing −60 available and six threatened work orders. Follow the related purchasing evidence; purchase-order line 1 is eleven days late. This supports a reasoned investigation but does not optimize replenishment or issue purchase orders.

Commitments and production context

Use Order explorer to filter commitments, sort value or date, and export bounded records. A line ordered for ten units ships in two partial deliveries of four and five. Inspect work-center load and chart drilldowns to explain where event minutes accumulate: WC-07 is the intentional all-history bottleneck fixture. Component-stage good output is not finished-assembly throughput, and event minutes are not a finite-capacity schedule.

Quality and integration review

Compare supplier sample rejection rates with their denominators, then inspect the underlying records. In CSV workspace, stage the sample file, review accepted/rejected rows, apply only the accepted subset, download rejections, and retry or reset. Use synthetic sample content: this public workspace is temporary and is not a destination for confidential production records.

4. CSV integration: isolation and recovery

This is an import laboratory, not a production master-data import. Operational reference tables are never mutated. Every browser gets a cryptographically random HttpOnly/SameSite=Strict cookie mapped to one PostgreSQL visitor session. Public HTTPS uses Secure cookies; local loopback development uses non-Secure cookies.

Input

UTF-8 CSV, optional BOM, quoted fields/newlines supported by csv-parse. Exact header:

sku,description,quantity,unit
SAMPLE-1,"Quoted, description",25.125,ea
SAMPLE-2,Cable,12.5,m

• 256 KiB request body ceiling (JSON encoding overhead counts); UI rejects files >256 KiB. Near-limit files may be rejected by the stricter encoded-body ceiling.
• 1–1,000 data rows, 2 KiB max record size.
• SKU: 1–40 uppercase letters/numbers/./_/-, first character alphanumeric.
• Description: 1–200 printable characters; literal text, never rendered as HTML.
• Quantity: decimal 0–1,000,000, at most 3 places; no scientific notation or negatives.
• Unit: ea, kg, or m. These isolated visitor units do not revise reference part units.
• Duplicate SKUs within one file are rejected after the first occurrence. A malformed first occurrence still reserves that SKU in the file, making subsequent duplicates explicit instead of silently choosing a winner.

Transaction states

1. Staged: parse/validate once, accepted and rejected rows persisted with source row numbers, exact content SHA-256 and caller retry key; no parts changed.
2. Committed: explicit apply locks the owning session/import and atomically upserts accepted SKUs. Existing quantities are replaced, never incremented. Rejected rows remain downloadable. All-or-nothing for the accepted subset.
3. Cancelled: explicit cancellation prevents subsequent commit. Repeated cancel is idempotent; commit-after-cancel returns conflict.

Retrying staging with the same key + content returns the original import; same key + different content is rejected. Repeated/concurrent commit returns the already-committed result with one committed audit event. If the response disappears after commit, reload and review/retry safely. Tab sessionStorage preserves the draft and retry key; server history supports resuming staged records across reloads. Different committed imports affecting the same SKU serialize on the session lock; last committed import wins.

Isolation and bounds

Every import, row, part and audit query is owner-scoped. Another visitor cannot inspect or commit a known import UUID. Same-origin mutation checks and Host allowlist protect the application surface. No arbitrary SQL endpoint. Database role permissions additionally deny reference INSERT/UPDATE/DELETE.

• 24-hour fixed expiry (not sliding), cleaned every minute and on new-session creation.
• 50 global workspaces; global creation is transaction/advisory-lock bounded.
• 20 imports per workspace, including cancelled imports; 2,000 distinct workspace SKUs.
• 120 workspace requests per minute per session, bounded expiring in-memory rate entries.
• At most 20,000 staging rows per visitor before expiry; no unlimited staging table growth.
• Reset deletes only this visitor's session with cascading visitor rows/imports/audit, never reference data.
• Audit records staged/committed/cancelled events, timestamps, import identity and accepted/rejected counts; source staged rows remain available. It is a demo audit trail, not tamper-evident regulatory logging.

Rejected CSV and bounded operational exports escape cells beginning with formula-significant characters (=, +, -, @, leading whitespace controls), quote cells and double quotes. There is no spreadsheet formula execution in the web app.

Tests cover real DB isolation, duplicate/invalid decimals/quoting, upsert replacement, rejected exports, concurrent commit, cancelled commit conflict, both caps, expiry/reset and reference permission denial. Browser tests actually drop the committed network response, reload and recover. No mocked backend or fabricated mutation response is used.

5. Measured performance

Measured 2026-09-13T18:19:30.862Z. This is a documentation summary; raw JSON, request observations and screenshots remain in ignored artifacts/.

Configuration

• AMD Ryzen 5 8600G, 12 logical host CPUs, 30.43 GiB host RAM. PostgreSQL 16.15, Linux, Node v26.4.0.
• Database and app share affinity 0,1 (at most two logical CPUs); DB quota 2 CPUs / 2 GiB, app 512 MiB cgroup / 384 MiB JS heap. App pool 12; PG shared buffers 256 MiB, work_mem 8 MiB, application parallel gathers disabled.
• 5,412,559 actual reference rows. PostgreSQL database size at measurement 1,477,049,367 bytes (1.376 GiB), including indexes, visitor schemas and metadata, not just heap data.
• Synthetic frozen reference, no API response cache/CDN. Materialized snapshots explicitly labeled; joins/base-table probes included separately.

HTTP benchmark

Closed-loop concurrency 1/10/25, three warm-ups before each workload, 20/30/75 measured responses per workload respectively. 1,125 measured requests, zero errors in this final run. Nearest-rank p50/p95; payload is response-body byte length. End-to-end is loopback fetch through response-body consumption, excluding JSON parsing. Query time includes pool acquisition and row decoding; server time ends before serialization/socket delivery. The console's browser timing additionally includes JSON parsing.

The final sampled ordinary list-page server p95 is below the initial 250 ms target; the full-history overview p95 is below the initial 1,000 ms analytics target. These are achieved results for this bounded run, not latency promises. An earlier post-tune run reached 1,077.82 ms overview server p95 at concurrency 25; normal short-run variation is preserved in artifacts/post-tune-benchmark/ rather than hidden.

Actual browser-render benchmark

Independent Chromium contexts, desktop 1280×900, one per simulated visitor. Overview preloaded; time from Playwright navigation click through 50-row API result, visible virtualized table and two animation frames. Includes browser scheduling and Playwright actionability, not just an HTTP timer. Warm browser assets. Browser/driver shared CPUs 0/1 with app/DB, with a separate 1 GiB memory cgroup / 2-CPU quota. No WAN or physical-device claim.

The 25-page headless result is materially slower than the API p95 because browser pages compete for the same two CPUs. This is not representative of 25 separate physical client devices. An earlier browser stress run triggered the resource guard's one-CPU DB reduction; final before/after quotas above are recorded rather than assumed.

Direct query measurements

Eight base/aggregate fixtures × 20/30/75 observations = 1,000 measured direct database calls. Timings include local pg-client pool/transfer; engine-only timing is separately in EXPLAIN.

EXPLAIN ANALYZE evidence

artifacts/explain.json contains full ANALYZE/BUFFERS/SETTINGS JSON. artifacts/explain-api.json adds the exact order-prefix and late-receipt API SQL. Required workload indexes were actually selected:

Cache methodology

Final cache probe: 2026-09-13T18:24:29.472Z. Restarted only manufacturing-db and its own app connection pool. Host OS page cache was deliberately retained; no other DB/app/service was restarted.

• First lot-ledger EXPLAIN: 0.112 ms, 14 shared-buffer reads.
• Identical immediate warm EXPLAIN: 0.033 ms, 0 shared-buffer reads.
• This establishes PostgreSQL-buffer-cold versus warm access, not a cold-disk test. OS cache may serve all reads.
• Sequential HTTP first-touch results after restart are recorded separately in buffer-cold.json; later routes can reuse earlier warmed buffers.
• benchmark.json also records an explicitly non-cold first-touch series after prior integrity/browser activity. It is never mislabeled cold.

Failed initial run and corrections

The first run had 60 HTTP errors, all in the late-receipt workload. Concurrent parallel hash joins exhausted Docker's default 64 MiB shared-memory area. Original observations, errors and plans are retained in artifacts/initial-benchmark/. Corrected by disabling application parallel gathers and reading an explicitly labeled immutable late-receipts snapshot; no memory-limit increase or service substitution. Trace queries were index-targeted and order-number prefix search separated from customer substring search. Final zero-error results followed those changes.

Limits

Local short closed-loop runs, not a soak test, internet-scale load or production capacity certification. No true cold-disk result. No provider/vendor speed claims. Server/query/browser timings measure different boundaries and must not be interchanged. Physical Safari/iOS was not tested. This benchmark is local; the separate public smoke check below is not a repeat of it. Actual field deployments require their own profiling.

6. Public deployment check — a different experiment

The saved public HTTPS smoke check used three rounds each at concurrency 1, 10 and 25 against /api/orders: 3, 30 and 75 successful requests, respectively (108 total). Recorded p95 was 102.33 / 200.68 / 212.40 ms. The timer included fetch and JSON parsing across the public network. There were no explicit workload warm-ups, only one endpoint, and only three observations at concurrency 1; the result is a short connectivity/concurrency acceptance check, not a capacity benchmark. Client network conditions and exact server CPU model were not captured in this artifact. It must not be compared directly with the loopback suite's body-consumption timer or used to promise WAN latency.

Public acceptance also verified trusted TLS, Secure/HttpOnly/SameSite cookies, HSTS, origin rejection, desktop and emulated-mobile workflows. Physical iOS/Safari, long-duration load, multi-region performance and disaster-recovery objectives remain unverified.

7. Reproducibility and evidence

The fixed seed is 73013, generator 1.2.0. Each operational table has an ordered-row fingerprint: SHA-256 over concatenated per-row MD5 values in primary-key order (composite supplier/part order for supplier_parts), using UTC timestamp rendering. The manifest excludes materialized copies, metadata and visitor rows. Metadata timestamps and visitor identifiers are intentionally nondeterministic. A second independent full reseed has not been performed, so repeatability is supported by source and fingerprints, not claimed as a completed second experiment.

For a source-assisted reproduction, use the project's lockfile and a new isolated database—not the public instance or an existing reference schema. Follow docs/OPERATIONS.md: npm ci; start the dedicated database with scripts/database.sh start; run npm run seed (schema, seed, refine, tune, finalize, facility, manifest); build and start via the documented scripts. The seed command refuses an existing reference schema; it is not a reset or migration command. Match the affinity, quotas, PostgreSQL settings and application pool above before comparing results.

Then run scripts/database.sh sql < db/integrity.sql, npm test, and npm run browser. Run the benchmark with NODE_OPTIONS=--max-old-space-size=384 taskset -c 0,1 npm run benchmark; use scripts/browser-benchmark.ts inside the documented 1 GiB / two-CPU scope. Run sequentially on a quiet host. Compare table counts and fingerprints before comparing timings. Cache probes restart only the isolated research database; do not flush the host cache or restart unrelated services.

Source method references: db/schema.sql, db/seed.sql, db/refine.sql, db/tune.sql, db/finalize.sql, db/facility.sql, db/manifest.sql, db/integrity.sql; scripts/benchmark.ts, scripts/browser-benchmark.ts, scripts/buffer-cold.ts; tests/integration.ts, tests/browser.ts, tests/file-import.ts, tests/deployment.ts; and docs/MODEL.md, docs/CSV.md, docs/PERFORMANCE.md, docs/OPERATIONS.md. The repository is not publicly hosted at publication time; these are source identifiers, not downloadable links or a claim of open-source release.

The selected synthetic-only evidence downloads below were copied from saved raw artifacts, not regenerated to improve the reported results. Full per-request observations and historical failed-run evidence remain in the local research archive. The downloadable checksum manifest identifies the exact published files.

8. Research roadmap and limitations

1. Independent regeneration: rebuild in a clean environment and compare every table fingerprint; investigate any drift before performance comparison.
2. Changing operational state: study incremental refresh, freshness budgets and concurrent writes instead of assuming an immutable reference.
3. Representative planning fixtures: expand beyond the deliberately open/partial backlog, add realistic completed commitments and evaluate metric definitions with domain practitioners.
4. Integration contracts: explore versioned mappings, explicit unit conversions, reconciliation and authenticated connector boundaries. The current CSV workspace does not synchronize an ERP or alter reference master data.
5. Operational evaluation: test longer soaks, different query mixes, remote clients and physical mobile browsers; measure storage growth and recovery procedures under explicit service objectives.
6. Access and assurance: investigate production identity, roles, audit retention and tenant boundaries before any real operational deployment. Visitor-cookie isolation is not enterprise identity or tamper-evident compliance logging.

The current result demonstrates a coherent data model, bounded query design, inspectable metrics and recoverable integration behavior. It does not demonstrate labor savings, defect reduction, certification, production readiness, a scheduling optimizer, or guaranteed performance. Future collaborations begin with the operational question and measurable acceptance criteria—not a claim that an ERP package is already complete.

Selected saved evidence

• manifest.json
• benchmark.json
• browser-benchmark.json
• buffer-cold.json
• explain.json
• explain-api.json
• https-smoke.json
• checksums.json