Compare offers. Name your price.

The same robot. Different customer rights.

A durable machine can be sold outright or used by a provider to deliver inspection-as-a-service. XaaS describes the commercial arrangement. It does not automatically transfer ownership or include insurance and upgrades.

Compare what you receive, what you own or may use, how delivery is measured, the full cost and payment timing, and how the arrangement ends. Digital outputs, consumables and bundles need the same clarity.

The durable-goods example uses AX-14, the same fictional candidate as the separate order-lifecycle simulation. The other offers keep their own records and terms.

Follow the AX-14 order example · See what digital work costs when you decline a purchase

LIQUID is the intended shared exchange application for maker asks and buyer bids. Marketplace, POS and work orders use shared tools; they do not create a new buyer package or collapse commerce and finance into one obligation.

For rental capacity, the manufacturer issues its own-product offer. Identify the actual asset owner and any manufacturer-appointed delivery, setup or service partner. Skyzai does not own or finance the fleet. Delegated publishing and supplier admission still require qualification.

Both types bind the exact configuration, condition, delivery and service terms. The initial design uses the eligible maker’s ask price, constrained by the buyer’s full delivered-cost cap, with price then time ordering and a deterministic tie-break. These are execution requirements to qualify, not a live matching guarantee. Affiliate rewards and AI recommendations do not change that priority. A serialized robot or actuator cannot be split into a partial unit.

A match still needs the applicable authorisation and seller commitment. Payment, made-to-order production, delivery, acceptance and any remedy remain traceable stages. These pages do not accept or execute real orders.

A rental bid and ask must also agree on place, period, supported configuration and service. The same proposed single-ask, complete-quantity scope applies; a cheap but unavailable period does not qualify. The current purchase simulations do not implement rental matching or reservations.

For an anticipated product, open the buyer side first. Customers can place limit bids for a defined configuration and delivery window before the maker opens sell offers. The maker can inspect demand and later publish exact asks that compatible buyer bids may take. The selected initial scope still requires a single ask to cover the whole requested quantity at the maker’s ask price.

A one-sided book shows demand, not completed sales or guaranteed availability. An early bid is not a paid preorder or a guaranteed place in the allocation. If specifications or delivery terms are still unresolved, collect a non-binding indication or request for quotation until an exact order can be defined.

The proposed launch must publish when supply opens, how bids expire or are cancelled, how funds and eligibility are checked, and how quantities and fills are allocated. Richer bid-taking, multi-ask and partial-fill mechanisms remain broader designs requiring separate rules and qualification; they are not the selected initial execution scope. Unsold supply and unfilled demand remain visible.

If the configured product is already stored, use the exact variant to find eligible stock. Compare availability, reservation rights, total delivery cost, arrival time and destination requirements. The intended preference is the closest eligible inventory, including an authorised local retail fulfilment location. Availability, exact fit, delivered cost and promised arrival must still qualify; proximity alone is insufficient.

If no suitable unit is available, use the maker’s accepted production schedule. After manufacture and quality checks, dispatch to the agreed destination. Show the customer which path applies and its delivery commitment before they pay.

Follow reservation, dispatch, delivery and any return, with a named maker, storage or delivery partner responsible at each step. The AX-14 simulation below illustrates existing stock; it does not execute inventory routing or production.

Advance bidding describes how demand enters the market, not a fourth delivery method. The production, booking and advance-bid paths are designs explained here, not working transactions in the demonstrations.

Rental availability must include transport, setup, maintenance and turnaround between customers. Before confirming, the provider must reserve the whole agreed capacity without overlapping another accepted booking. Handover, service-period acceptance and return inspection remain separate events. Cancellation or a failed delivery follows the agreed remedy; it is not fulfilled rental time.

Set a workshop need, compare the fictional offers and stage a conditional unsigned draft. The actuator, brushless motor, compute and energy examples illustrate record structure. They are not available stock or real supplier quotes.

The draft retains the need and exact product, maker-offer and XaaS versions. Changing the brief afterwards does not silently rewrite it. An attached Nudge tag remains an attribution candidate; it creates no retained sale or payable commission.

Technical compatibility, stock, delivery and real service qualification are unresolved. The displayed draft is conditional on their clarification and makes no provider, seller, order or payment request.

Nora wants to restore a workshop robot. The workshop defines the required part, budget and purchasing policy; a procurement agent compares the evidence. Follow their shared case through success, rejected terms, failed delivery, a failed check, partial acceptance or a deferred decision. Every exception retains its obligation and evidence.

This AX-14 simulation includes fictional authorisation, delivery, acceptance and payment records. Partial acceptance is a delivery/remedy state, not a partial order-book fill. The LA-02 offer comparison is a different example and stops at an unsigned proposal.

{
  "id": "WORKCELL-17-REPAIR-DEMO",
  "schemaVersion": "actuator-case/1",
  "revision": 1,
  "simulatedDate": "2026-10-21",
  "scenario": "success",
  "stage": "need",
  "status": "Nora reports a failed actuator. The workshop defines the repair need, permitted context and spending limit.",
  "brief": {
    "id": "BRIEF-WORKCELL-17",
    "version": 1,
    "objective": "Restore the fictional workcell to its documented motion test.",
    "quantity": 1,
    "spendCapCents": 30000,
    "requirements": "One AX-14 revision C compatible replacement for the XR-7 revision D motion axis; fit and commissioning checks must be recorded.",
    "disclosure": "Equipment model, revision, fault and purchasing constraints only. No worker identities or production logs.",
    "principalId": "WORKSHOP-DEMO",
    "policyId": "PURCHASING-POLICY-01-demo"
  },
  "asset": {
    "instanceId": "ROBOT-CELL17-01",
    "model": "Workshop Robot XR-7",
    "modelRevision": "D-demo",
    "installedPart": "Failed AX-14 revision B · instance AX14-B-0042"
  },
  "twin": {
    "id": "TWIN-ROBOT-CELL17-01",
    "version": 7,
    "represents": "ROBOT-CELL17-01"
  },
  "machine": {
    "model": "offer-reader-weights/1-demo",
    "instance": "RUN-PRIMARY-01",
    "provider": "PROVIDER-A-DEMO",
    "account": "PROCUREMENT-ACCOUNT-DEMO",
    "key": "PUBLIC-KEY-FINGERPRINT-DEMO",
    "operator": "WORKSHOP-DEMO",
    "configuration": "equipment-only/1-demo",
    "hardware": "CPU-host-demo",
    "license": "task-permitted-demo",
    "grant": {
      "id": "READ-COMPARE-DRAFT-01",
      "version": 1,
      "status": "current",
      "account": "PROCUREMENT-ACCOUNT-DEMO",
      "context": "Equipment, manual and exact offer only; no contacts or unrelated records.",
      "policy": "PRINCIPAL-RESOURCE-POLICY-1-demo"
    },
    "run": "ready",
    "replacement": "qualified",
    "qualification": {
      "task": "Passed the fictional offer-reading fixture; no operating benchmark.",
      "cost": "Same USD 0.20 per 100 synthetic units; total run cap USD 1.00.",
      "hardware": "Compatible with fixture CPU host.",
      "license": "Fictional license permits this task.",
      "security": "Same tool allowlist and equipment-only view.",
      "reproducibility": "Pinned demo weights, tool v1 and configuration v1."
    },
    "limits": {
      "units": 500,
      "costCents": 100
    },
    "usage": [],
    "review": "not-reviewed",
    "notice": "An approved fictional resource policy permits routine read/compare/draft operations within these limits, without a fresh human screen each time. It supplies no purchasing authority."
  },
  "offer": {
    "id": "MAKER-AX14-C-DEMO",
    "version": 1,
    "productModel": "AX-14 Linear Actuator",
    "productRevision": "C-demo",
    "makerId": "Fictional Workshop Motion Works",
    "termsVersion": "AX14-TERMS-1-demo",
    "validUntil": "2026-11-21",
    "fit": "documented-in-fixture",
    "stock": "fresh-in-fixture",
    "itemCents": 23000,
    "shippingCents": 1500,
    "taxCents": 2450,
    "platformFeeCents": 0,
    "serviceCents": 0,
    "totalCents": 26950,
    "allInKnown": true,
    "currency": "USD",
    "paymentTerms": "This fixture pays only after delivery, successful inspection and explicit acceptance. Other contracts can require another sequence.",
    "scope": "Fictional all-in quotation: one actuator, shipping and a synthetic tax amount. No platform fee or recurring service is selected. These are fixture terms, not Skyzai fee or tax policy."
  },
  "agent": {
    "id": "AGENT-PROCUREMENT-DEMO",
    "version": "1-demo",
    "toolVersion": "offer-reader/1-demo",
    "grantId": "READ-COMPARE-DRAFT-01",
    "allowedActions": [
      "read",
      "compare",
      "clarify",
      "stage_unsigned_proposal"
    ],
    "mayAuthorize": false,
    "maySign": false
  },
  "fitEvidenceVersion": 1,
  "proposal": null,
  "authority": null,
  "commitment": null,
  "delivery": "not-started",
  "inspection": "not-recorded",
  "acceptance": "not-accepted",
  "payment": "not-paid",
  "reconciliation": "not-reconciled",
  "correction": "none",
  "acceptanceScope": {
    "acceptedChecks": 0,
    "requiredChecks": 2,
    "unresolved": "Installation and motion checks await inspection and explicit customer acceptance."
  },
  "invoice": null,
  "processedEvents": [],
  "history": [
    {
      "revision": 1,
      "action": "need",
      "actor": "Nora and workshop · fictional",
      "detail": "Maintenance need and purpose-limited purchasing brief recorded."
    }
  ],
  "evidence": [
    {
      "id": "EVIDENCE-1",
      "revision": 1,
      "source": "Maintenance note · fictional",
      "detail": "XR-7 revision D, installed instance ROBOT-CELL17-01, failed AX14-B-0042. No real equipment inspected.",
      "status": "fictional-record"
    }
  ]
}

The existing LA-02 product twin and BLM-28 compatibility correction remain uncertain examples. The successful path uses a separate fictional AX-14 candidate with synthetic evidence. It does not qualify either existing product.

The proposed commission covers eligible completed sales, completed rentals and fulfilled service periods through Skyzai, under agreed terms. Sales and rentals completed elsewhere carry no Skyzai marketplace commission. Refundable deposits, wallet top-ups, internal record hops and bank transfers are not commission events. A reservation or renewal alone is not fulfilled service.

Define the fee base, payer, recipient and completion evidence before charging. The existing physical-sale proposal excludes shipping; rental bases, cancellations, partial service, refunds and reversals need explicit terms and fee-policy reconciliation. Rates remain unresolved. Refunded, credited or disputed amounts follow the accepted terms and the exact retained eligible amount. Routine return of the robot and repayment of a refundable deposit do not themselves reverse an accepted rental period.

Compute follows its own usage terms. Count provider expense, Skyzai service charge, any publisher premium and any marketplace fee once each; a robot rental creates no automatic cloud bill. Affiliate rewards share one funded campaign pool. Rental eligibility requires express campaign terms, not an assumed extension of the sale example. Unknown required costs prevent a complete payable total.

Later product or campaign changes must not rewrite the order’s pinned history. Duplicated events, reversals and refunds need explicit accounting. The service provider remains accountable for its accepted commitments.

Manufacturers can explore the current public partner room and the archived robotics pitch. These materials describe possible partnerships, not signed agreements or admitted suppliers.

The twin explains the product. The agreement records what the parties promised. Delivery, acceptance and payment record what happened. Keeping them linked lets you follow the whole journey and see what remains unresolved.

Payment can precede delivery; a delivery can be disputed; service can continue after a sale. Each record keeps its own identity, version, responsible party, permissions, retention and correction history.

An exact quote can be rejected. A commitment still needs fulfilment, explicit acceptance and its own invoice/payment records; partial or unresolved acceptance stays visible.