Case study: Two-system strong-contract coupling

Background: This page describes a real overseas glazing / window subcontractor engagement. Every plant’s process and toolchain differs; treat this as a reference pattern. Production rollouts follow the P0–P3 playbook (see the Project delivery (four phases) section on the manufacturing solution page).

Why “two systems” instead of two siloed tools?

From inquiry to production, the workflow naturally splits into drawing review → quotation. Their inputs and outputs are tightly coupled:

The structured door/window manifest from review is the quotation system’s input
Customer conventions must be visible in both legs
Engineer red hard-stops must block the quotation system from accepting bad jobs

If the two legs are separate tools with manual hand-offs, bad orders still flow from review → quote → factory. If both run on one platform as two coupled modules tied by files + state contracts, faulty jobs are stopped at the source.

End-to-end flow

Rendering diagram…

Strong contracts

Contract	Meaning	Enforcement
Review state	`"passed"` / `"in progress"` / `"rejected"`	Quotation hard-rejects unless review is passed
Structured manifest schema	Required fields per opening (series/W×H/qty/glass/hardware/finish/swing/node ref)	Missing fields → quotation rejects
Provenance tags	Every field carries `source + confidence`	Low-confidence fields surface extra sales confirmation
Customer-convention pointer	Same convention library for both modules	Review-learned preferences instantly visible in quotation

Shared historical memory

One per-customer isolated memory backs both systems:

Dimension	Writers	Readers
Customer conventions (e.g. “customer X defaults to LowE+Argon”)	Review	Review (auto-injected) + quotation (similar-job signals)
Error patterns (e.g. “hardware alias gaps”)	Review + quotation	Review (early warnings) + quotation (low-confidence flags)
Historical neighbours	quotation	quotation (price anchors)
Negotiation floor distributions	quotation	quotation (negotiation hints)
Waiver rationales	Review	Review (input to rule evolution)

Decoupling flexibility: buy separately

Despite the ideal joint story, the two systems are decoupled via files + state, so they can go live independently:

Scenario	Option
Strong quotation already, review is the bottleneck	Drawing review only → emit a standard Excel manifest; keep current quoting
Strong review already, inconsistent quotes	Quotation only → sales types the opening list manually
Both pain points	Bundle with strong-contract coupling
Phased proof	Start with review (smaller blast radius) → add quotation once stable

Extra value of the bundle

Dimension	Two independent tools	Coupled two-system design
Upload churn	Sales uploads twice (review + quote)	Once (review auto-feeds quotation after pass)
Customer conventions	Maintained twice	One shared library
Bad-order containment	Quote system blind to review status	Review not passed → quotation hard-rejects
Status visibility	Two UIs	Single project timeline
Audit trail	Split records	One chronological chain

Commercial packaging

Package	Contents	Fits
Drawing review standalone	Full M1–M10 scope for review	Customers who already quote elsewhere
Quotation standalone	Full M1–M10 scope for quoting	Customers not ready for automated review yet
Bundle (recommended)	Both + strong contracts + shared memory	Customers who want the full chain

Contact info@nox-lumen.com for pricing.

Suggested implementation order

If you adopt both modules:

Week 1-2:   Joint P0 (sample curation)
Week 3-5:   Drawing review P1 ‖ Quotation P1 (parallel)
Week 6-8:   Drawing review P2 ‖ Quotation P2 (parallel)
Week 9:     Integrate contracts (drawing review → quotation)
Week 10-11 Memory wiring + fleet go-live

Total roughly 10–11 weeks, similar to single-system thanks to shared P0 and parallel streams.

Case study: Two-system strong-contract coupling

On this page