# Blueprints > A Blueprint is a ready-made company shape composed into a sandbox Product with one call. Each provisions a curated set of capabilities and business instruments, speaks its own vocabulary and SDK actions, and ships a guided setup journey. Composition never grants live access. Product Activation requires KYB approval, billing configuration, capability grants, live-readiness checks, and provider readiness where applicable. Blueprint composition targets sandbox, and live access is a separate gated request. Primitives Products provision capabilities directly instead. See [plans](plans.md) for pricing. Generated from the Hyperscale contract. ## Air Travel Agency Flight bookings held against itineraries, confirmed on carrier decisions, and unwound under void-window penalty schedules. A founder gets the settlement spine of a flight seller -- held bookings, carrier-decided confirmations, deadline-driven expiry, and quoted cancellations -- as one composed product with its own vocabulary and SDK. - Blueprint ID: `air-travel-agency` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, deposits, flight_booking, hotel_stay, identity, internal_transfers, payouts, products, travel_package, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.airTravelAgency` - Built on business instruments: flight_booking Business vocabulary: - **Itinerary** (`itinerary`): The flight the booking purchases, grounded on the versioned subject record. [grounded in the `subject` resource] - **Booking hold** (`booking_hold`): The free reservation window before payment; grounded on the flight booking state machine. [grounded in the `flight_booking` business instrument] - **Fare settlement** (`fare_settlement`): The ledger transfer settling the fare into the agency account on confirmation. [grounded in the `internal_transfer` resource] - **Cancellation quote** (`cancellation_quote`): The refund priced under the void-window penalty schedule before it executes. [grounded in the `flight_booking` business instrument] SDK actions: - `hyperscale.blueprints.airTravelAgency.registerItinerary()` -> `subject.create`: Register the flight itinerary a booking will purchase. - `hyperscale.blueprints.airTravelAgency.holdBooking()` -> `flight_booking.create`: Hold a flight booking against its itinerary with no money moved. - `hyperscale.blueprints.airTravelAgency.confirmBooking()` -> `flight_booking.confirm`: Confirm the booking through the carrier decision and settle the fare. - `hyperscale.blueprints.airTravelAgency.quoteCancellation()` -> `flight_booking.cancel_quote`: Quote the refund under the void-window penalty schedule. - `hyperscale.blueprints.airTravelAgency.confirmCancellation()` -> `flight_booking.cancel_confirm`: Execute the quoted cancellation refund to the traveler. Provider families: - Air Carrier (`air_carrier`): roadmap (not integrated; blocks the live surface). Blocked live until an air carrier or consolidator provider is integrated; live ticketing requires an accredited issuing seat. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - air_carrier_provider_integration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create traveler customers (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create traveler and agency accounts (`account.create`) 8. Fund the traveler wallet in sandbox (`sandbox.account.fund`) 9. Register the first itinerary (`subject.create`) 10. Hold the first booking (`flight_booking.create`) 11. Confirm the booking (`flight_booking.confirm`) 12. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Sell a flight: Hold the booking, confirm it through the carrier decision, and unwind a cancellation under the void window. - Register an itinerary: Register the flight itinerary as the versioned subject the booking refers to. - Onboard a traveler: Create the traveler and activate product access before the first hold. - Move fare funds: Reserve and post ledger transfers explicitly in sandbox to trace the fare leg. ## Asset-Backed Membership Member-owned watches listed, rented, exchanged, and sold under inspection deposits, collateral holds, and scheduled seller payouts. A membership founder gets an asset register, club enrollment, inspection deposits, rental holds, member exchanges, damage claims, and seller payout runs as one composed product speaking the club's own language. - Blueprint ID: `asset-backed-membership` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, claim, deposit_hold, deposits, escrow_order, identity, internal_transfers, listing, order, payout_run, payouts, policy, products, trade_settlement, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.assetBackedMembership` - Built on business instruments: deposit_hold, escrow_order, listing, order, claim, policy, payout_run, trade_settlement Business vocabulary: - **Member asset** (`member_asset`): A watch or collectible registered for club rental, exchange, or sale; grounded on the listing state machine. [grounded in the `listing` business instrument] - **Club membership** (`club_membership`): One member's active access to the club Product. [grounded in the `customer_access` resource] - **Inspection deposit** (`inspection_deposit`): Collateral held while a member inspects an asset, claimable against evidenced damage. [grounded in the `deposit_hold` business instrument] - **Rental hold** (`rental_hold`): The member's refundable security deposit for one asset rental. [grounded in the `escrow_order` business instrument] - **Member exchange** (`member_exchange`): A two-sided exchange between members whose cash legs fund before either asset changes hands. [grounded in the `trade_settlement` business instrument] - **Asset damage claim** (`asset_damage_claim`): An evidence-backed condition claim opened against a protected rental or exchange. [grounded in the `claim` business instrument] - **Seller payout run** (`seller_payout_run`): The scheduled batch that pays asset sellers after club fees and reversals settle. [grounded in the `payout_run` business instrument] SDK actions: - `hyperscale.blueprints.assetBackedMembership.registerMemberAsset()` -> `listing.create`: Register a member-owned watch or collectible with its declared condition. - `hyperscale.blueprints.assetBackedMembership.openInspectionDeposit()` -> `deposit_hold.create`: Open the refundable deposit that protects one asset inspection. - `hyperscale.blueprints.assetBackedMembership.openRentalHold()` -> `escrow_order.create`: Open the security hold for one member rental. - `hyperscale.blueprints.assetBackedMembership.openMemberExchange()` -> `trade_settlement.create`: Open a two-sided exchange between members. - `hyperscale.blueprints.assetBackedMembership.openAssetDamageClaim()` -> `claim.create`: Open an evidence-backed claim for asset damage. - `hyperscale.blueprints.assetBackedMembership.scheduleSellerPayoutRun()` -> `payout_run.create`: Schedule the next seller payout batch. Provider families: - Accounts & Ledger (first-party) (`accounts_ledger_first_party`): first-party (Hyperscale is the provider). First-party; no external provider readiness applies. Live money movement still gates on KYB and the product's own live capability grants. - Identity & Business Verification (`identity_verification`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the identity trust provider configured and its External Confirmation accepted. - Settlement Ingestion (pay-in) (`settlement_ingestion`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires a live collection account and the settlement provider integration configured. - Insurance Carrier (`insurance_carrier`): roadmap (not integrated; blocks the live surface). Blocked live until an insurance carrier provider is integrated; insurance binding is a regulated activity gated behind license review, and the reference Saudi marketplace additionally requires the distributor's own SAMA approval before it will serve the API at all. Quoting on that class is identity-full: the distributor demands national ID or Iqama, date of birth, and contact details before it prices, so a tenant holds regulated personal data from the first quote, not from binding. - Insurance Claims Adjuster (`insurance_claims_adjuster`): roadmap (not integrated; blocks the live surface). Blocked live until a claims-adjuster provider is integrated; claim payouts remain sandbox-only. A carrier with no adjudication API is served by the attest path on the claim instrument instead of this decision seam. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - provider_payout_configuration - insurance_carrier_provider_integration - insurance_claims_adjuster_provider_integration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Onboard members and sellers (`customer.create`) 5. Activate sandbox member bindings (`customer_access.activate`) 6. Create member, seller, and club accounts (`account.create`) 7. Register the first watch (`subject.create`) 8. Fund the member account in sandbox (`sandbox.account.fund`) 9. Register the first member asset (`listing.create`) 10. Open the first inspection deposit (`deposit_hold.create`) 11. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Acquire a member asset: Register the watch, place the buyer hold, and complete the sale to a member. - Settle an inspection deposit: Fund the inspection deposit, claim evidenced damage, and return the remainder. - Fund a member exchange: Fund and release the money legs that make a two-sided member exchange safe. - Protect a member asset: Bind cover for a member asset, assess an evidence-backed damage claim, and pay the approved amount. - Move member funds: Reserve and post one internal transfer so the club can reconcile its ledger movement. - Run seller payouts: Schedule the seller payout batch, apply its declared adjustments, and execute the net amount. ## B2B Trade Credit Wholesale invoicing on payment terms: approved counterparty limits, financed invoices collected on schedule, and a collections trail for what lapses. A founder gets the settlement spine of a trade-credit operation -- counterparty limits, financed terms invoices, dated delinquency, and a collections trail -- as one composed product with its own vocabulary and SDK. - Blueprint ID: `b2b-trade-credit` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, collections_case, contact_attempt, credit_agreement, deposits, exposure_arrangement, funding_commitment, funding_round, identity, installment, internal_transfers, payouts, products, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.b2bTradeCredit` - Built on business instruments: exposure_arrangement, credit_agreement, installment, collections_case, contact_attempt, funding_round, funding_commitment Business vocabulary: - **Trade limit** (`trade_limit`): The approved exposure cap for one buyer that every terms invoice is admitted against. [grounded in the `exposure_arrangement` business instrument] - **Terms invoice** (`terms_invoice`): One wholesale invoice financed on payment terms; grounded on the credit agreement state machine. [grounded in the `credit_agreement` business instrument] - **Terms payment** (`terms_payment`): One scheduled repayment of the invoice, collected on its date or marked overdue. [grounded in the `installment` business instrument] - **Recovery case** (`recovery_case`): The collections case a lapsed invoice hands off to, with its contact trail. [grounded in the `collections_case` business instrument] - **Contact attempt** (`contact_attempt`): One logged contact attempt inside a recovery case. [grounded in the `contact_attempt` business instrument] - **Supplier advance** (`supplier_advance`): The ledger transfer advancing the invoice principal to the supplier at shipment. [grounded in the `internal_transfer` resource] - **Funding round** (`funding_round`): The pooled funding round lenders commit into; grounded on the funding round state machine. [grounded in the `funding_round` business instrument] - **Funding commitment** (`funding_commitment`): An investor pledge committing capital into an open funding round. [grounded in the `funding_commitment` business instrument] SDK actions: - `hyperscale.blueprints.b2bTradeCredit.approveTradeLimit()` -> `exposure_arrangement.approve`: Approve the buyer's limit so invoices can be admitted under it. - `hyperscale.blueprints.b2bTradeCredit.openFundingRound()` -> `funding_round.create`: Open a pooled funding round for terms invoices. - `hyperscale.blueprints.b2bTradeCredit.pledgeToFundingRound()` -> `funding_commitment.create`: Pledge capital into an open funding round. - `hyperscale.blueprints.b2bTradeCredit.invoiceOnTerms()` -> `credit_agreement.create`: Open a terms invoice for a shipment under the buyer's limit. - `hyperscale.blueprints.b2bTradeCredit.advanceInvoice()` -> `credit_agreement.advance`: Advance the invoice principal to the supplier at shipment. - `hyperscale.blueprints.b2bTradeCredit.schedulePayment()` -> `installment.create`: Schedule one repayment installment for a terms invoice. - `hyperscale.blueprints.b2bTradeCredit.settleInvoice()` -> `credit_agreement.settle`: Settle the invoice once collected payments cover the principal. - `hyperscale.blueprints.b2bTradeCredit.openRecoveryCase()` -> `collections_case.create`: Open a collections case for a delinquent terms invoice. - `hyperscale.blueprints.b2bTradeCredit.logContactAttempt()` -> `contact_attempt.create`: Log a debtor contact attempt in a recovery case. - `hyperscale.blueprints.b2bTradeCredit.closeTradeLimit()` -> `exposure_arrangement.close`: Close a buyer's limit when the trading relationship ends. Provider families: - Accounts & Ledger (first-party) (`accounts_ledger_first_party`): first-party (Hyperscale is the provider). First-party; no external provider readiness applies. Live money movement still gates on KYB and the product's own live capability grants. - Settlement Ingestion (pay-in) (`settlement_ingestion`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires a live collection account and the settlement provider integration configured. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - provider_payout_configuration - lending_license_evidence Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create buyer customers (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create supplier, buyer, and funding accounts (`account.create`) 8. Fund the financing pool in sandbox (`sandbox.account.fund`) 9. Request the first trade limit (`exposure_arrangement.create`) 10. Approve the trade limit (`exposure_arrangement.approve`) 11. Open the first terms invoice (`credit_agreement.create`) 12. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Trade under a limit: Approve a buyer's limit, run an invoice referencing it through advance and settlement, and close the limit. - Settle a terms invoice: Open the invoice, advance the principal, collect the terms, and settle in full. - Hand off to collections: Open a recovery case over the lapsed invoice, record contact, and recover. - Raise the financing pool: Open a funding round, collect a commitment, and activate the raised pool. - Onboard a buyer: Create the buyer and activate product access before the first limit request. - Move advance funds: Reserve and post ledger transfers explicitly in sandbox to trace the advance leg. ## B2B Wholesale Marketplace Supplier catalogs sold on trade terms, purchase orders settled through escrow, and supplier payouts released on shipment. A founder gets the full settlement spine of a wholesale marketplace -- supplier catalogs, purchase-order escrow, trade-terms approval, shipment evidence, and supplier payouts -- as one composed product with its own vocabulary and SDK. - Blueprint ID: `b2b-wholesale-marketplace` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, deposits, escrow_order, identity, internal_transfers, listing, payouts, products, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.b2bWholesaleMarketplace` - Built on business instruments: escrow_order, listing Business vocabulary: - **Wholesale buyer** (`wholesale_buyer`): A retail or distribution business buying at trade pricing; grounded on the customer record. [grounded in the `customer` resource] - **Supplier catalog item** (`supplier_catalog_item`): A wholesale product a supplier offers for order; grounded on the listing state machine. [grounded in the `listing` business instrument] - **Purchase order** (`purchase_order`): A buyer's funded commitment to one wholesale order; grounded on the escrow order state machine. [grounded in the `escrow_order` business instrument] - **Trade terms** (`trade_terms`): The declared payment and delivery terms a purchase order must satisfy before release. [grounded in the `trust_requirement` resource] - **Shipment evidence** (`shipment_evidence`): Dispatch and delivery evidence attached to the order's trust file. [grounded in the `trust_evidence` resource] - **Supplier payout** (`supplier_payout`): The outbound settlement to the supplier once the purchase order releases. [grounded in the `payout` resource] SDK actions: - `hyperscale.blueprints.b2bWholesaleMarketplace.draftSupplierCatalogItem()` -> `listing.create`: Draft a wholesale product in the supplier catalog. - `hyperscale.blueprints.b2bWholesaleMarketplace.publishSupplierCatalogItem()` -> `listing.publish`: Publish a drafted wholesale product to the supplier catalog. - `hyperscale.blueprints.b2bWholesaleMarketplace.createWholesaleOrder()` -> `escrow_order.create`: Open a purchase order for a buyer against supplier catalog items. - `hyperscale.blueprints.b2bWholesaleMarketplace.fundWholesaleOrder()` -> `escrow_order.fund`: Fund a purchase order into escrow. - `hyperscale.blueprints.b2bWholesaleMarketplace.reserveWholesaleOrder()` -> `listing.reserve`: Reserve a supplier catalog item against a funded purchase order. - `hyperscale.blueprints.b2bWholesaleMarketplace.completeWholesaleSale()` -> `listing.sell`: Complete the wholesale sale for a reserved catalog item. - `hyperscale.blueprints.b2bWholesaleMarketplace.approveTradeTerms()` -> `trust_requirement.respond`: Respond to the order's trade-terms requirement with agreed terms. - `hyperscale.blueprints.b2bWholesaleMarketplace.splitSupplierPayout()` -> `escrow_order.release`: Release the escrowed purchase order to the supplier when the shipment lands. Provider families: - Accounts & Ledger (first-party) (`accounts_ledger_first_party`): first-party (Hyperscale is the provider). First-party; no external provider readiness applies. Live money movement still gates on KYB and the product's own live capability grants. - Settlement Ingestion (pay-in) (`settlement_ingestion`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires a live collection account and the settlement provider integration configured. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - provider_payout_configuration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create buyer and supplier customers (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create buyer and supplier accounts (`account.create`) 8. Fund the buyer wallet in sandbox (`sandbox.account.fund`) 9. Draft the first supplier catalog item (`listing.create`) 10. Publish the supplier catalog item (`listing.publish`) 11. Open the first purchase order (`escrow_order.create`) 12. Fund the purchase order into escrow (`escrow_order.fund`) 13. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Sell a catalog item: Publish the supplier catalog item, reserve it against a purchase order, and complete the wholesale sale. - Settle a purchase order: Open the purchase order, fund it into escrow, reserve its catalog item, and release the escrow to the supplier. - Pay a supplier: Verify the supplier beneficiary and follow the payout through processing and completion. - Onboard buyer and supplier: Create both trading counterparties and activate their product access before the first order. - Move order funds: Reserve and post the purchase order's ledger transfers explicitly in sandbox. ## BNPL Checkout Pay-later purchase plans advanced at checkout, collected back as a declared installment schedule with honest delinquency and collections handoff. A founder gets the settlement spine of a BNPL company -- advanced principal, declared schedules, overdue tracking, and a collections trail -- as one composed product with its own vocabulary and SDK, without building a lending ledger. - Blueprint ID: `bnpl-checkout` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, collections_case, contact_attempt, credit_agreement, deposits, exposure_arrangement, funding_commitment, funding_round, identity, installment, internal_transfers, payouts, products, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.bnplCheckout` - Built on business instruments: credit_agreement, installment, exposure_arrangement, collections_case, contact_attempt, funding_round, funding_commitment Business vocabulary: - **Purchase plan** (`purchase_plan`): The shopper's pay-later purchase; grounded on the credit agreement state machine. [grounded in the `credit_agreement` business instrument] - **Plan payment** (`plan_payment`): One scheduled repayment of the plan, collected on its date or marked overdue. [grounded in the `installment` business instrument] - **Spending limit** (`spending_limit`): The approved exposure cap every new plan is admitted against. [grounded in the `exposure_arrangement` business instrument] - **Recovery case** (`recovery_case`): The collections case a delinquent plan hands off to, with its contact trail. [grounded in the `collections_case` business instrument] - **Contact attempt** (`contact_attempt`): One logged customer contact attempt inside a recovery case. [grounded in the `contact_attempt` business instrument] - **Merchant disbursement** (`merchant_disbursement`): The ledger transfer advancing the purchase principal to the merchant. [grounded in the `internal_transfer` resource] - **Funding round** (`funding_round`): The pooled funding round lenders commit into; grounded on the funding round state machine. [grounded in the `funding_round` business instrument] - **Funding commitment** (`funding_commitment`): An investor pledge committing capital into an open funding round. [grounded in the `funding_commitment` business instrument] SDK actions: - `hyperscale.blueprints.bnplCheckout.openFundingRound()` -> `funding_round.create`: Open a pooled funding round for merchant financing. - `hyperscale.blueprints.bnplCheckout.pledgeToFundingRound()` -> `funding_commitment.create`: Pledge capital into an open funding round. - `hyperscale.blueprints.bnplCheckout.openPurchasePlan()` -> `credit_agreement.create`: Open a pay-later purchase plan for a shopper's checkout. - `hyperscale.blueprints.bnplCheckout.disbursePrincipal()` -> `credit_agreement.advance`: Advance the purchase principal to the merchant from the funding pool. - `hyperscale.blueprints.bnplCheckout.schedulePayment()` -> `installment.create`: Declare one repayment of the plan with its due date and amount. - `hyperscale.blueprints.bnplCheckout.settlePlan()` -> `credit_agreement.settle`: Settle the plan once collected repayments cover the principal. - `hyperscale.blueprints.bnplCheckout.openRecoveryCase()` -> `collections_case.create`: Hand a delinquent balance off to a collections case. - `hyperscale.blueprints.bnplCheckout.logContactAttempt()` -> `contact_attempt.create`: Log a customer contact attempt in a recovery case. Provider families: - Accounts & Ledger (first-party) (`accounts_ledger_first_party`): first-party (Hyperscale is the provider). First-party; no external provider readiness applies. Live money movement still gates on KYB and the product's own live capability grants. - Settlement Ingestion (pay-in) (`settlement_ingestion`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires a live collection account and the settlement provider integration configured. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - provider_payout_configuration - lending_license_evidence Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create shopper customers (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create shopper, merchant, and funding accounts (`account.create`) 8. Fund the funding pool in sandbox (`sandbox.account.fund`) 9. Open the first purchase plan (`credit_agreement.create`) 10. Advance the principal to the merchant (`credit_agreement.advance`) 11. Schedule the first payment (`installment.create`) 12. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Advance and settle a plan: Open the plan, advance the principal, collect the schedule, and settle in full. - Recover an overdue payment: Mark a lapsed payment overdue on its date and collect the late repayment. - Hand off to collections: Open a recovery case over the delinquent balance, record contact, and recover. - Approve a spending limit: Approve the shopper's spending limit, then run a plan referencing it end to end. - Raise the funding pool: Open a funding round, collect a commitment, and activate the raised pool. - Onboard a shopper: Create the shopper and activate product access before the first plan. - Move principal funds: Reserve and post ledger transfers explicitly in sandbox to trace the advance leg. ## Closed-Loop Wallet Member balances in dedicated ledger accounts: receipt-backed loads, limit-admitted spends, freeze as the guardian control, and honest cash-out. A founder gets the settlement spine of a stored-value program -- provisioned member accounts, limit-admitted spends, guardian freeze, and honest cash-out -- as one composed product with its own vocabulary and SDK. - Blueprint ID: `closed-loop-wallet` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, deposits, identity, internal_transfers, payouts, products, usage, verification, wallet, wallet_spend, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.closedLoopWallet` - Built on business instruments: wallet, wallet_spend Business vocabulary: - **Member balance** (`member_balance`): The member's stored balance in its dedicated ledger account; grounded on the wallet state machine. [grounded in the `wallet` business instrument] - **Balance load** (`balance_load`): The top-up transfer crediting the balance from the member's funding source. [grounded in the `internal_transfer` resource] - **Member spend** (`member_spend`): One spend from the balance to the venue, admitted against the declared limit. [grounded in the `wallet_spend` business instrument] SDK actions: - `hyperscale.blueprints.closedLoopWallet.openMemberBalance()` -> `wallet.create`: Provision a member's balance with its dedicated ledger account and declared limit. - `hyperscale.blueprints.closedLoopWallet.activateMemberBalance()` -> `wallet.activate`: Activate the balance so loads and spends are admitted. - `hyperscale.blueprints.closedLoopWallet.loadBalance()` -> `wallet.topup`: Load the balance from the member's funding source as a receipt-backed transfer. - `hyperscale.blueprints.closedLoopWallet.recordSpend()` -> `wallet_spend.create`: Record a spend against the balance, admitted under the declared limit. - `hyperscale.blueprints.closedLoopWallet.postSpend()` -> `wallet_spend.post`: Post the spend, settling it as a statement line. - `hyperscale.blueprints.closedLoopWallet.refundSpend()` -> `wallet_spend.refund`: Refund a posted spend back to the balance. - `hyperscale.blueprints.closedLoopWallet.freezeBalance()` -> `wallet.freeze`: Freeze the balance so no spend can move money. - `hyperscale.blueprints.closedLoopWallet.withdrawBalance()` -> `wallet.withdraw`: Withdraw the remaining balance back to the member honestly. Provider families: - Accounts & Ledger (first-party) (`accounts_ledger_first_party`): first-party (Hyperscale is the provider). First-party; no external provider readiness applies. Live money movement still gates on KYB and the product's own live capability grants. - Settlement Ingestion (pay-in) (`settlement_ingestion`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires a live collection account and the settlement provider integration configured. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - provider_payout_configuration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create member customers (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create member and venue accounts (`account.create`) 8. Fund the member's source in sandbox (`sandbox.account.fund`) 9. Open the first member balance (`wallet.create`) 10. Activate the balance (`wallet.activate`) 11. Load the first balance (`wallet.topup`) 12. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Load and spend a balance: Open and activate the balance, load it, post a spend under the limit, and withdraw the rest. - Reload a balance: Open and activate a member balance, load it, then withdraw the balance. - Onboard a member: Create the member and activate product access before the first load. - Move load funds: Reserve and post ledger transfers explicitly in sandbox to trace the load leg. ## Creator Payouts & Tax Docs Creator earnings ledgered per event, beneficiaries verified, and payouts created with tax reviews on file. A payouts founder gets creator onboarding, per-event earnings ledgers, beneficiary verification, creator payouts, and tax-document reviews as one composed product with its own vocabulary and SDK. - Blueprint ID: `creator-payouts-tax-docs` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, deposits, identity, internal_transfers, payout_run, payouts, products, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.creatorPayoutsTaxDocs` - Built on business instruments: payout_run Business vocabulary: - **Creator account** (`creator_account`): A creator onboarded for payouts; grounded on the first-party customer record. [grounded in the `customer` resource] - **Earnings event** (`earnings_event`): One earned amount posted to a creator's ledger; grounded on the internal transfer record. [grounded in the `internal_transfer` resource] - **Creator payout** (`creator_payout`): Money sent to one verified creator; grounded on the payout record. [grounded in the `payout` resource] - **Tax profile** (`tax_profile`): The creator's tax-documentation review, opened before payouts run; grounded on the trust review record. [grounded in the `trust_review` resource] - **Withholding rule** (`withholding_rule`): A declared withholding requirement the tax profile must satisfy; grounded on the trust requirement record. [grounded in the `trust_requirement` resource] - **Payout receipt** (`payout_receipt`): The receipt-backed record of one completed payout instruction. [grounded in the `receipt` resource] SDK actions: - `hyperscale.blueprints.creatorPayoutsTaxDocs.onboardCreator()` -> `customer.create`: Onboard a creator as a payout-ready customer. - `hyperscale.blueprints.creatorPayoutsTaxDocs.recordEarningsEvent()` -> `internal_transfer.create`: Post one earnings event to the creator's ledger account. - `hyperscale.blueprints.creatorPayoutsTaxDocs.createCreatorPayout()` -> `payout.create`: Create a payout for a verified creator. - `hyperscale.blueprints.creatorPayoutsTaxDocs.applyWithholdingRule()` -> `trust_requirement.respond`: Respond to the creator's declared withholding requirement on the tax profile. Provider families: - Identity & Business Verification (`identity_verification`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the identity trust provider configured and its External Confirmation accepted. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - provider_payout_configuration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Onboard your first creator (`customer.create`) 5. Enroll creators into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create platform and creator ledger accounts (`account.create`) 8. Fund the platform float in sandbox (`sandbox.account.fund`) 9. Post the first earnings event (`internal_transfer.create`) 10. Open the creator's tax profile review (`trust_review.create`) 11. Create the creator's payout beneficiary (`beneficiary.create`) 12. Schedule the creator's first payout run (`payout_run.create`) 13. Create the first creator payout (`payout.create`) 14. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Onboard a creator: Create the creator, enroll them into the product, and activate their payout access. - Run a disbursement cycle: Schedule the creator's payout run, settle declared withholding, and let the net amount execute into payout funding on schedule. - Create a creator payout: Verify the beneficiary, accept it at the sandbox sponsor bank, then create a funded payout for the creator. - Ledger an earnings cycle: Reserve and post earnings transfers into the creator's ledger explicitly in sandbox. - Register the payout organization: Create the organization customer record that owns the payout program. ## Digital Savings Circles The jam'iya as contract machinery: formed circles, enrolled members, collected contributions, and the rotating pot paid on schedule. A founder gets the settlement spine of a savings-circle platform -- formation, enrollment, collected contributions, and rotating pot payouts -- as one composed product with its own vocabulary and SDK. - Blueprint ID: `digital-savings-circles` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, circle_membership, deposits, identity, internal_transfers, payouts, products, savings_circle, usage, verification, wallet, wallet_spend, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.digitalSavingsCircles` - Built on business instruments: savings_circle, circle_membership, wallet, wallet_spend Business vocabulary: - **Circle** (`circle`): One rotating savings circle with its declared contribution and rotation order. [grounded in the `savings_circle` business instrument] - **Circle seat** (`circle_seat`): One member's seat in the rotation, with their contribution and pot turn. [grounded in the `circle_membership` business instrument] - **Member balance** (`member_balance`): The member's stored balance operated alongside the circles; contributions draw from the member's declared funding account. [grounded in the `wallet` business instrument] - **Wallet spend** (`wallet_spend`): One authorized spend out of a member's wallet balance. [grounded in the `wallet_spend` business instrument] - **Pot payout** (`pot_payout`): The ledger transfer paying the full round pot to that rotation's member. [grounded in the `internal_transfer` resource] SDK actions: - `hyperscale.blueprints.digitalSavingsCircles.formCircle()` -> `savings_circle.create`: Form a circle with its declared contribution amount and rotation order. - `hyperscale.blueprints.digitalSavingsCircles.joinCircle()` -> `circle_membership.create`: Enroll a member into a seat in the forming circle. - `hyperscale.blueprints.digitalSavingsCircles.openMemberBalance()` -> `wallet.create`: Provision a member balance before joining a circle. - `hyperscale.blueprints.digitalSavingsCircles.spendFromWallet()` -> `wallet_spend.create`: Authorize a spend from a member wallet balance. - `hyperscale.blueprints.digitalSavingsCircles.completeCircle()` -> `savings_circle.close`: Close the circle once the final rotation has paid out. Provider families: - Accounts & Ledger (first-party) (`accounts_ledger_first_party`): first-party (Hyperscale is the provider). First-party; no external provider readiness applies. Live money movement still gates on KYB and the product's own live capability grants. - Settlement Ingestion (pay-in) (`settlement_ingestion`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires a live collection account and the settlement provider integration configured. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - provider_payout_configuration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create member customers (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create member and circle accounts (`account.create`) 8. Fund member sources in sandbox (`sandbox.account.fund`) 9. Form the first circle (`savings_circle.create`) 10. Enroll the first members (`circle_membership.create`) 11. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Run a rotation: Form the circle, enroll a member, launch, collect the contribution, and pay the pot. - Run a member balance: Load a member balance, post a spend under its limit, and withdraw the rest. - Onboard a member: Create the member and activate product access before the first seat. - Move pot funds: Reserve and post ledger transfers explicitly in sandbox to trace the pot leg. ## Dream Trip Packages Curated trips sold as one package whose flights, stays, and protection confirm together, financed in installments when the traveler wants them. A founder gets a tour operator, an embedded insurer, and a consumer lender in one composed product -- all-or-nothing package confirmation over independent legs, same-trip protection, and installment financing -- with one vocabulary and SDK. - Blueprint ID: `dream-trip-packages` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, claim, collections_case, contact_attempt, credit_agreement, deposits, exposure_arrangement, flight_booking, funding_commitment, funding_round, hotel_stay, identity, installment, internal_transfers, payouts, policy, products, travel_package, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.dreamTripPackages` - Built on business instruments: travel_package, flight_booking, hotel_stay, policy, claim, credit_agreement, installment, collections_case, contact_attempt Business vocabulary: - **Trip package** (`trip_package`): The curated trip the traveler buys as one product; grounded on the travel package state machine. [grounded in the `travel_package` business instrument] - **Package flight** (`package_flight`): One flight leg inside the package, holding and confirming through the carrier decision. [grounded in the `flight_booking` business instrument] - **Package stay** (`package_stay`): One lodging leg inside the package, holding and confirming through the supplier decision. [grounded in the `hotel_stay` business instrument] - **Trip protection** (`trip_protection`): Protection bound over the packaged trip; grounded on the policy state machine. [grounded in the `policy` business instrument] - **Disruption claim** (`disruption_claim`): A covered disruption filed against the trip protection; grounded on the claim state machine. [grounded in the `claim` business instrument] - **Payment plan** (`payment_plan`): The traveler's financing for a packaged trip; grounded on the credit agreement state machine. [grounded in the `credit_agreement` business instrument] - **Plan installment** (`plan_installment`): One scheduled repayment of the payment plan, collected on its date. [grounded in the `installment` business instrument] - **Trip recovery case** (`recovery_case`): The collections file opened over a missed plan installment. [grounded in the `collections_case` business instrument] - **Recovery contact** (`recovery_contact`): One logged traveler contact inside a trip recovery case. [grounded in the `contact_attempt` business instrument] SDK actions: - `hyperscale.blueprints.dreamTripPackages.draftPackage()` -> `travel_package.create`: Draft the packaged trip the legs will attach to. - `hyperscale.blueprints.dreamTripPackages.holdPackageFlight()` -> `flight_booking.create`: Hold a flight leg inside the package. - `hyperscale.blueprints.dreamTripPackages.holdPackageStay()` -> `hotel_stay.create`: Hold a lodging leg inside the package. - `hyperscale.blueprints.dreamTripPackages.confirmPackage()` -> `travel_package.confirm`: Confirm the package once every leg has confirmed. - `hyperscale.blueprints.dreamTripPackages.cancelPackage()` -> `travel_package.cancel`: Cancel the package and cascade full refunds across its legs. - `hyperscale.blueprints.dreamTripPackages.completeTrip()` -> `travel_package.complete`: Complete the package after the trip runs. - `hyperscale.blueprints.dreamTripPackages.quoteTripProtection()` -> `policy.create`: Quote travel protection for the trip package. - `hyperscale.blueprints.dreamTripPackages.bindTripProtection()` -> `policy.bind`: Bind protection over the packaged trip. - `hyperscale.blueprints.dreamTripPackages.fileDisruptionClaim()` -> `claim.create`: File a covered disruption against the trip protection. - `hyperscale.blueprints.dreamTripPackages.openPaymentPlan()` -> `credit_agreement.create`: Open installment financing for the packaged trip. - `hyperscale.blueprints.dreamTripPackages.advancePaymentPlan()` -> `credit_agreement.advance`: Advance the financed trip amount to the traveler. - `hyperscale.blueprints.dreamTripPackages.scheduleInstallment()` -> `installment.create`: Schedule one repayment of the payment plan. - `hyperscale.blueprints.dreamTripPackages.openTripRecoveryCase()` -> `collections_case.create`: Open a recovery case over a missed plan installment. - `hyperscale.blueprints.dreamTripPackages.assignTripRecoveryCase()` -> `collections_case.assign`: Assign a trip recovery case to a collections agency. - `hyperscale.blueprints.dreamTripPackages.recordRecoveryContact()` -> `contact_attempt.create`: Record one traveler contact in the recovery case. - `hyperscale.blueprints.dreamTripPackages.recoverMissedPayment()` -> `collections_case.recover`: Recover a missed installment into the payment plan. Provider families: - Accounts & Ledger (first-party) (`accounts_ledger_first_party`): first-party (Hyperscale is the provider). First-party; no external provider readiness applies. Live money movement still gates on KYB and the product's own live capability grants. - Settlement Ingestion (pay-in) (`settlement_ingestion`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires a live collection account and the settlement provider integration configured. - Air Carrier (`air_carrier`): roadmap (not integrated; blocks the live surface). Blocked live until an air carrier or consolidator provider is integrated; live ticketing requires an accredited issuing seat. - Lodging Supplier (`lodging_supplier`): roadmap (not integrated; blocks the live surface). Blocked live until a lodging supply provider is integrated. - Insurance Carrier (`insurance_carrier`): roadmap (not integrated; blocks the live surface). Blocked live until an insurance carrier provider is integrated; insurance binding is a regulated activity gated behind license review, and the reference Saudi marketplace additionally requires the distributor's own SAMA approval before it will serve the API at all. Quoting on that class is identity-full: the distributor demands national ID or Iqama, date of birth, and contact details before it prices, so a tenant holds regulated personal data from the first quote, not from binding. - Insurance Claims Adjuster (`insurance_claims_adjuster`): roadmap (not integrated; blocks the live surface). Blocked live until a claims-adjuster provider is integrated; claim payouts remain sandbox-only. A carrier with no adjudication API is served by the attest path on the claim instrument instead of this decision seam. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - collection_account_configured - provider_configuration - provider_payout_configuration - lending_license_evidence - air_carrier_provider_integration - lodging_supplier_provider_integration - insurance_carrier_provider_integration - insurance_claims_adjuster_provider_integration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create traveler customers (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create traveler, operator, and supplier accounts (`account.create`) 8. Fund the traveler wallet in sandbox (`sandbox.account.fund`) 9. Draft the first trip package (`travel_package.create`) 10. Hold its flight leg (`flight_booking.create`) 11. Hold its stay leg (`hotel_stay.create`) 12. Quote trip protection over the trip (`policy.create`) 13. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Sell a package to departure: Draft the package, hold and confirm both legs, confirm the package once every leg agrees, and complete it after the trip. - Run a flight leg: Hold and confirm the flight leg, then unwind a cancellation under the void window. - Run a stay leg: Hold and confirm the lodging leg, then unwind a cancellation under the free-cancel window. - Settle a disruption claim: Bind protection over the packaged trip, file a covered event, and settle the payout. - Finance a trip: Open the payment plan, advance it, schedule installments, and settle after the last collection. - Hand off a missed payment: Open a recovery case over a missed installment, record contact, and recover the payment into the plan. - Onboard a traveler: Create the traveler and activate product access before the first draft. - Move trip funds: Reserve and post one trip-fund transfer explicitly in sandbox. ## Embedded Asset Protection Coverage certificates attached to protected assets at checkout, with incident claims settled through a declared lifecycle. A founder gets an embedded-protection program -- registered assets, bound coverage certificates, evidence-backed incident claims, and replacement payouts -- as one composed product speaking the protection trade's language. - Blueprint ID: `embedded-asset-protection` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, claim, deposits, identity, internal_transfers, payouts, policy, products, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.embeddedAssetProtection` - Built on business instruments: policy, claim Business vocabulary: - **Protected asset** (`protected_asset`): The covered item under protection, grounded on the versioned subject record. [grounded in the `subject` resource] - **Coverage certificate** (`coverage_certificate`): The protection terms bound against one asset; grounded on the policy state machine. [grounded in the `policy` business instrument] - **Incident report** (`incident_report`): The customer's damage or loss report attached to the claim's trust file. [grounded in the `trust_evidence` resource] - **Repair estimate** (`repair_estimate`): The repairer's costed estimate backing the claim decision. [grounded in the `trust_evidence` resource] - **Replacement payout** (`replacement_payout`): The ledger transfer that settles an approved claim as repair or replacement value. [grounded in the `internal_transfer` resource] SDK actions: - `hyperscale.blueprints.embeddedAssetProtection.registerProtectedAsset()` -> `subject.create`: Register a covered item as a protected asset. - `hyperscale.blueprints.embeddedAssetProtection.attachAssetCoverage()` -> `policy.bind`: Bind a coverage certificate against a protected asset. - `hyperscale.blueprints.embeddedAssetProtection.submitIncidentReport()` -> `claim.create`: Open a claim from a customer's incident report. - `hyperscale.blueprints.embeddedAssetProtection.approveReplacementPayout()` -> `claim.pay`: Settle the approved claim as a replacement payout. Provider families: - Insurance Carrier (`insurance_carrier`): roadmap (not integrated; blocks the live surface). Blocked live until an insurance carrier provider is integrated; insurance binding is a regulated activity gated behind license review, and the reference Saudi marketplace additionally requires the distributor's own SAMA approval before it will serve the API at all. Quoting on that class is identity-full: the distributor demands national ID or Iqama, date of birth, and contact details before it prices, so a tenant holds regulated personal data from the first quote, not from binding. - Insurance Claims Adjuster (`insurance_claims_adjuster`): roadmap (not integrated; blocks the live surface). Blocked live until a claims-adjuster provider is integrated; claim payouts remain sandbox-only. A carrier with no adjudication API is served by the attest path on the claim instrument instead of this decision seam. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - insurance_carrier_provider_integration - insurance_claims_adjuster_provider_integration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create covered customers (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create customer and claims accounts (`account.create`) 8. Fund the customer wallet in sandbox (`sandbox.account.fund`) 9. Register the first protected asset (`subject.create`) 10. Quote the first coverage certificate (`policy.create`) 11. Bind coverage against the asset (`policy.bind`) 12. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Settle an incident claim: Bind the coverage certificate, open the claim from an incident report, and settle the replacement payout. - Track a protected asset: Register the protected asset as the versioned subject the coverage refers to. - Onboard a covered customer: Create the customer and activate product access before attaching coverage. - Move claim funds: Reserve and post the replacement payout's ledger transfers explicitly in sandbox. - Void a payout hold: Reserve and void a replacement-payout hold before it posts. ## Escrow Marketplace Sandbox Buyer wallet, seller wallet, escrow account, address, transfer. The reference escrow marketplace: the archetype demo every escrow-family showcase specializes. - Blueprint ID: `escrow_marketplace_sandbox` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, deposit_hold, deposits, escrow_order, identity, internal_transfers, listing, order, payouts, products, trade_settlement, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.escrowMarketplaceSandbox` - Built on business instruments: deposit_hold, escrow_order, listing, order, trade_settlement Provider families: - Accounts & Ledger (first-party) (`accounts_ledger_first_party`): first-party (Hyperscale is the provider). First-party; no external provider readiness applies. Live money movement still gates on KYB and the product's own live capability grants. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create buyer and seller customers (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create buyer and seller accounts (`account.create`) 8. Issue buyer financial address (`financial_address.create`) 9. Fund buyer wallet in sandbox (`sandbox.account.fund`) 10. Reserve buyer funds into escrow (`internal_transfer.reserve`) 11. Post escrow reserve (`internal_transfer.post`) 12. Transfer buyer funds into escrow (`internal_transfer.create`) 13. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Sell a listing: Create a listing, reserve it while the buyer's escrow order holds funds, and complete the sale. - Claim part of a deposit hold: Create and fund a time-bounded deposit hold, then claim part and return the remainder. - Settle an escrow order: Open, fund, and release an escrow order between a buyer and a seller. - Open buyer funding address: Create the buyer account, then issue its funding address before marketplace money movement. - Move escrow funds: Reserve and post explicit transfers in the escrow sandbox. - Cancel escrow reserve: Reserve and void an escrow transfer before handover. ## Fractional Art Shares A gallery lists an artwork, one buyer escrows the full asking price, the operator marks the artwork sold, and settlement releases the escrow to the seller. A founder gets a gallery, an escrow agent, and a transfer registrar in one composed product: provenance-backed artworks, one-buyer full-price escrow orders, and ledger settlements that back every leg with receipts. - Blueprint ID: `fractional-art-shares` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, deposits, escrow_order, identity, internal_transfers, listing, order, payouts, products, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.fractionalArtShares` - Built on business instruments: escrow_order, listing, order Business vocabulary: - **Artwork** (`artwork`): The physical work an offering lists, grounded on the versioned subject record. [grounded in the `subject` resource] - **Share offering** (`share_offering`): The offering listing for one artwork at an asking price; grounded on the marketplace listing state machine. [grounded in the `listing` business instrument] - **Share subscription** (`share_subscription`): One buyer's full-price escrow purchase for the offering; grounded on the escrow order state machine. [grounded in the `escrow_order` business instrument] - **Provenance record** (`provenance_record`): Authenticity and ownership evidence attached to the artwork subject. [grounded in the `trust_evidence` resource] - **Seller settlement** (`seller_settlement`): The ledger transfer paying the seller out of the released full-price escrow. [grounded in the `internal_transfer` resource] SDK actions: - `hyperscale.blueprints.fractionalArtShares.registerArtwork()` -> `subject.create`: Register the artwork an offering lists. - `hyperscale.blueprints.fractionalArtShares.openShareOffering()` -> `listing.create`: Open an offering listing over the registered artwork at its declared asking price. - `hyperscale.blueprints.fractionalArtShares.publishShareOffering()` -> `listing.publish`: Publish the draft share offering so buyers can open escrow against it. - `hyperscale.blueprints.fractionalArtShares.subscribeShares()` -> `escrow_order.create`: Open full-price escrow for one buyer against the active offering. - `hyperscale.blueprints.fractionalArtShares.fundShareSubscription()` -> `escrow_order.fund`: Fund the buyer escrow for the full asking price. - `hyperscale.blueprints.fractionalArtShares.reserveShareOffering()` -> `listing.reserve`: Reserve the share offering against the buyer's funded escrow order. - `hyperscale.blueprints.fractionalArtShares.recordShareAgreement()` -> `order.create`: Record the buyer purchase agreement against the offering and escrow order. - `hyperscale.blueprints.fractionalArtShares.settleOffering()` -> `escrow_order.release`: Release the buyer's full-price escrow to the seller after the offering is marked sold. - `hyperscale.blueprints.fractionalArtShares.liquidateArtwork()` -> `listing.sell`: Mark the artwork sold and close the offering while its matching escrow holds the full asking price. Settle the escrow afterward. Provider families: - Accounts & Ledger (first-party) (`accounts_ledger_first_party`): first-party (Hyperscale is the provider). First-party; no external provider readiness applies. Live money movement still gates on KYB and the product's own live capability grants. - Identity & Business Verification (`identity_verification`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the identity trust provider configured and its External Confirmation accepted. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - provider_payout_configuration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create buyer customer (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create seller, buyer, and proceeds accounts (`account.create`) 8. Fund buyer wallet in sandbox (`sandbox.account.fund`) 9. Register the first artwork (`subject.create`) 10. Attach its provenance evidence (`trust_evidence.attach`) 11. Open the offering listing (`listing.create`) 12. Publish the offering listing (`listing.publish`) 13. Open full-price buyer escrow (`escrow_order.create`) 14. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Sell an artwork offering: Publish the offering over the registered artwork, reserve it against one buyer's funded full-price escrow, mark the artwork sold, then release funds to the seller. - Settle a buyer full-price escrow: Open full-price escrow for one buyer, fund it, reserve the offering, mark the artwork sold, and release the escrow to the seller. - Register an artwork: Register the work every offering, buyer escrow, and provenance record references. - Onboard a buyer: Create the buyer customer and activate product access before opening escrow. - Move offering funds: Reserve and post one offering-fund transfer explicitly in sandbox. - Void a reserved transfer: Reserve a transfer and void it before posting to see the cancel path on the same ledger. ## Hotel Booking Platform Hotel stays held against lodging subjects, confirmed on supplier decisions, and unwound under free-cancel penalty schedules. A founder gets the settlement spine of a lodging marketplace -- held stays, supplier-decided confirmations, deadline-driven expiry, and quoted cancellations -- as one composed product with its own vocabulary and SDK. - Blueprint ID: `hotel-booking-platform` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, deposits, flight_booking, hotel_stay, identity, internal_transfers, payouts, products, travel_package, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.hotelBookingPlatform` - Built on business instruments: hotel_stay Business vocabulary: - **Stay record** (`stay_record`): The property stay the booking purchases, grounded on the versioned subject record. [grounded in the `subject` resource] - **Stay hold** (`stay_hold`): The free reservation window before payment; grounded on the hotel stay state machine. [grounded in the `hotel_stay` business instrument] - **Rate settlement** (`rate_settlement`): The ledger transfer settling the rate into the property account on confirmation. [grounded in the `internal_transfer` resource] - **Cancellation quote** (`cancellation_quote`): The refund priced under the free-cancel penalty schedule before it executes. [grounded in the `hotel_stay` business instrument] SDK actions: - `hyperscale.blueprints.hotelBookingPlatform.registerStay()` -> `subject.create`: Register the lodging stay a booking will purchase. - `hyperscale.blueprints.hotelBookingPlatform.holdStay()` -> `hotel_stay.create`: Hold a hotel stay against its property with no money moved. - `hyperscale.blueprints.hotelBookingPlatform.confirmStay()` -> `hotel_stay.confirm`: Confirm the stay through the supplier decision and settle the rate. - `hyperscale.blueprints.hotelBookingPlatform.quoteCancellation()` -> `hotel_stay.cancel_quote`: Quote the refund under the free-cancel penalty schedule. - `hyperscale.blueprints.hotelBookingPlatform.confirmCancellation()` -> `hotel_stay.cancel_confirm`: Execute the quoted cancellation refund to the guest. Provider families: - Lodging Supplier (`lodging_supplier`): roadmap (not integrated; blocks the live surface). Blocked live until a lodging supply provider is integrated. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - lodging_supplier_provider_integration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create guest customers (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create guest and property accounts (`account.create`) 8. Fund the guest wallet in sandbox (`sandbox.account.fund`) 9. Register the first stay (`subject.create`) 10. Hold the first stay (`hotel_stay.create`) 11. Confirm the stay (`hotel_stay.confirm`) 12. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Sell a stay: Hold the stay, confirm it through the supplier decision, and unwind a cancellation under the free-cancel window. - Register a stay: Register the lodging stay as the versioned subject the booking refers to. - Onboard a guest: Create the guest and activate product access before the first hold. - Move rate funds: Reserve and post ledger transfers explicitly in sandbox to trace the rate leg. ## Insured Travel Marketplace Flights and stays sold side by side with embedded trip protection bound over the same itinerary and lodging subjects. A founder gets a travel seller and an embedded insurer in one composed product -- independent bookings, same-subject trip protection, carrier- and supplier-decided confirmations, and claim settlement -- with one vocabulary and SDK. - Blueprint ID: `insured-travel-marketplace` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, claim, deposits, flight_booking, hotel_stay, identity, internal_transfers, payouts, policy, products, travel_package, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.insuredTravelMarketplace` - Built on business instruments: flight_booking, hotel_stay, policy, claim Business vocabulary: - **Trip subject** (`trip_subject`): The itinerary or stay both the booking and its protection reference, grounded on the versioned subject record. [grounded in the `subject` resource] - **Travel policy** (`travel_policy`): Trip protection bound over the same subject a booking references; grounded on the policy state machine. [grounded in the `policy` business instrument] - **Covered event** (`covered_event`): The disruption claim filed against the travel policy; grounded on the claim state machine. [grounded in the `claim` business instrument] - **Protection payout** (`protection_payout`): The ledger transfer settling an approved disruption claim to the traveler. [grounded in the `internal_transfer` resource] SDK actions: - `hyperscale.blueprints.insuredTravelMarketplace.registerTripSubject()` -> `subject.create`: Register the itinerary or stay a booking and policy will share. - `hyperscale.blueprints.insuredTravelMarketplace.holdFlight()` -> `flight_booking.create`: Hold a flight booking against the registered trip subject. - `hyperscale.blueprints.insuredTravelMarketplace.holdStay()` -> `hotel_stay.create`: Hold a hotel stay against the registered trip subject. - `hyperscale.blueprints.insuredTravelMarketplace.quoteTripProtection()` -> `policy.create`: Quote travel protection for the itinerary. - `hyperscale.blueprints.insuredTravelMarketplace.bindTripProtection()` -> `policy.bind`: Bind trip protection over the same subject the booking holds. - `hyperscale.blueprints.insuredTravelMarketplace.fileCoveredEvent()` -> `claim.create`: File a disruption claim against the travel policy. - `hyperscale.blueprints.insuredTravelMarketplace.payProtection()` -> `claim.pay`: Settle the approved disruption claim to the traveler. Provider families: - Air Carrier (`air_carrier`): roadmap (not integrated; blocks the live surface). Blocked live until an air carrier or consolidator provider is integrated; live ticketing requires an accredited issuing seat. - Lodging Supplier (`lodging_supplier`): roadmap (not integrated; blocks the live surface). Blocked live until a lodging supply provider is integrated. - Insurance Carrier (`insurance_carrier`): roadmap (not integrated; blocks the live surface). Blocked live until an insurance carrier provider is integrated; insurance binding is a regulated activity gated behind license review, and the reference Saudi marketplace additionally requires the distributor's own SAMA approval before it will serve the API at all. Quoting on that class is identity-full: the distributor demands national ID or Iqama, date of birth, and contact details before it prices, so a tenant holds regulated personal data from the first quote, not from binding. - Insurance Claims Adjuster (`insurance_claims_adjuster`): roadmap (not integrated; blocks the live surface). Blocked live until a claims-adjuster provider is integrated; claim payouts remain sandbox-only. A carrier with no adjudication API is served by the attest path on the claim instrument instead of this decision seam. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - air_carrier_provider_integration - lodging_supplier_provider_integration - insurance_carrier_provider_integration - insurance_claims_adjuster_provider_integration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create traveler customers (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create traveler, operator, and insurer accounts (`account.create`) 8. Fund the traveler wallet in sandbox (`sandbox.account.fund`) 9. Register the first trip subject (`subject.create`) 10. Hold the first flight booking (`flight_booking.create`) 11. Quote trip protection over the subject (`policy.create`) 12. Bind the protection (`policy.bind`) 13. Confirm the booking (`flight_booking.confirm`) 14. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Sell a flight: Hold and confirm the flight, then unwind a cancellation under the void window. - Sell a stay: Hold and confirm the stay, then unwind a cancellation under the free-cancel window. - Settle a disruption claim: Bind trip protection over the registered subject, file a covered event, and settle the payout. - Register a flight itinerary: Register the flight itinerary as the subject a booking or protection policy can reference. - Onboard a traveler: Create the traveler and activate product access before the first hold. - Move trip funds: Reserve and post one trip-fund transfer explicitly in sandbox. ## Local Services Marketplace Service requests matched to provider offers, customer funds held until completion evidence lands, then provider payouts release. A founder gets the whole job-settlement spine of a services marketplace -- service requests, provider offers, customer holds, completion evidence, and provider payouts -- as one composed product with its own vocabulary and SDK. - Blueprint ID: `local-services-marketplace` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, deposits, escrow_order, identity, internal_transfers, listing, payouts, products, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.localServicesMarketplace` - Built on business instruments: escrow_order, listing Business vocabulary: - **Service request** (`service_request`): A job a customer posts for providers to accept; grounded on the listing state machine. [grounded in the `listing` business instrument] - **Provider offer** (`provider_offer`): A provider's acceptance reserving a posted job; grounded on the listing state machine. [grounded in the `listing` business instrument] - **Customer hold** (`customer_hold`): The customer's escrowed funds for one job; grounded on the escrow order state machine. [grounded in the `escrow_order` business instrument] - **Completion evidence** (`completion_evidence`): Proof-of-work evidence attached to the job's trust file before release. [grounded in the `trust_evidence` resource] - **Provider payout** (`provider_payout`): The outbound settlement to the provider once the customer hold releases. [grounded in the `payout` resource] SDK actions: - `hyperscale.blueprints.localServicesMarketplace.postServiceRequest()` -> `listing.create`: Post a customer's job as an open service request. - `hyperscale.blueprints.localServicesMarketplace.publishServiceRequest()` -> `listing.publish`: Publish a posted service request so providers can submit offers and open escrow holds. - `hyperscale.blueprints.localServicesMarketplace.acceptProviderOffer()` -> `listing.reserve`: Reserve the service request under an accepted provider offer. - `hyperscale.blueprints.localServicesMarketplace.openServiceHold()` -> `escrow_order.create`: Open an escrow hold for an accepted job. - `hyperscale.blueprints.localServicesMarketplace.fundServiceHold()` -> `escrow_order.fund`: Fund the customer's escrow hold for an accepted job. - `hyperscale.blueprints.localServicesMarketplace.completeServiceRequest()` -> `listing.sell`: Mark the service request completed against the funded customer hold before payout release. - `hyperscale.blueprints.localServicesMarketplace.releaseProviderPayout()` -> `escrow_order.release`: Release the customer hold to the provider once completion evidence lands. Provider families: - Accounts & Ledger (first-party) (`accounts_ledger_first_party`): first-party (Hyperscale is the provider). First-party; no external provider readiness applies. Live money movement still gates on KYB and the product's own live capability grants. - Identity & Business Verification (`identity_verification`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the identity trust provider configured and its External Confirmation accepted. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create customer and provider profiles (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create customer and provider accounts (`account.create`) 8. Fund the customer wallet in sandbox (`sandbox.account.fund`) 9. Post the first service request (`listing.create`) 10. Publish the service request (`listing.publish`) 11. Open the customer hold (`escrow_order.create`) 12. Fund the customer hold into escrow (`escrow_order.fund`) 13. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Fulfill a service request: Post the request, reserve it under a provider offer, and complete the job on delivered work. - Onboard a customer: Create the customer and activate product access before the first request. - Move job funds: Reserve and post the hold's ledger transfers explicitly in sandbox. - Void a customer hold: Reserve and void a customer-hold transfer before it posts. ## Luxury Goods Consignment Escrow Consigned luxury assets sold under authenticity checks, buyer holds, and protected consignor payouts. A consignment founder gets registered assets, authenticity evidence, escrowed buyer holds, dispute claims, and consignor payouts as one composed product speaking the consignment trade's own language. - Blueprint ID: `luxury-goods-consignment-escrow` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, claim, deposits, escrow_order, identity, internal_transfers, listing, order, payouts, policy, products, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.luxuryGoodsConsignmentEscrow` - Built on business instruments: escrow_order, listing, order, policy, claim Business vocabulary: - **Consigned asset** (`consigned_asset`): A luxury item registered for sale on behalf of its consignor; grounded on the listing state machine. [grounded in the `listing` business instrument] - **Authenticity check** (`authenticity_check`): Expert authentication evidence attached to the asset's trust file before sale. [grounded in the `trust_evidence` resource] - **Condition report** (`condition_report`): The documented condition of the asset at intake, backing later dispute decisions. [grounded in the `trust_evidence` resource] - **Buyer hold** (`buyer_hold`): The buyer's escrowed funds for one asset; grounded on the escrow order state machine. [grounded in the `escrow_order` business instrument] - **Dispute claim** (`dispute_claim`): A condition or authenticity dispute settled through the declared claim lifecycle. [grounded in the `claim` business instrument] - **Consignor payout** (`consignor_payout`): The outbound settlement to the consignor after commission on a completed sale. [grounded in the `payout` resource] SDK actions: - `hyperscale.blueprints.luxuryGoodsConsignmentEscrow.registerConsignedAsset()` -> `listing.create`: Register a consigned asset for sale. - `hyperscale.blueprints.luxuryGoodsConsignmentEscrow.placeBuyerHold()` -> `escrow_order.fund`: Fund the buyer's escrow hold for an asset purchase. - `hyperscale.blueprints.luxuryGoodsConsignmentEscrow.openConditionDispute()` -> `claim.create`: Open a condition dispute against the sale's protection coverage. - `hyperscale.blueprints.luxuryGoodsConsignmentEscrow.releaseConsignorPayout()` -> `escrow_order.release`: Release the buyer's hold to the consignor when the sale completes clean. Provider families: - Accounts & Ledger (first-party) (`accounts_ledger_first_party`): first-party (Hyperscale is the provider). First-party; no external provider readiness applies. Live money movement still gates on KYB and the product's own live capability grants. - Identity & Business Verification (`identity_verification`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the identity trust provider configured and its External Confirmation accepted. - Insurance Carrier (`insurance_carrier`): roadmap (not integrated; blocks the live surface). Blocked live until an insurance carrier provider is integrated; insurance binding is a regulated activity gated behind license review, and the reference Saudi marketplace additionally requires the distributor's own SAMA approval before it will serve the API at all. Quoting on that class is identity-full: the distributor demands national ID or Iqama, date of birth, and contact details before it prices, so a tenant holds regulated personal data from the first quote, not from binding. - Insurance Claims Adjuster (`insurance_claims_adjuster`): roadmap (not integrated; blocks the live surface). Blocked live until a claims-adjuster provider is integrated; claim payouts remain sandbox-only. A carrier with no adjudication API is served by the attest path on the claim instrument instead of this decision seam. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - insurance_carrier_provider_integration - insurance_claims_adjuster_provider_integration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Onboard consignor and buyer customers in sandbox (`sandbox.customer.onboard`) 5. Activate sandbox customer bindings (`sandbox.customer_access.activate`) 6. Create consignor and buyer accounts (`account.create`) 7. Register the merchandise subject (`subject.create`) 8. Fund the buyer wallet in sandbox (`sandbox.account.fund`) 9. Register the first consigned asset (`listing.create`) 10. Quote sale protection coverage (`policy.create`) 11. Bind sale protection coverage (`policy.bind`) 12. Place the buyer's escrow hold (`escrow_order.create`) 13. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Sell and protect a consigned asset: Register the asset, place the buyer hold, reserve and confirm the order, settle a condition claim, mark the asset sold, release the consignor payout, and fulfill the order. - Move sale funds: Reserve and post the hold's ledger transfers in sandbox. ## Parametric Travel Insurance Travel policies bound against covered trips, with claims triggered by recorded delay signals instead of adjuster review. A founder gets the settlement spine of a parametric insurer -- bound travel policies, covered trips, recorded delay signals, and rule-driven beneficiary payouts -- as one composed product with its own vocabulary and SDK. - Blueprint ID: `parametric-travel-insurance` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, claim, deposits, identity, internal_transfers, payouts, policy, products, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.parametricTravelInsurance` - Built on business instruments: policy, claim Business vocabulary: - **Travel policy** (`travel_policy`): A delay and cancellation policy bound against one covered trip; grounded on the policy state machine. [grounded in the `policy` business instrument] - **Covered event** (`covered_event`): The trip whose disruption the policy covers; grounded on the versioned subject record. [grounded in the `subject` resource] - **Delay signal** (`delay_signal`): The disruption evidence a payout rule triggers on, recorded on the policy when its claim opens. [grounded in the `claim` business instrument] - **Payout rule** (`payout_rule`): The declared trigger-to-payout terms a policy settles claims under; vocabulary over the claim lifecycle. [grounded in the `claim` business instrument] - **Beneficiary payout** (`beneficiary_payout`): The ledger transfer that settles a triggered claim to the policyholder. [grounded in the `internal_transfer` resource] SDK actions: - `hyperscale.blueprints.parametricTravelInsurance.registerCoveredEvent()` -> `subject.create`: Register the trip a policy will cover. - `hyperscale.blueprints.parametricTravelInsurance.bindTravelPolicy()` -> `policy.bind`: Bind a quoted travel policy against its covered trip. - `hyperscale.blueprints.parametricTravelInsurance.triggerParametricClaim()` -> `claim.create`: Open a claim when a recorded delay signal meets the payout rule. - `hyperscale.blueprints.parametricTravelInsurance.payBeneficiary()` -> `claim.pay`: Settle the triggered claim as a beneficiary payout. Provider families: - Insurance Carrier (`insurance_carrier`): roadmap (not integrated; blocks the live surface). Blocked live until an insurance carrier provider is integrated; insurance binding is a regulated activity gated behind license review, and the reference Saudi marketplace additionally requires the distributor's own SAMA approval before it will serve the API at all. Quoting on that class is identity-full: the distributor demands national ID or Iqama, date of birth, and contact details before it prices, so a tenant holds regulated personal data from the first quote, not from binding. - Insurance Claims Adjuster (`insurance_claims_adjuster`): roadmap (not integrated; blocks the live surface). Blocked live until a claims-adjuster provider is integrated; claim payouts remain sandbox-only. A carrier with no adjudication API is served by the attest path on the claim instrument instead of this decision seam. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - insurance_carrier_provider_integration - insurance_claims_adjuster_provider_integration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create policyholder customers (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create policyholder and payout accounts (`account.create`) 8. Fund the premium wallet in sandbox (`sandbox.account.fund`) 9. Register the first covered trip (`subject.create`) 10. Quote the first travel policy (`policy.create`) 11. Bind the policy against its trip (`policy.bind`) 12. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Trigger a parametric claim: Quote and bind the travel policy, open the claim on a delay signal, and settle the beneficiary payout. - Register a covered trip: Register the covered trip as the versioned subject the policy refers to. - Onboard a policyholder: Create the policyholder and activate product access before the first quote. - Move payout funds: Reserve and post the beneficiary payout's ledger transfers explicitly in sandbox. - Void a payout hold: Reserve and void a beneficiary-payout hold before it posts. ## Peer Lending Marketplace Borrowers raise loan requests that lenders fund in commitments, one servicing account carries the whole loan, and repayments flow back to lenders by committed weight. A founder gets a lending marketplace and a loan servicer in one composed product -- escrowed lender commitments, one servicing account wired through the whole loan, weight-exact lender distributions, and a real recovery lane -- with one vocabulary and SDK. - Blueprint ID: `peer-lending-marketplace` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, collections_case, contact_attempt, credit_agreement, deposits, exposure_arrangement, funding_commitment, funding_round, identity, installment, internal_transfers, lender_distribution, payouts, products, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.peerLendingMarketplace` - Built on business instruments: credit_agreement, funding_round, funding_commitment, lender_distribution, installment, collections_case, contact_attempt Business vocabulary: - **Loan request** (`loan_request`): The borrower's raise lenders commit into; grounded on the funding round state machine. [grounded in the `funding_round` business instrument] - **Lender commitment** (`lender_commitment`): One lender's escrowed pledge inside a loan request; grounded on the funding commitment state machine. [grounded in the `funding_commitment` business instrument] - **Loan** (`loan`): The funded agreement advanced to the borrower; grounded on the credit agreement state machine. [grounded in the `credit_agreement` business instrument] - **Repayment** (`repayment`): One scheduled loan repayment, collected on its date or marked overdue. [grounded in the `installment` business instrument] - **Lender share** (`lender_share`): One lender's claim on the serviced loan, paid its committed-weight share of the advanced pool. [grounded in the `lender_distribution` business instrument] - **Recovery case** (`recovery_case`): The collections file opened over a delinquent repayment; grounded on the collections case state machine. [grounded in the `collections_case` business instrument] - **Outreach record** (`outreach_record`): One logged borrower contact inside a recovery case. [grounded in the `contact_attempt` business instrument] SDK actions: - `hyperscale.blueprints.peerLendingMarketplace.openLoanRequest()` -> `funding_round.create`: Open the borrower's raise lenders will commit into. - `hyperscale.blueprints.peerLendingMarketplace.commitFunds()` -> `funding_commitment.create`: Escrow a lender's pledge while the round is open. - `hyperscale.blueprints.peerLendingMarketplace.openLoan()` -> `credit_agreement.create`: Open the loan agreement over the funded round's servicing account. - `hyperscale.blueprints.peerLendingMarketplace.disburseLoan()` -> `credit_agreement.advance`: Advance the funded principal to the borrower. - `hyperscale.blueprints.peerLendingMarketplace.scheduleRepayment()` -> `installment.create`: Schedule one repayment against the servicing account. - `hyperscale.blueprints.peerLendingMarketplace.claimLenderShare()` -> `lender_distribution.create`: Record a lender's claim on the serviced loan at origination. - `hyperscale.blueprints.peerLendingMarketplace.settleLoan()` -> `credit_agreement.settle`: Settle the loan after the last repayment collects. - `hyperscale.blueprints.peerLendingMarketplace.openRecoveryCase()` -> `collections_case.create`: Open a recovery case over a delinquent repayment. - `hyperscale.blueprints.peerLendingMarketplace.logOutreach()` -> `contact_attempt.create`: Log a borrower contact inside the recovery case. Provider families: - Accounts & Ledger (first-party) (`accounts_ledger_first_party`): first-party (Hyperscale is the provider). First-party; no external provider readiness applies. Live money movement still gates on KYB and the product's own live capability grants. - Identity & Business Verification (`identity_verification`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the identity trust provider configured and its External Confirmation accepted. - Settlement Ingestion (pay-in) (`settlement_ingestion`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires a live collection account and the settlement provider integration configured. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - provider_payout_configuration - lending_license_evidence Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create borrower and lender customers (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create borrower, lender, and servicing accounts (`account.create`) 8. Fund lender wallets in sandbox (`sandbox.account.fund`) 9. Open the first loan request (`funding_round.create`) 10. Escrow the first lender commitment (`funding_commitment.create`) 11. Open the loan over the servicing account (`credit_agreement.create`) 12. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Fill a loan request: Open the raise, escrow lender commitments, activate at target, and collect the round into the servicing account. - Write off a loan: Open and advance the loan out of the servicing account, then write off the outstanding agreement. - Create a lender distribution: Activate and collect the lender's commitment, advance the loan, then record the lender's distribution claim. - Write off a late repayment: Let a repayment lapse overdue, then write off the installment on the same schedule. - Recover a delinquent loan: Open a recovery case over the overdue repayment, log outreach, and recover the balance. - Onboard a borrower or lender: Create the customer and activate product access before the first commitment. - Move loan funds: Reserve and post one loan-fund transfer explicitly in sandbox. ## Personalized Shopping Concierge Concierge recommendations proposed as orders, purchases approved into escrow, and returns settled through refunds and store credit. A concierge founder gets shopper profiles, proposed merchant orders, approval-gated purchase holds, return windows, and store credit as one composed product with its own vocabulary and SDK. - Blueprint ID: `personalized-shopping-concierge` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, deposits, escrow_order, identity, internal_transfers, listing, payouts, products, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.personalizedShoppingConcierge` - Built on business instruments: escrow_order, listing Business vocabulary: - **Shopper profile** (`shopper_profile`): A shopper onboarded with the preferences the concierge buys for; grounded on the first-party customer record. [grounded in the `customer` resource] - **Concierge recommendation** (`concierge_recommendation`): A proposed purchase awaiting the shopper's approval; grounded on the listing state machine. [grounded in the `listing` business instrument] - **Purchase approval** (`purchase_approval`): The shopper's funded approval for one purchase; grounded on the escrow order state machine. [grounded in the `escrow_order` business instrument] - **Merchant order** (`merchant_order`): An approved recommendation placed with the merchant; grounded on the listing state machine. [grounded in the `listing` business instrument] - **Return window** (`return_window`): The refundable period after delivery while the purchase can still unwind; grounded on the escrow order state machine. [grounded in the `escrow_order` business instrument] - **Store credit** (`store_credit`): A shopper's credit balance held on its own ledger account. [grounded in the `account` resource] SDK actions: - `hyperscale.blueprints.personalizedShoppingConcierge.createShopperProfile()` -> `customer.create`: Onboard a shopper with the profile the concierge buys for. - `hyperscale.blueprints.personalizedShoppingConcierge.proposeRecommendation()` -> `listing.create`: Propose a purchase recommendation for the shopper's approval. - `hyperscale.blueprints.personalizedShoppingConcierge.publishRecommendation()` -> `listing.publish`: Publish a proposed purchase recommendation so the shopper can approve it. - `hyperscale.blueprints.personalizedShoppingConcierge.openPurchaseHold()` -> `escrow_order.create`: Open the shopper's purchase hold for a proposed purchase. - `hyperscale.blueprints.personalizedShoppingConcierge.approvePurchase()` -> `escrow_order.fund`: Fund the shopper's approval hold for a proposed purchase. - `hyperscale.blueprints.personalizedShoppingConcierge.reserveRecommendation()` -> `listing.reserve`: Reserve the recommendation against the shopper's funded approval hold. - `hyperscale.blueprints.personalizedShoppingConcierge.attachMerchantOrder()` -> `listing.update`: Attach the placed merchant order to an approved recommendation. - `hyperscale.blueprints.personalizedShoppingConcierge.completeMerchantOrder()` -> `listing.sell`: Complete the merchant order once the item is delivered. - `hyperscale.blueprints.personalizedShoppingConcierge.releaseMerchantPayout()` -> `escrow_order.release`: Release the escrowed purchase hold to the merchant upon delivery. - `hyperscale.blueprints.personalizedShoppingConcierge.issueStoreCredit()` -> `internal_transfer.create`: Credit the shopper's store-credit account. - `hyperscale.blueprints.personalizedShoppingConcierge.refundReturnWindow()` -> `escrow_order.refund`: Refund the purchase hold when a return lands inside the window. Provider families: - Accounts & Ledger (first-party) (`accounts_ledger_first_party`): first-party (Hyperscale is the provider). First-party; no external provider readiness applies. Live money movement still gates on KYB and the product's own live capability grants. - Settlement Ingestion (pay-in) (`settlement_ingestion`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires a live collection account and the settlement provider integration configured. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create your first shopper customer (`customer.create`) 5. Enroll shoppers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create shopper, merchant, and store-credit accounts (`account.create`) 8. Fund the shopper wallet in sandbox (`sandbox.account.fund`) 9. Propose the first recommendation (`listing.create`) 10. Publish the recommendation (`listing.publish`) 11. Open the purchase approval hold (`escrow_order.create`) 12. Fund the shopper's approval (`escrow_order.fund`) 13. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Onboard a shopper: Create the shopper profile and activate their concierge access before the first recommendation. - Fulfill a merchant order: Propose the recommendation, reserve it on approval, and complete the order on delivery. - Create a shopper pay-in: Create the shopper's pay-in transfer that backs the next approval hold. - Move purchase funds: Reserve and post the hold's ledger transfers explicitly in sandbox. ## SMB Expense Card Business expense cards over a funded float, with spend policies, authorization review, and a reimbursement ledger. A founder gets an expense program's operating spine -- funded business accounts, cardholders, spend policies, authorization review, and a reimbursement ledger -- as one composed product with its own vocabulary and SDK. - Blueprint ID: `smb-expense-card` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, card, card_authorization, card_dispute, card_transaction, cardholder, deposits, identity, internal_transfers, payouts, products, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.smbExpenseCard` - Built on business instruments: cardholder, card, card_authorization, card_transaction, card_dispute Business vocabulary: - **Business account** (`business_account`): The funded expense float one business spends and reimburses from. [grounded in the `account` resource] - **Expense card** (`expense_card`): The virtual card issued against one business float. [grounded in the `card` business instrument] - **Spend policy** (`spend_policy`): The declarative limits stored on an expense card. [grounded in the `card` business instrument] - **Authorization decision** (`authorization_decision`): The just-in-time approval that places a card hold. [grounded in the `card_authorization` business instrument] - **Expense receipt** (`expense_receipt`): The receipt document a cardholder attaches as evidence behind a cleared spend or reimbursement. [grounded in the `trust_evidence` resource] - **Reimbursement ledger** (`reimbursement_ledger`): The ledger transfer that pays back out-of-pocket employee spend from the float. [grounded in the `internal_transfer` resource] SDK actions: - `hyperscale.blueprints.smbExpenseCard.createBusinessAccount()` -> `account.create`: Open the business's expense float account. - `hyperscale.blueprints.smbExpenseCard.fundExpenseFloat()` -> `sandbox.account.fund`: Fund the expense float in sandbox. - `hyperscale.blueprints.smbExpenseCard.issueExpenseCard()` -> `card.create`: Issue a virtual expense card against the business float. - `hyperscale.blueprints.smbExpenseCard.setSpendPolicy()` -> `card.update`: Update the expense card's declarative spend controls. - `hyperscale.blueprints.smbExpenseCard.approveCardAuthorization()` -> `card_authorization.approve`: Approve a card authorization through the provider decision seam. - `hyperscale.blueprints.smbExpenseCard.moveReimbursement()` -> `internal_transfer.create`: Pay back out-of-pocket employee spend from the float. Provider families: - Accounts & Ledger (first-party) (`accounts_ledger_first_party`): first-party (Hyperscale is the provider). First-party; no external provider readiness applies. Live money movement still gates on KYB and the product's own live capability grants. - Identity & Business Verification (`identity_verification`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the identity trust provider configured and its External Confirmation accepted. - Banking & Card Issuing (`banking_or_card_issuing`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the issuer processor and tokenization provider configured. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - issuer_processor_configuration - tokenization_provider_configuration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create business and cardholder customers (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create the business float account (`account.create`) 8. Fund the expense float in sandbox (`sandbox.account.fund`) 9. Open the cardholder identity review (`trust_review.create`) 10. Create the first cardholder (`cardholder.create`) 11. Activate the first cardholder (`cardholder.activate`) 12. Issue the first expense card (`card.create`) 13. Activate the first expense card (`card.activate`) 14. Request the first authorization (`card_authorization.create`) 15. Approve the first authorization (`card_authorization.approve`) 16. Capture the first authorization (`card_authorization.capture`) 17. Record the first transaction (`card_transaction.create`) 18. File the first card dispute (`card_dispute.create`) 19. Post the first reimbursement (`internal_transfer.create`) 20. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Issue and authorize a card: Enroll the cardholder, issue their expense card, and clear the first authorization against the float. - Onboard a business: Create the business and activate product access before issuing cards. - Move reimbursement funds: Reserve and post a reimbursement's ledger transfers explicitly in sandbox. - Void a reimbursement hold: Reserve and void a reimbursement transfer before it posts. - Resolve a card dispute: File the evidence-backed dispute, review it, and record the provider-decision-gated outcome. ## Tuition Installment Academy Term tuition funded up front to the academy and collected back from families as a declared installment schedule with dated delinquency. A founder gets the settlement spine of a tuition-financing operation -- funded terms, family payment schedules, dated delinquency, and a collections trail -- as one composed product with its own vocabulary and SDK. - Blueprint ID: `tuition-installment-academy` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, collections_case, contact_attempt, credit_agreement, deposits, exposure_arrangement, funding_commitment, funding_round, identity, installment, internal_transfers, payouts, products, usage, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.tuitionInstallmentAcademy` - Built on business instruments: credit_agreement, installment, exposure_arrangement, funding_round, funding_commitment, collections_case, contact_attempt Business vocabulary: - **Tuition plan** (`tuition_plan`): One student's funded term fee; grounded on the credit agreement state machine. [grounded in the `credit_agreement` business instrument] - **Tuition payment** (`tuition_payment`): One scheduled family payment of the plan, collected on its date or marked overdue. [grounded in the `installment` business instrument] - **Family limit** (`family_limit`): The approved financing cap every new tuition plan is admitted against. [grounded in the `exposure_arrangement` business instrument] - **Term funding** (`term_funding`): The ledger transfer advancing the term fee to the academy's account at enrollment. [grounded in the `internal_transfer` resource] - **Funding round** (`funding_round`): The pooled funding round lenders commit into; grounded on the funding round state machine. [grounded in the `funding_round` business instrument] - **Funding commitment** (`funding_commitment`): An investor pledge committing capital into an open funding round. [grounded in the `funding_commitment` business instrument] SDK actions: - `hyperscale.blueprints.tuitionInstallmentAcademy.openFundingRound()` -> `funding_round.create`: Open a pooled funding round for tuition financing. - `hyperscale.blueprints.tuitionInstallmentAcademy.pledgeToFundingRound()` -> `funding_commitment.create`: Pledge capital into an open funding round. - `hyperscale.blueprints.tuitionInstallmentAcademy.openTuitionPlan()` -> `credit_agreement.create`: Open a tuition plan for a student's term at enrollment. - `hyperscale.blueprints.tuitionInstallmentAcademy.fundTerm()` -> `credit_agreement.advance`: Advance the full term fee to the academy's account. - `hyperscale.blueprints.tuitionInstallmentAcademy.scheduleTuitionPayment()` -> `installment.create`: Declare one family payment with its due date and amount. - `hyperscale.blueprints.tuitionInstallmentAcademy.settleTuitionPlan()` -> `credit_agreement.settle`: Settle the plan once collected payments cover the term fee. Provider families: - Accounts & Ledger (first-party) (`accounts_ledger_first_party`): first-party (Hyperscale is the provider). First-party; no external provider readiness applies. Live money movement still gates on KYB and the product's own live capability grants. - Settlement Ingestion (pay-in) (`settlement_ingestion`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires a live collection account and the settlement provider integration configured. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - provider_payout_configuration - lending_license_evidence Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create family customers (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create family, academy, and funding accounts (`account.create`) 8. Fund the financing pool in sandbox (`sandbox.account.fund`) 9. Open the first tuition plan (`credit_agreement.create`) 10. Fund the term to the academy (`credit_agreement.advance`) 11. Schedule the first tuition payment (`installment.create`) 12. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Write off a funded term: Open the tuition plan, advance the term funding, then write off the outstanding agreement. - Write off an overdue payment: Mark a lapsed payment overdue on its date, then write off the installment. - Hand off to collections: Open a recovery case over the delinquent plan, record contact, and recover. - Approve a family limit: Approve the family's financing limit, advance a plan against it, write off the plan, and close the limit. - Raise the financing pool: Open a funding round, collect a commitment, and activate the raised pool. - Onboard a family: Create the family customer and activate product access before the first plan. - Move funding: Reserve and post ledger transfers explicitly in sandbox to trace the term-funding leg. ## Vehicle Escrow Marketplace Buyer deposits held in escrow against vehicle listings, released while motor coverage is active. A founder gets the entire settlement spine of a vehicle marketplace -- listings, buyer deposits, active motor policy gating, and seller payouts -- as one composed product with its own vocabulary and SDK. - Blueprint ID: `vehicle-escrow-marketplace` - Environment: sandbox - Capabilities provisioned: accounts, activity, beneficiary_verification, billing, deposits, identity, internal_transfers, motor_policy, payouts, products, usage, vehicle_escrow, vehicle_listing, verification, webhooks - Meters billed: account.active_month, account.created.count, collection.pay_in.count, collection.pay_in.volume_sar, deposit.attributed.count, deposit.attributed.volume_sar, financial_address.active_month, financial_address.issued.count, instrument.event.count, instrument.event.volume_sar, kyb.application.review, payout.external.count, payout.external.volume_sar, transfer.internal.count, transfer.internal.volume_sar, verification.kyb.count, verification.kyc.basic.count, verification.kyc.investment.count, verification.kyc.standard.count - SDK namespace: `blueprints.vehicleEscrowMarketplace` - Built on business instruments: motor_policy, vehicle_escrow, vehicle_listing Business vocabulary: - **Vehicle listing** (`vehicle_listing`): A vehicle offered for sale; grounded on the vehicle listing state machine. [grounded in the `vehicle_listing` business instrument] - **Buyer deposit** (`buyer_deposit`): The buyer's escrowed funds for one vehicle deal; grounded on the vehicle escrow state machine. [grounded in the `vehicle_escrow` business instrument] - **Motor policy** (`motor_policy`): Coverage bound to the vehicle subject before the escrow may release. [grounded in the `motor_policy` business instrument] - **Inspection report** (`inspection_report`): Pre-sale vehicle inspection evidence attached to the deal's trust file. [grounded in the `trust_evidence` resource] - **Title transfer** (`title_transfer`): The externally witnessed registry confirmation that ownership changed hands. [grounded in the `external_confirmation` resource] - **Seller payout** (`seller_payout`): The outbound settlement to the seller once the escrow releases. [grounded in the `payout` resource] - **Delivery confirmation** (`delivery_confirmation`): The receipt-backed record that the vehicle was handed over to the buyer. [grounded in the `receipt` resource] SDK actions: - `hyperscale.blueprints.vehicleEscrowMarketplace.createVehicleListing()` -> `vehicle_listing.create`: Publish a vehicle for sale as a marketplace listing. - `hyperscale.blueprints.vehicleEscrowMarketplace.quoteMotorPolicy()` -> `motor_policy.create`: Quote motor insurance coverage for the vehicle. - `hyperscale.blueprints.vehicleEscrowMarketplace.openVehicleEscrow()` -> `vehicle_escrow.create`: Open an escrow deposit for a vehicle deal. - `hyperscale.blueprints.vehicleEscrowMarketplace.holdBuyerDeposit()` -> `vehicle_escrow.fund`: Fund the buyer's escrow deposit for a vehicle deal. - `hyperscale.blueprints.vehicleEscrowMarketplace.approveTitleTransfer()` -> `trust_requirement.respond`: Respond to the title-transfer requirement with registry evidence. - `hyperscale.blueprints.vehicleEscrowMarketplace.releaseSellerPayout()` -> `vehicle_escrow.release`: Release the escrowed deposit to the seller once conditions resolve. - `hyperscale.blueprints.vehicleEscrowMarketplace.refundBuyerDeposit()` -> `vehicle_escrow.confirm_cancel`: Refund the escrowed deposit to the buyer on a failed deal. Provider families: - Accounts & Ledger (first-party) (`accounts_ledger_first_party`): first-party (Hyperscale is the provider). First-party; no external provider readiness applies. Live money movement still gates on KYB and the product's own live capability grants. - Identity & Business Verification (`identity_verification`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the identity trust provider configured and its External Confirmation accepted. - Insurance Carrier (`insurance_carrier`): roadmap (not integrated; blocks the live surface). Blocked live until an insurance carrier provider is integrated; insurance binding is a regulated activity gated behind license review, and the reference Saudi marketplace additionally requires the distributor's own SAMA approval before it will serve the API at all. Quoting on that class is identity-full: the distributor demands national ID or Iqama, date of birth, and contact details before it prices, so a tenant holds regulated personal data from the first quote, not from binding. - Insurance Claims Adjuster (`insurance_claims_adjuster`): roadmap (not integrated; blocks the live surface). Blocked live until a claims-adjuster provider is integrated; claim payouts remain sandbox-only. A carrier with no adjudication API is served by the attest path on the claim instrument instead of this decision seam. - Payouts (bank) (`payouts`): integrated (sandbox adapter executes). Sandbox-simulated. Live requires the partner-bank credential reference, mirrored limits, and a live ledger partition. Going live requires: - kyb_approved - billing_accounts_configured - provider_configuration - insurance_carrier_provider_integration - insurance_claims_adjuster_provider_integration Setup journey: 1. Sign up and create your team (`user.signup`) 2. Compose product from blueprint (`product.blueprint.compose`) 3. Mint a sandbox API key (`api_key.sandbox.create`) 4. Create buyer and seller customers (`customer.create`) 5. Enroll customers into product (`customer_access.create`) 6. Approve sandbox customer bindings (`customer_access.activate`) 7. Create buyer and seller accounts (`account.create`) 8. Fund the buyer wallet in sandbox (`sandbox.account.fund`) 9. Register the vehicle subject (`subject.create`) 10. Quote the motor policy (`motor_policy.create`) 11. Bind the motor policy (`motor_policy.bind`) 12. Open the buyer's vehicle escrow (`vehicle_escrow.create`) 13. Fund the buyer deposit into escrow (`vehicle_escrow.fund`) 14. Publish the first vehicle listing (`vehicle_listing.create`) 15. Retrieve receipt confirmation (`receipt.retrieve`) Example journeys: - Bind protection for the vehicle: Quote and bind the vehicle's motor policy before the escrow can release. - Sell a vehicle: Publish the vehicle listing, reserve it for the buyer, and complete the sale on handover. - Onboard a buyer: Create the buyer and activate product access before the first deal. - Move deal funds: Reserve and post the deposit's ledger transfers explicitly in sandbox. - Void a deal transfer: Reserve and void a deal-fund transfer before it posts. Compose a Blueprint from the catalog in the Hyperscale portal, then mint a sandbox API key from the Product's Developers desk and follow the setup journey above. See the [Quickstart](quickstart.md) for the credential bootstrap.