Engineering inside Nexus /

Interface and interaction architecture

The narrative website uses an original generated listening-edition image. The studio explorer retains GSAP transitions, Three.js inspection, named parts and source-backed specifications; the headphones artwork is not the inspectable interface model.

Original geometry and explicit specifications

Products reference an optional validated embedded GLB and a bounded set of text or numeric specifications. Numeric values must be finite. The One and Pro assets use named component hierarchies for inspection, while device information is also represented as readable data. Model complexity counts describe the asset; they do not establish hardware performance.

Compatibility is checked twice

The interface presents permitted accessory combinations, and the server rejects unknown, duplicated or declared-incompatible selections. Comparisons accept one to three distinct products belonging to the workspace. This keeps a saved configuration consistent even when a request is submitted outside the normal visual path or an old screen carries obsolete choices.

A comparison is saved state

The comparison stores product snapshots and selected accessory identifiers. Reopening restores the selection, and its PDF includes the selected accessory names rather than the whole available catalogue. A changed accessory choice clears the current saved-comparison binding in the interface, prompting another save before continuing with that revised configuration.

Requests preserve the reviewed context

A walkthrough request is bound to a comparison and checks product membership, accessory compatibility and contact details. The saved request includes selection snapshots with the product names and supported specifications. This makes later operator review concrete. Authentication and workspace checks protect the records; a successful local request response does not imply provider-side scheduling.

Operating the product

Save the comparison again after changing an accessory so the exported and requested configuration matches the latest choice.

Resolve invalid or incompatible accessory errors against the current product catalogue before retrying.

Keep source models and their rights records when importing a new product.

Review the request’s retained specification and selection before confirming a walkthrough with the visitor.

Verify any external scheduling or notification integration independently before claiming that a request reached a recipient.

Independent by construction

Nexus has its own application source, build configuration, local server, database, object store and session cookie. The fifteen applications reuse copies of a common foundation, but their operational data and credentials are independent. A shared dependency cache on this Mac saves disk space; each product includes a lockfile and a command to install its own dependencies.

Mutations validate the workspace and current record version. Approval binds the reviewed content digest; an idempotency key prevents an identical retry from becoming a second action. These controls are implemented in the server, alongside the product-specific rules described above.