On this page
Skyzai Marketplace
See the whole. Know the part.
A virtual product twin connects an exact product to its assemblies, components, offers and service history. It gives a buyer or agent something precise to inspect and compare.
- Machine or complete assembly
The intended work and its configuration.
- Subsystem and component
Motor, encoder, gearhead, lead screw and housing.
- Exact version and evidence
Identity, interface, compatibility source and revision.
- Maker offer + service
An accountable commercial offer and matching XaaS.
Explore an illustrative actuator
This fictional twin uses a linear actuator and brushless motor instead of a generic product photograph. Select an assembly or part to inspect the example makers and the information that a real offer would need. Interactive concept · fictional hardware Explore a linear actuator driven by a brushless motor, separate its modules, then select a part. Illustrative geometry—not manufacturer CAD, a fit approval or verified specifications. Selected module · demonstration BLM-28-R1 / version 1 Converts controlled electrical input into rotary motion. Compatibility: not verified Choose a maker and preview the request, or see how service would keep the selected module as context. Local demonstration only. Every maker, module and part code above is fictional. No catalogue, stock, fit approval, live AI, order or payment is connected. A production twin needs validated product data—not an AI-generated guess at internal parts.One actuator. A world of parts.
Linear actuator LA-02 / version 2Assembled schematicBrushless motor
Winding, KV, voltage and current limits, cooling, mounting and shaft interface need version-specific evidence.
The drawing is explanatory geometry. It is not manufacturer CAD, admitted inventory, an engineering specification or evidence that brushless motor BLM-28 fits actuator LA-02. They are distinct example products; their interface compatibility is unresolved.
The product graph keeps exact identities
The twin should connect a complete assembly with subsystems, components, accessories, peripherals, consumables, replacement parts and upgrades. A relationship describes how records connect. It does not make those records interchangeable.
| Record or decision | What it needs to say |
|---|---|
| Product and revision | Stable identity, manufacturer, exact version/variant, specification and configuration. |
| Relationships | Parent assembly, bill of materials, dependencies, compatible options and replacement or successor references. |
| Evidence | Source, scope, date, author/responsible party and status of each technical or compatibility claim. |
| Commercial offers | Exact maker/seller offer versions, quantity or usage unit, validity, costs, availability and delivery terms. |
| Service and history | Matching Menexus XaaS, care, maintenance, accepted corrections, upgrades and lifecycle records. |
One twin can link to several offers from different makers or sellers. The order book compares the offers for a defined specification, use context and time horizon. A price on a similar-looking component is not a substitute for fit evidence.
A relation needs evidence
A compatibility correction should update affected future decisions while preserving the original claim and accepted order history. It should not silently rewrite the product revision, service coverage or the buyer’s past commitments.
The graph reaches upstream
For white-collar machine intelligence, the product can be a model, an app or a digital work service, with provider and compute dependencies. For blue-collar machine intelligence, it can be equipment, a robot, a component or a measured physical-work service.
Manufacturing, chips, data centres, racks, cooling, connectivity, installation, energy generation, storage and delivery belong to the intended upstream scope. A physical product may be bought as an asset or offered by usage; a digital product may combine a licence with a service. Each offer must describe the deliverable, rights, unit, duration and accountable party.
Energy dependency records do not prove supplied electricity or connected meters. The graph explains the target supply chain; every offered product still needs its own eligibility and qualifying XaaS.
Product design, with local illustrative examples. Live inventory, billing, orders, attribution and payouts are not connected.
Continue exploringOrder bookA need, comparable offers and a bounded proposal.Source: Skyzai Marketplace product model and public explanation and decision map. GitHub repository access may be required. These pages describe the design; they do not adopt commercial terms.