On this page
Product-sale qualification
The catalogue must identify a valid, exact service offer and evidence that its scope covers the intended sale. Menexus retains ownership of programme and contract requirements.
Skyzai Marketplace
The service follows the product.
Every product offered for sale on Skyzai would need a qualifying Menexus XaaS offer. The commitment must identify the exact product, use context, responsible provider and remedy.
- Exact product + context
Version, configuration, buyer use, region and period.
- A named service commitment
Scope, capacity, price/payer, support and remedy.
- Qualification and validity
Evidence must cover this product and intended sale.
- A sale can become eligible
Other fit, authority, seller and delivery checks still apply.
No qualifying XaaS, no sale
XaaS connects the product with the service that keeps it useful. What that service includes depends on the offer: support, continuity, care, maintenance, access, upgrades, measured work or remedies. A generic badge, populated fields or an intention to arrange service later is insufficient.
The buyer’s service choice
A qualifying service offer does not automatically enrol the buyer in a subscription. Service can accompany a purchase or be integrated with usage or access. Its payer, term, inclusion and cost allocation must be explicit.
This direction does not override the digital usage-only model or turn an API response into a guaranteed outcome. Existing Menexus subscription language and the new usage direction still need an explicit integration decision.
Name the commitment
| Record or decision | What it needs to say |
|---|---|
| Product link | Exact product, version/configuration, service-offer ID/version and covered transaction. |
| Responsible parties | Maker, seller, fulfiller and named service/remedy owner. |
| Scope and unit | What is provided, how measured, capacity, service level, exclusions and evidence. |
| Context and time | Buyer/operating context, region, duration, validity, renewal and withdrawal. |
| Price and payer | Included versus separate costs, who pays and which usage or access terms apply. |
| Remedy and exit | Support, service failure, cancellation, refund, portability and what remains owed. |
Offer qualification and delivered service performance are different facts. An admitted provider still needs evidence for its actual work. A website fixture cannot establish a valid contract, coverage, insurance, capacity or provider acceptance.
Qualification has a scope and a lifetime
A service offer has a scope
Fictional XAAS-LA-02, version 1.0-demo, names actuator LA-02 in workshop region R-01. Change the intended sale to see why a badge alone is insufficient.
A later service change must preserve the original order and its accepted obligations. Replacement terms need their own review; history is not rewritten.
If a provider withdraws or changes a service offer, eligibility for future sales must be reconsidered. Existing accepted obligations, correction history and buyer remedies remain recorded. A successor offer does not retrospectively alter a past order.
The product twin carries the exact links, and the order proposal pins them for review. A product-version change cannot inherit qualification by appearance alone.
Keep the product useful
A product-aware service assistant could inspect permitted manuals, compare sourced compatibility claims and prepare a repair request. It should preserve conflicting evidence and route unresolved facts to the accountable provider. It does not itself approve engineering fit or book service.
The same lifecycle applies to a digital app’s continuity, a robot’s maintenance, a component’s replacement and an energy-service commitment. The programme must select the actual providers, admission evidence, service terms and cost allocation before representing a live qualifying offer.
Product design, with local illustrative examples. Live inventory, billing, orders, attribution and payouts are not connected.
Continue exploringNudgeAttribution, recommendations and a finite reward pool.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.