On this page
We · Skyzai Markets
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 | Verified maker and contractual seller, exact offer versions, quantity or usage unit, validity, costs, availability and delivery terms. |
| Service and history | Matching Skyzai XaaS, care, maintenance, accepted corrections, upgrades and lifecycle records. |
One twin can link to several eligible maker offers, with distinct stock and terms. Retailer resale offers are outside the listing direction. 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 product family and the rights record
Accessories, peripherals, consumable supplies and replaceable parts each need their own identity and version. A compatibility link describes a scoped claim; installation, title, warranty and licence rights come from their own records.
Compare the installed asset, replacement instance and pinned invoice. The partial-acceptance example leaves the twin’s installed-part record unchanged until the workshop accepts the complete unit.
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.
Keep the next decision attached to its record.
Bind each part, accessory and replacement to its own revision, instance and source. A twin or compatibility edge creates no title, stock, service coverage or purchasing permission.
Open the same fictional order as Me · buyer, We · author and accountable workshop or They · machine. Each visit starts a new local example; perspective controls within it preserve the record.
We · value creation · LIQUID · exchange scope · SoResFi · instruments and obligations · Network · economic receipt requirements · Aureus · asset origination
A product twin does not transfer title. Local logs do not issue OFN receipts. An order or accepted result does not establish payment. The originator, issuer, venue operator, chain operator and custodian retain separately specified responsibilities.
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 Markets 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.