This page defines the logical data the DomiDo platform stores and exchanges. It describes the shape of every domain resource — users, drafts, listings, orders, jobs, payments — without naming a database, queue, or object store. Field names here are requirements for the API and domain layer, not for physical tables or collections, and the same data supports the Web/PWA beta today and the iOS and Android surfaces later through the React Native and Expo architecture. The page is long because the platform is broad, but the structure is consistent: each topic section opens with the principles that govern that data area, then walks through the resources and their fields in turn so a reviewer can see both the rule and the contract that enforces it.
Every user-facing resource carries id, createdAt, updatedAt, and a stable display identifier when the UI shows a public reference, order number, listing slug, receipt number, or statement period. Resources that render configurable copy include configuration source and version metadata when the frontend needs to explain jurisdiction support, Phase A interest-reservation policy, Phase A.5 Stripe card support, AI generation costs, Promo Studio options, payout fees, payout schedules, reserve and dispute rules, fulfilment waiting states, Phase A remix disabling, delivery phase state, or help content publication state. Money values include amount, currency, display, and includesVat when the value can include VAT. Media references include url, alt, kind, format, sourceFilename, width, height, sizeBytes, validationStatus, and crop metadata when the UI supports cropping.
Long-running work is represented by a Job with id, type, public status, progress, currentStep, steps, resourceRef, resultRef, generated artifacts, cost, configVersion, retry state, cancellation state, safe error state, pollAfterMs, createdAt, startedAt, updatedAt, and completedAt. The public job status values exposed to the app are queued, running, retrying, complete, failed, cancelled, and deadLettered; internal worker states such as leased, leaseOwner, and leaseUntil are backend data, not public app state. Job steps support user-visible progress for multi-stage work including projection generation, model provider calls, model validation, voxelisation, blockification, BOM and cost calculation, assembly and export generation, Promo Studio generation, text assistance, translation, publication, and future fulfilment sync. Job-start request data is typed by domain — projection, model, block-kit, and Promo Studio job starts and job retry and cancel controls do not use opaque generic payloads.
Every major feature aggregate that can appear before its operational phase is active includes a phaseStatus or equivalent FeaturePhaseGate reference. The FeaturePhaseGate includes featureKey, phase, status, userFacingState, disabledReason, activationCriteria, and configVersion. The allowed status values are phaseAActive, phaseAConditional, phaseA5Active, phaseBActive, phaseCExpansion, nativeDeferred, and blockedReadOnly.
Free-form user-generated text is represented internally by LocalizedText, which carries the original source text, source language, field and resource context, author role, visibility and audience, generated translation variants, translation status, stale state, moderation state, glossary or config version, and the last translation job reference. Public and read DTOs may expose resolved strings for convenience, but owner, admin, support, and editor DTOs expose localizedFields or translationSummary where the UI needs pending, failed, stale, or missing-language state. Translation targets come from backend-configured supported languages, and structured or sensitive fields — names, emails, phone numbers, addresses, payment and security data, file names, identifiers, VAT and tax fields, OAuth profile data, and credentials — remain ordinary structured and private fields and are not modelled as LocalizedText. The companion TranslationJobResult includes job id, resource ref, field path, source language, target language, status, provider-safe metadata, error code and message where failed, started and completed timestamps, cost and config metadata, and whether the result is approved for public display and search indexing.
ApiError carries a stable code, display-safe message, request id, field path where applicable, retryable state, retry-after seconds where applicable, phase-gate reference where applicable, and safe detail metadata. IdempotencyKey domain data carries scope, key, actor or session, operation, request hash, response status and body snapshot, resource refs, state, lock expiry, conflict state, and expiration. HealthStatus carries service status, readiness state, build version, environment, checked-at timestamp, and sanitised DependencyHealth entries; DependencyHealth carries the dependency key, category, status, degraded capability list, retryable state, last successful check timestamp where safe, and a safe message. The ReliabilityIncident or equivalent operational record supports dependency outage, readiness transition, worker recovery, restore rehearsal, provider circuit-breaker, webhook durable-store failure, object-storage mismatch cleanup, and audit-fail-closed events with request and correlation id and safe summary.
Product-event ingestion uses three coordinated shapes. AnalyticsEvent carries id, event name, event version, occurred-at timestamp, received-at timestamp, anonymous, session, user, and device identifiers where allowed, surface, route or screen, release version, platform target, locale, consent class, properties constrained by event schema, related resource refs, and correlation id where applicable. AnalyticsEventBatch carries batch id, client batch id, event count, accepted count, rejected count, rejected event indexes with safe reasons, ingestion timestamp, idempotency key where supplied, and retryability metadata. ProductEventDefinition carries a stable event name, version, description, phase, owner, required and optional properties, allowed property types, consent class, retention class, and deprecation state.
The founder beta dashboard, beta feedback, alert rules, and telemetry data classes round out the operational data model. FounderBetaDashboard carries metric period, activation funnel, listing and publish funnel, interest-reservation funnel, Phase A.5 pre-order funnel where active, listing-owner and designer funnel, support health, reliability health, top beta feedback themes, top failure states, conversion blockers, and export metadata — and it derives from stored events and domain records rather than manually assembled spreadsheets. BetaFeedback carries id, submitter or session reference, feedback type, title and body where provided, rating or severity where applicable, surface, route or screen, related resource refs, locale and source language, translation summary for translatable text, attachment refs, support conversation ref where created, status, tags, release version, and timestamps. AlertRule carries rule key, severity, owner, trigger condition, deduplication or suppression behaviour, current state, last triggered timestamp, resolved timestamp, impact summary, runbook or action summary, linked incidents, and notification channels without storing provider secrets. TelemetryDataClass defines retention, access roles, redaction rules, export eligibility, deletion behaviour, and raw-text or private-media allowance for audit events, technical logs, product analytics, support content, beta feedback, and aggregated metrics.
UserProfile carries id, displayName, avatar, email, locale, preferredContentLanguage, currency, roles, savedListings, interestReservationSummary, Phase A.5 or B cartId where active, designerProfileId or listing-owner profile reference where active, adminContentCapability, and notificationSummary. OAuthIdentity carries provider, providerUserId, email, displayName, and avatar, and the only allowed provider values are google, apple, and facebook. AccountSettings carries profile fields, avatar media reference, privacy choices, cookie choices, notification preferences, saved addresses, saved Stripe payment references, security settings, active sessions, data-export requests, pause-account and shop requests, and delete-account request state. LocalePreference uses configured UI language values, preferred content-language values, and configured locale and currency pairs; the mock language values are display examples only. NotificationPreference carries category, channel, enabled state, source screen, and last-updated metadata for the order, designer, payout, message, production-readiness, jurisdiction-availability, and marketing categories that are visible.
The trust and account-lifecycle layer keeps abusive content and credentials at arm's length. TrustRestriction carries userId, status, reasonCategory, summary, effectiveAt, createdBy, supportTicketIds, disputeIds, challengeStatus, and resolvedAt; reason categories include customer-extremism and anti-abuse categories without exposing unnecessary private detail. AccountSecuritySettings carries password-change availability, two-factor state where applicable, session list summary, recent security events, and reauthentication requirement labels without exposing credentials. AccountLifecycleRequest carries request type (dataExport, pauseAccount, pauseShop, deleteAccount), status, requested-at, completed-at, target account or shop reference, user-facing message, and support reference where applicable. AccountSession carries session id, device or browser display, approximate location where shown, last active time, current-session flag, and revoke availability. NotificationItem carries id, userId, category, severity, title, body, sourceSurface, resourceRef, actionRef, read, createdAt, readAt, and configVersion where the notification text depends on configuration.
Configuration drives a long list of decisions the UI used to hard-code. JurisdictionConfig carries jurisdiction code, supported state, coming-soon message, currency, VAT rule reference, delivery options, Stripe supported-card copy, and checkout-blocking reason. AIGenerationCostConfig carries operation type, label, cost amount, unit, currency or credit display, effective dates, and version. PayoutConfig carries minimum payout, payout-on-request fee percent, below-minimum payout fee percent, payout eligibility delay after delivery, schedule labels, pause and resume availability, reserve and dispute rule labels, grace and hold copy, and version, with default fee percent for payout on request and below-minimum payout set at 2%. FeatureFlagConfig carries remixesEnabled, phase label, delivery phase state, user-facing disabled message, and version. CreateStylePreset carries id, label, palette, descriptor, seedPrompt, swatches, thumbnailAsset, referenceMedia, displayOrder, enabled, and configVersion. PromoStudioConfig carries environment presets, photo style presets, lens presets, duration options, aspect options, batch-size labels, credit and cost display, top-up availability, custom environment upload availability, and config version.
The remaining configuration resources cover the shell and shared infrastructure. ShellConfig carries configured language options, locale and currency options, navigation items, feature availability, cart and account indicators, social links, legal links, newsletter configuration, and cookie-management entry metadata. SearchConfig carries enabled scopes, scope labels, minimum query length, debounce interval, recents policy, voice-search availability, result limits, and config version. TranslationConfig carries supported languages, default language, fallback order, provider availability, glossary version, asynchronous job policy, public fallback policy, and feature gate or config version. SecurityLimitConfig carries public read limits, auth attempt limits, upload limits, search query and page limits, text, prompt, comment, and support-message lengths, job concurrency limits, provider timeout and retry budgets, webhook body size, and rate-limit response metadata. ReliabilityConfig carries readiness dependency classes, maintenance state, provider circuit-breaker thresholds, provider retry budgets, transaction retry limits, worker drain timeout, job max age and attempts, backup, recovery-point and recovery-time objectives, and degraded-mode flags. ObservabilityConfig carries enabled analytics provider mode, event dictionary version, analytics consent classes, telemetry retention by data class, log redaction profile, alert notification channels, support service-level targets, beta dashboard export policy, and environment-specific sampling rules. InterestReservationPolicyConfig carries enabled state, non-binding disclaimer version, duplicate policy, cancellation policy, per-user, per-listing, and per-IP limits, eligible listing states, geography policy, conversion-invite policy, and user-facing blocked reasons.
MediaAsset supports raster and reference media assets, model and source assets, profile and avatar media, listing media, finished-build photos, and Promo Studio generated or custom environment media. Raster accepted formats are defined separately for raster and reference slots. Model and source accepted formats are glb, gltf, obj, and stl only, and model and source upload validation enforces maxSizeBytes of 104857600 (100 megabytes) unless a later approved configuration changes the limit. CropState carries x, y, width, height, rotation, zoom, and applied. UploadValidation carries accepted, reason, maxSizeBytes, actualSizeBytes, format, kind, and message. MediaUploadRequest distinguishes upload purpose and kind so model and source uploads are validated only against GLB, GLTF, OBJ, and STL, while raster, reference, profile, listing, and Promo Studio environment uploads use their own approved raster validation rules.
Upload validation data carries normalised filename, declared format, detected format or signature where available, content type where available, size, validation status, rejection reason, scan and quarantine status, and signed action expiry. MediaAsset also carries enough lifecycle state to repair object-storage mismatches: object key or safe storage reference, visibility, checksum where available, upload session reference, validation status, artifact source job, cleanup eligibility, regeneration source reference, and missing-object or deleted-object state where repair is needed.
DesignDraft carries id, ownerId, stage, title, brief, referenceText, category, tags, media, projectionSet, modelTryouts, selectedModelTryoutId, blockKit, publishSettings, saveStatus, lastEditedAt, and resumePriority. The title, brief, referenceText, and user-authored publish copy fields are translatable user-generated content. Allowed draft stages are describe, projections, model, blockKit, and savePublish. TagSuggestion carries label, source, selected, and confidence when generated. Describe data includes selected CreateStylePreset references and any style-applied prompt or reference-media changes when the user applies a preset.
Projections data is structured around six faces. ProjectionSet carries the six faces front, back, right, left, top, and bottom, with front marked as required. ProjectionFace carries face, required, active, sourceAssetId, generatedAssetId, sourceLabel, history, zoom, status, lastRestoredHistoryId, and optionalMissingAllowed. ProjectionHistoryEntry carries id, face, assetId, sourceAssetId, createdAt, action, prompt, selected, and restorable.
The 3D model stage stores both options and tryouts. ModelGenerationOption carries id, label, description, estimatedOutputLabel, cost, and a configuration version. ModelTryout carries id, optionId, label, status, progress, previewAssetId, modelAssetId, outputFormat, sizeLabel, stats, sourceProjectionSetId, createdAt, and feedbackSummary. The outputFormat supports GLB and GLTF-compatible output references. ModelGenerationFeedback carries id, draftId, tryoutId, userId, qualityRating, usable, issueCategories, comment, submittedAt, and pipelineTrainingUseAllowed.
The block-kit stage stores the kit and the bill of materials. BlockKit carries id, jobId, cost, status, summary, bomGroups, assemblySteps, selectedModelTryoutId, and error; the summary carries SKU count, part count, estimated cost, estimated build time, and currency display fields. BomGroup carries groupName, items, partCount, subtotal, and search-and-filter metadata. BomItem carries sku, name, color, quantity, unitPrice, subtotal, thumbnail, and availabilityLabel. AssemblyStep carries stepNumber, title, instructions, media, parts, estimatedMinutes, and payload.
Publishing collects the visibility and ownership decisions. PublishSettings carries visibility, allowRemixes, remixesEnabled, disabledRemixMessage, ownershipAcknowledgement, licenceGrantVersion, intendedUse, safetyGate, future-phase royaltyPercent, isCommunityGift, basePrice, listedPrice, validationMessages, draftSavedAt, and publishedAt. Allowed visibility values are private, unlisted, and public, and the royaltyPercent field accepts 0 to 25 inclusive only where a future monetisation phase exposes the control.
Listing carries id, slug, ownerUserId, ownerDisplay, creatorProfileRef where active, designOwnership, licenceGrantVersion, title, description, media, indicativePrice, future-phase baseKitPrice, future-phase royaltyPercent, future-phase listedPrice, visibility, allowRemixes, remixesEnabled, disabledRemixMessage, status, availability and orderability metadata, interestReservationState, interestSummary, phaseA5PreorderEligibility, tags, category, intendedUse, safetyGate, moderationState, kitSummary, assemblySummary, reviewsSummary, questionsSummary, savedByViewer, shareUrl, reportState, and product-detail variant references. User-authored title, description, and tags are translatable user-generated content.
ListingCard carries image, title, owner and creator display, indicative price or price-unavailable state, saved state, tags and badges, availability and status markers, interest count or label where configured, block count where shown, rating, social-proof, and order metrics where configured and phase-appropriate, and enough metadata for the home and gallery rails. ListingVariantSurface identifies alternate product-detail mock variants with surfaceId, sourceFile, contentBlocks, and commercePanel.
DesignerProfile carries public identity, banner, avatar, and media, verified state, handle, name, location where shown, pronouns where shown, joined date, availability, bio, social and contact fields, follow, notify and share state, follower counts where shown, listings, pinned kit, portfolio, collections, reviews, inspirations and recommendations, section visibility, saved and follow state, and owner analytics fields when viewed by the profile owner. Bio, collection descriptions, and inspirations are translatable user-generated content; handle, name, social and contact fields, and location are not automatically translated. Review and Question resources carry listing reference, author display data, rating where shown, text, status, created time, and response data where shown; review text, question text, replies, and answers are translatable user-generated content.
Search is exposed through two resources. SearchResult carries id, type, scope, title, summary, snippet, thumbnailAsset, avatarAsset, targetUrl, resourceRef, highlightRanges, metadata, and score. SearchResponse carries query, enabled scopes, selected scope, scope counts, result list, suggestions where available, no-results copy, and config version. DesignerCollection carries profile reference, title, description, listing references, display order, and visibility. DesignerInspiration carries profile reference, title and body or media reference, related designer and listing references where shown, display order, and visibility.
InterestReservation carries id, a stable reference, userId or session reference, listingId, listingOwnerUserId, status, nonBindingAcknowledged, acknowledgementVersion, indicativePriceSnapshot, jurisdiction, intendedUse, sourceSurface, campaign, source and UTM metadata, duplicate and reuse metadata, createdAt, updatedAt, cancelledAt, cancelReason, conversionInvite, and convertedPreOrderId where applicable. Status values include active, cancelledByUser, cancelledByDomiDo, blocked, invitedToPreorder, convertedToPreOrder, and expired. The nested conversionInvite carries invite status, invited-at, expires-at, invited-by, eligibility snapshot, gate versions, buyer fresh-consent state, declined-at, and safe blocked reason. InterestReservationSummary carries active count, cancelled count, listing refs, newest reservation, conversion-invite count, and needs-action count for dashboard and header use. AdminInterestReservationView carries filters and aggregates by listing, owner, source, geography, eligibility state, cancellation state, and Phase A.5 conversion invite state.
PromoStudioProject carries listingId, ownerId, scene, generations, assets, creditSummary, configVersion, createdAt, updatedAt, and lastOpenedAt. PromoScene carries environmentId, optional customEnvironmentAssetId, lensId, horizon, sunPosition, objectPosition, objectScale, objectRotation, objectYaw, cameraRig, sourceModelAssetId, sourceHeroMediaId, footprintLabel, and reset and default metadata. PromoEnvironmentPreset carries id, label, description, previewAsset, enabled, and configVersion, and PromoPhotoStylePreset carries id, label, description, enabled, and configVersion. PromoGenerationJob extends Job with listingId, projectId, jobKind, sceneSnapshot, prompt, styleId, sourcePhotoAssetId, motionPrompt, durationSeconds, aspectRatio, configVersion, and resultAssetIds; the jobKind values are promoPhoto and promoVideo. PromoAsset carries id, listingId, projectId, type, mediaAsset, sourceJobId, sourcePhotoAssetId, sceneSnapshot, prompt, styleId, motionPrompt, durationSeconds, aspectRatio, kept, listingGalleryState, downloadState, createdAt, and archivedAt. PromoCreditSummary carries available balance, monthly or period allowance where configured, cost labels for photo and video generation, top-up link or action availability, and config version; demo credit counts from the mock are not encoded as truth.
Cart and checkout data are not required for Phase A interest reservations. They become active for Phase A.5 invited no-capture pre-orders and Phase B charged orders.
Cart carries id, userId, items, subtotal, deliveryEstimate, vat, discounts, total, currency, savedForLater, checkoutState, validationMessages, and configVersion. CartItem carries id, listingId, title, owner and creator display, thumbnail, quantity, unitPrice, lineTotal, kitSummary, availability, validationMessages, and removable and savable flags. SavedCart carries id, userId, cartSnapshot, checkoutDraft, itemCount, displaySummary, lastUpdatedAt, resumeAvailable, discardAvailable, staleReason, and the configuration versions used for jurisdiction, VAT, delivery, and supported-card copy.
CheckoutState carries id, cartId, savedCartId, step, phase, commitmentType, bag, delivery, payment, review, confirmation, jurisdiction, stripeCheckout, agreementAccepted, validationMessages, savedAt, and configuration versions. Allowed checkout steps are bag, delivery, payment, review, and confirmation. Address carries name, line fields, city, region, postcode, country, phone where shown, delivery instructions where shown, and saved and default flags; country values are validated against JurisdictionConfig. DeliveryOption carries id, label, description, price, deliveryWindow, requiresCollectionPoint, and jurisdictionAvailability.
Payment data is intentionally thin on the platform side. PaymentMethodReference carries id, type, brand, last4, expiryLabel, holderName, isDefault, verificationStatus, provider, and displayLabel. The provider is Stripe. Card payment references store masked Stripe card data only, and accepted-card display copy derives from JurisdictionConfig.stripeSupportedCardCopy. StripeCheckoutState carries sessionId, setupIntentId, paymentIntentId, clientSecret or redirect reference where applicable, mode, status, supportedCardCopy, jurisdictionCode, amount, and expiresAt; the mode distinguishes Phase A.5 SetupIntent verification from Phase B payment capture.
The review and confirmation surfaces have their own data shapes. CheckoutReview carries item totals, delivery or future-delivery assumptions, jurisdictional VAT, expected final total, supported-card copy, unsupported-jurisdiction message when applicable, Stripe verification or payment state, Phase A.5 no-capture acknowledgement, editable bag, delivery and payment summaries, agreement state, and validation messages; it does not include post-checkout wait-time data or promised ship-date data. PromoCode carries code, status, discount, message, and source surface. CheckoutBag carries cart items, saved-for-later items, subtotal, discounts, delivery estimate, jurisdictional VAT estimate, total, stale item messages, and save-for-later or save-bag state. CheckoutDelivery carries selected saved address or manual address, jurisdiction code, supported or unsupported jurisdiction state, selected delivery option, collection point where required, delivery instructions, phone where required, and validation messages. CheckoutPayment carries selected saved Stripe payment reference, Stripe checkout state, save-card choice, billing address mode, supported-card copy, promo code, payment readiness, and validation messages. CheckoutConfirmation carries commitmentType, Phase A reservation reference where applicable, Phase A.5 pre-order reference where applicable, Phase B order reference where applicable, receipt and contact email, Stripe SetupIntent verification or payment state, no-capture acknowledgement, cancellation action, fulfilment readiness only when Phase B order fulfilment is active, next-step timeline, summary, receipt and invoice links only for captured orders, social-sharing state, dashboard link, and keep-browsing action. CheckoutValidationMessage carries field path, code, severity, message, blocking state, and remediation action where available.
Checkout and reservation requests are typed by named schemas: InterestReservationCreateRequest, InterestReservationCancelRequest, CheckoutDeliveryUpdate, CheckoutPaymentUpdate, StripeSetupIntentRequest, StripeCheckoutSessionRequest, PromoCodeUpdate, CheckoutReviewRequest, and CheckoutConfirmRequest, each including the relevant reservation or checkout id, source step, idempotency key, and required fields. CommitmentType values are phaseAInterestReservation, phaseA5PreOrder, and phaseBOrder. StripeSetupIntentRequest carries checkoutId, sourceInterestReservationId, conversionInviteId, returnUrl, cancelUrl, selectedPaymentReferenceId, buyerFreshConsent, noCaptureAcknowledged, and idempotencyKey. CardVerificationStatus values are notStarted, requiresAction, verified, failed, and cancelled.
PreOrder is Phase A.5 active and carries id, reference, sourceInterestReservationId, conversionInviteId, userId, listingOwnerUserId, items, status, cardVerificationStatus, stripeSetupIntentId, expectedPrice, buyerFreshConsent, noCaptureAcknowledged, gateVersions, cancellationEligibility, cancelledAt, supportConversationRef, dashboardSummary, attribution, createdAt, and updatedAt. The PreOrder.status values are draft, verificationPending, verified, verificationFailed, cancelled, conversionReady, and convertedToOrder. PreOrderAttribution carries listing id, design owner id, source interest reservation id, campaign, source and UTM metadata, projected entitlement, and attribution confidence and source.
Order is Phase B active and carries order reference, source pre-order reference, source interest reservation reference, user, items, status, payment status, fulfilment readiness status, delivery status, delivery address, selected delivery option, shipments and parcels, tracking detail, delivery preferences, notification summary, totals, receipt and invoice references, cancellation eligibility, return eligibility, replacement eligibility, dispute status, trust restriction reference, messages, actions, and timeline. OrderPayment carries charge amount, jurisdictional VAT, refund amount, masked Stripe payment reference display, retry eligibility, receipt URL, invoice URL, and payment status. FulfilmentReadiness carries state, reason, missingBlockSkus, productionReadinessPhase, emailNotificationPending, and shipDatePromised; the shipDatePromised field is false for pre-orders and production-readiness waits.
OrderAction carries type, available, deadline, form, status, and result message for cancel, address change, delivery preference, return, replacement, dispute, support contact, and payment retry actions. ReturnAssessment carries return reason, condition findings, damaged blocks, wear signs, diminished value assessment, change-of-mind flag, fee amount, fee reason, user notification, dispute status, and evidence attachments. SupportConversation carries id, requester reference, subject, category, priority, status, source surface, related resource refs, assignee display and reference, last customer message timestamp, last staff response timestamp, first-response due timestamp, escalation flag, unread counts, message preview, attachment summary, translation summary, linked trust, dispute and reliability refs, and audit refs for staff changes. SupportMessage carries id, conversation id, sender role, author display, body, source language, translation summary, attachments, internal or staff-only flag, created-at timestamp, edited and deleted metadata, delivery and read state, and safe moderation and report state.
The build companion and its photos round out the post-delivery surface. BuildCompanion carries orderId, entrySource, offlineReady, currentStep, steps, progress, paused, stuckHelp, parallelBuildGroup, finishedPhotos, shareToProfile, designerFeedbackAllowed, and buildExperienceRating. BuildCompanionStep carries stepNumber, requiredBlocks, joinPattern, preview3d, timerEstimate, finishedGroupPhoto, animation, stuckFailureModes, and completedAt. FinishedBuildPhoto carries assetId, kind, caption, profileVisible, designerFeedbackVisible, and validation state.
Shipment and order-line data is typed and rich. Shipment carries id, orderId, status, carrierDisplay where shown, trackingDisplay or safe tracking reference, parcels, deliveryOption, deliveryWindow, and user-facing messages. Parcel carries id, shipmentId, status, trackingDisplay or safe tracking reference, items, weightOrSizeLabel, and timeline events. OrderLine carries id, orderId, listingId, title, designerDisplay, quantity, thumbnail, kitSummary, unitPrice, lineTotal, fulfilmentStatus, returnEligibility, replacementEligibility, and per-line action availability. OrderNotificationItem carries id, orderId, category, severity, title, body, read, createdAt, readAt, actionRef, and timelineEventRef. ShipmentTrackingDetail carries orderId, shipments, parcels, currentStatus, trackingDisplay, safeTrackingRef, trackingStops, etaDeltas, lastUpdatedAt, and user-facing messages. TrackingStop carries id, label, status, occurredAt, locationDisplay, current, completed, and safe metadata. EtaDelta carries id, previousEtaLabel, newEtaLabel, reason, changedAt, and user-notification state. DeliveryPreference carries orderId, safePlace, neighbourName, neighbourAddress, holdOrCollectionChoice, signaturePreference, deliveryInstructions, available, validationMessages, and updatedAt.
The order-action requests are all typed too. OrderActionForm carries orderId, actionType, available, reasonUnavailable, fields, requiredAttachments, validationMessages, idempotencyKey, status, and result message. ReturnRequest carries orderId, lineItems, reason, conditionDescription, refundPreference, evidenceAttachments, submittedAt, status, and the linked return assessment. ReplacementRequest carries orderId, lineItems, reason, quantity, description, evidenceAttachments, submittedAt, and status. OrderReportRequest carries orderId, category, description, lineItems, evidenceAttachments, submittedAt, support conversation reference, and status; report categories are configuration or support policy data. DisputeRequest carries orderId, disputeType, challengedDecisionRef, reason, description, evidenceAttachments, submittedAt, support and dispute references, and status. PaymentRetryRequest carries orderId, selectedStripePaymentReferenceId, stripeCheckoutSessionId or Stripe handoff reference, savePaymentReference, billingAddress, idempotencyKey, and retry status. OrderMessage carries id, orderId, senderRole, body, attachments, visibility, createdAt, readBy, reportStatus, and linked support and dispute references.
DesignerListing, or the listing-owner editor aggregate, extends Listing with edit state, owner metadata, unsaved and versioned save state, editable section map, platform-read-only section metadata, status notices, moderation state, similarity matches, performance metrics, Phase A interest metrics, future ad-boost data, future royalty settings, messages, action items, and publish controls. RoyaltySetting carries royaltyPercent, minPercent, maxPercent, basePrice, listedPrice, designerMarkup, amountIncludesVat, isCommunityGift, and splitRules. AdBoost carries enabled, weeklyBudget, budgetConfig, spendToDate, deductedFromRoyalty, status, and performance metrics where visible.
DesignerDashboardSummary carries attributed interest reservations, attributed pre-orders, projected sales, projected royalties and entitlements, captured sales, earnings, fees, payout due, payout readiness, payout balances, payout events, statement period, action queue count, message count, listing metrics, disabled remix summary, and export links. PayoutAccount carries Stripe Connect state, identity and KYC state, safe requirement labels, payout options, selected payout option, payout schedule, auto-payout pause state, tax region, VAT number, UTR, minimum payout status, payout-on-request availability, below-minimum payout handling, payout readiness status, payout config version, and statement archive. PayoutOption carries option type, label, feePercent, minimumPayoutRule, eligibilityDelayDaysAfterDelivery, availability, and config version.
RoyaltyEvent or entitlement event carries pre-order or order reference, listing, design owner, royalty source, projected or captured amount, amountIncludesVat, accrual date, delivery date, earliestPayableDate, payout eligibility state, payout release eligibility, return fee or reversal adjustment state, split participants, and statement reference; Phase A interest reservations do not create payable entitlement events. RemixSplitProposal carries original listing, remix listing, participants, split percentages, message, status, disabledReason, and action history. In Phase A the disabled reason indicates remixes are disabled. Statement carries period, gross sales, fees, boost spend, payout fees, royalty total, return adjustments, payout total, export formats, archive status, and the config versions used for calculations.
DesignerSale carries interest, pre-order, or order reference, listing, buyer display alias, status, sale value, projected royalty amount, captured royalty amount, amountIncludesVat, verifiedOn, capturedOn, clearedOn, payoutId, paidOn, lifecycle, dispute, and statement references. DesignerSaleDispute carries id, sale or order reference, reason label, amount, openedAt, evidenceDueAt where configured, state, reserveImpact, handling status, outcome, royaltyAdjustment, and provider and config metadata safe for display. PayoutBalance carries available, pending, inTransit, reserved, currency, display values, and config and version metadata. PayoutSchedule carries cadence, anchor, minimumPayout, autoPayoutPaused, payoutOnRequestAvailable, belowMinimumBehavior, notification preferences, and config version. PayoutTransfer carries payout id, date, amount, status, masked method display, arrival or expected arrival, failure reason label, retry availability, Stripe handoff reference, included royalty events, and release eligibility; transfers are preview and readiness data in Phase A.5 and actual money movement only after Phase B eligibility.
ReserveLedgerEntry carries id, date, kind, amount, reason, linked sale or dispute reference, status, and config version. PayoutActivityEvent carries id, kind, timestamp, title, body, linked payout, linked sale or dispute, notification category, read state, and source config version. TaxStatementExport carries tax year or period, supported export formats, generated and export status, redacted tax identifiers, and access metadata.
DesignerListingEditor carries listing, owner edit state, current version, last saved and published metadata, dirty fields, editable sections, platform-owned copy sections, validation messages, unsaved-leave guard state, save, apply and discard actions, buyer preview, and config version. ModerationFlag carries id, listingId, category, severity, verdict, rating, location, excerpt, reason, visibilityRestrictions, safeEvidenceRef, rerunEligibility, rerunCost, and configVersion. SimilarityMatch carries id, listingId, matchedListingRef, score, reason, gatingState, requiredAction, and safe preview metadata. ListingPerformanceMetrics carries time range, views, saves, follows, interest reservations, Phase A.5 pre-order signals, cart, order and conversion signals where active, revenue and royalty context where allowed, ad impressions, clicks, cost-per-click, acquisition guidance, and config version. ActionQueueItem carries id, kind, resourceRef, priority, status, title, message, availableActions, dueAt, and resolution metadata.
The designer-engagement resources cover review, Q&A, and message workflows. ReviewReply carries id, reviewId, listingId, designerId, draftText, postedText, status, assistiveActionRefs, createdAt, updatedAt, postedAt, deletedAt, and moderation and report state. QuestionResponse carries id, questionId, listingId, designerId, draftText, postedText, status, createdAt, updatedAt, postedAt, and designer and verified display markers. FaqCandidate carries id, listingId, questionId, answerRef, title, body, status, createdBy, createdAt, and target content workflow reference; creating a FAQ candidate does not mutate admin-managed Help content directly. DesignerMessageThread carries id, listingId, claimId, participants, priority, status, pinned, unreadCount, nodes, internalNotes, availableActions, and linked order, support, and dispute references. MessageThreadNode carries id, threadId, parentId, senderRole, body, attachments, internal, suggested, createdAt, updatedAt, readState, and report status. ModerationReport carries id, resourceType, resourceId, reason, description, reporterId, status, createdAt, resolvedAt, and safe moderation notes. DesignerClaimAction carries id, claimId, listingId, orderId, actionType, reason, message, requestedPhotoTypes, refundReference, replacementReference, escalationReference, status, createdAt, and resolution metadata.
HelpTopic carries id, group, label, display order, Docusaurus navigation and sidebar metadata, publication state, and admin-edit metadata. HelpKind carries id, label, accent and display metadata, Docusaurus category and tag metadata, and publication state. HelpArticle carries slug, kind, topic, title, summary, readMinutes, updated, author, publicationState, version, Docusaurus document reference or static path, source format, bodySections or source content reference, toc, related, backlinks, and admin audit metadata. Help article slugs, body sections, source documents, source facts, shipping copy, material copy, designer application copy, and story copy are content data controlled by administrators, not fixed data requirements.
HelpHubConfig carries featured article slots, popular article slots, topic groups, article kind metadata, Docusaurus sidebar and navigation metadata, search snippets, and related and backlink behaviour. HelpContentAdminAction carries admin actor, action type, target content, prior publication state, new publication state, Docusaurus publication or build reference, version, timestamp, and reason. FooterConfig carries locale and currency options, social links, legal links, VAT display, newsletter fields, cookie controls, sitemap link, and data-request link. CookiePreference carries category, enabled, required flag, updatedAt, and version. NewsletterSignup carries email, locale, consent state, source surface, and status.
Help comments, comment replies, support conversation messages, report and dispute notes, and designer and buyer message-thread nodes are translatable user-generated content; authorisation and moderation state are preserved identically for source and translated variants. HelpComment carries id, articleSlug, parentCommentId, authorDisplay, authorRoleTag, body, status, likeCount, likedByViewer, replyCount, createdAt, updatedAt, moderationStatus, and report state. HelpCommentReport carries id, commentId, reason, description, reporterId, status, createdAt, and moderation result. HelpPublicationArtifact carries id, target surface, Docusaurus build or export reference, included content versions, generatedAt, status, publishedBy, failure summary, and audit metadata.
Enum values are closed to the values defined here unless a later approved requirement updates them. Configurable values are not overwritten by hard-coded frontend defaults — that rule covers AI generation costs, Promo Studio costs and options, payout numbers, payout schedules, reserve and dispute rules, supported jurisdictions, VAT behaviour, delivery availability, and Stripe-supported card copy. Delete, cancel, return, refund, payout, publish, interest reservation create and cancel, Phase A.5 pre-order verification and cancellation, trust restriction, model feedback, and help-content operations retain audit-ready state transitions in domain data.
Payout, tax, payment, and order data do not include raw sensitive provider data that stays with Stripe or is only displayed as masked references. Promo Studio private assets are not included in public listing responses until listingGalleryState indicates the asset has been added to public listing media. User-visible interest reservation, commerce, pre-order, order, designer engagement, and Help discussion mutations use typed domain data; opaque generic payloads are not acceptable for reservations, saved carts, checkout steps, pre-order actions, order actions, order notifications, tracking, delivery preferences, designer review replies, Q&A replies, message reports, claim actions, or Help comments. Public and private API security, idempotency, rate limit, CSRF, webhook signature, payload size, and provider budget decisions are represented by typed request and response data or configuration, not by undocumented middleware-only behaviour. Reliability behaviour is represented by typed health, dependency, job, webhook, audit, media, and error data; maintenance, degraded mode, provider outage, search fallback, object-storage mismatch, and restore-and-reconciliation state do not exist only as undocumented logs.