Product knowledge that keeps working.

In the proposed model, the maker supplies the product twin and its permitted knowledge: manuals, specifications, configurations, compatibility evidence, service procedures, policies and known limitations. Keep sources, revisions, ownership and access attached. Retrieval indexes or vector databases can make that knowledge available to the chosen inference service; the implementation must fit its models and access rules.

Agentz is intended to provide contextual customer assistance whenever the service is available: explain supported facts, identify missing evidence and route requests to the responsible team. In the intended design, Cortex would retain permissioned product history, and APU would organise stored records. This website does not connect those services. An answer must not invent a repair, coverage decision or delivery promise.

That foundation could connect customer service to order-book sales, affiliate marketing, eligible local fulfilment and product operations. The product mirror can progressively extend into a mirror of the value chain. A bounded pilot would test the system; it would not limit the product’s knowledge to one preselected question.

In the proposed flow, a customer could choose a product’s size, components, accessories and service options through its virtual twin. The configuration would become an exact, versioned specification for the maker, customer and their agents to share.

Before the customer commits, show which path applies, the payment timing, and cancellation, refund and delay terms. An unresolved custom specification starts as a request for quotation; it enters the order book once the maker can commit to exact terms.

Production and inspection records follow the accepted configuration. A later design change needs an explicit revision and agreement; it cannot silently change what the customer bought. The example below illustrates product structure, not a live configurator or manufacturing service.

First, practise reading a specification. Sample revision A has no selected maker or price, and its load rating is missing. It is a separate example from the LA-02 comparison and AX-14 order simulation.

Next, compare an offer.

The LA-02 example adds a buyer’s brief, maker offers, costs and service commitments. Its proposal remains conditional on unanswered questions; it does not inherit evidence from this specification exercise.

Explore the LA-02 comparison

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.

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.

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.

Follow a brushless-motor compatibility correction

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.

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; each offer needs its own eligibility evidence and applicable service commitments. Whether the proposed Skyzai XaaS standard becomes mandatory remains undecided.

Porter’s value chain maps the work behind an offer. Its five primary activities show where work creates and sustains value; they are not a mandatory checkout chronology. A service business can combine activities or use partners while keeping responsibilities visible.

See the illustrated Markets experience.

The supporting work matters too.

Procurement selects and purchases inputs; inbound logistics handles their arrival, storage and availability. People and skills, technology development and organisational infrastructure support every activity. Product and service twins connect specifications, sources and history across the chain.

The seven products contribute selected capabilities rather than becoming five process stages. Each can support work in more than one activity.

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.