This page specifies the audit events the DomiDo platform records — what each event contains, when it is emitted, how long it lives, and who is allowed to read it. Audit logging is deliberately distinct from the other observability streams the platform produces: technical logs trace the runtime behaviour of services, product analytics capture user-behaviour signals for founder learning, support content holds the conversation history between users and staff, and beta feedback is a structured product-feedback resource. Audit events are required only where accountability, security, compliance, or material business-state traceability makes the record valuable. A product-analytics event may help founders understand activation without ever becoming an audit record; an audit event, by contrast, is the durable trace that explains who touched what, when, and with what outcome. This page describes event content and retention intent for business traceability; it does not name a logging vendor or a storage product, and the implementation is free to evolve.
Every audit event carries the same required fields: an eventId that uniquely identifies the event, an eventType that names the action class, the actorId and actorRole that identify the actor responsible, a resourceType and resourceId for the resource the action touched, the action itself, the result, a timestamp, the sourceSurface that produced the action, the requestId that correlates the event with surrounding request and job records, and a summary that captures the human-readable meaning of what happened. Events involving changed data carry before-and-after values for non-sensitive fields, or a change summary when full values should not be recorded; failed security-sensitive operations are logged with a failure reason code and no sensitive secret values. The redaction posture is consistent across event types: raw card data, OAuth secrets, payout account secrets, full provider credentials, private media URLs where they are not needed, and full tax identifiers are redacted unless an authorised audit use specifically requires the value.
Events driven by configuration include the relevant configuration key or version whenever the decision under audit depends on configuration — supported jurisdiction, Stripe card support, AI generation cost, Promo Studio options or costs, the feature phase gate, payout fee or schedule, reserve or dispute rules, fulfilment-waiting state, the disabled-remix state, or Help content publication state — so that a later reader can reconstruct the policy that produced the outcome. Audit event metadata also includes the data class, the retention class, the correlation or request identifier, and the redaction profile. Audit events do not store unrestricted analytics properties, raw technical logs, raw LLM prompts or responses, or full support or beta free text; where a specific authorised audit purpose requires it, a redacted excerpt or reference may be stored, but the unbounded raw text never is.
The authentication audit covers OAuth sign-in start, success, failure, account creation, account linking, and sign-out, with provider values constrained to Google, Apple, and Facebook because no other identity provider is exposed. Account-state changes are logged across the full lifecycle: profile updates, avatar upload and removal, locale and currency updates, notification-preference updates, notification-item read and mark-all-read events, privacy changes, cookie-preference changes, account security changes, session revocation, data-export requests, pause-account and pause-shop requests, and delete-account requests. Saved-address create, update, delete, and default-change events are logged, and saved Stripe payment references are logged on creation and deletion with masked display data only — the brand, label, last-four digits where present, expiry label, verification state, and provider display — but never the underlying card number.
Trust restrictions sit slightly outside ordinary account events because they govern what a user is allowed to do on the platform. Blacklist and restriction create, update, removal, internal review, user-challenge, support-ticket link, dispute link, and final-resolution events are all logged. Trust-restriction events record the reason category and the decision summary; they explicitly do not store abusive content or unnecessary private detail beyond what the audit need requires.
The upload and create surfaces produce a dense audit trail because each step in the create wizard either advances a draft or commits expensive worker time. Media upload validation accepted and rejected events log the format, size, kind, the configured limit that was applied, and the rejection reason; crop updates log the asset identifier and the crop metadata without storing raw image contents. Design draft create, resume, update, stage change, save, and any delete-or-archive events that are implemented are all audited, so a draft's history is reconstructable. Projection face events distinguish the compulsory front face from the optional faces and cover set, generate-start, generate-complete, generate-failure, optional autofill, history-restore, and source-reuse. Model audit events cover the job start, the generation option selected, tryout completion, tryout failure, changes to the selected tryout, and the configured generation cost that was applied. Model generation feedback submissions log the tryout identifier, the feedback categories, the quality assessment, and the usability flag; free-text comments are redacted or access-limited if they contain personal data. Block-kit events cover the job start, model validation, voxelisation start, complete, and failure, blockification start, complete, and failure, the Bill-of-Materials and cost update, the assembly-and-export payload update, artefact persistence, retry, cancellation, dead-letter, and the configured cost application.
Long-running jobs as a class — projection, model, block-kit, Promo Studio, text assist, publication, embedding, notification, and fulfilment-sync — log queued, leased-and-started, progress-milestone, completed, failed, retried, cancelled, and dead-lettered events. Each entry carries the job identifier, the job type, the resource reference, the actor or system actor, the attempt number, safe provider and configuration metadata, and the audit correlation identifier so the job trace lines up with the surrounding request and resource trace. Publish setting changes log visibility, the ownership-and-licence acknowledgement, the intended-use-and-safety gate, the disabled-remix state, and the future-phase royalty and price controls where they are active; draft publish success and publish-validation failure are both audited. Create style-preset application logs the draft identifier, the preset identifier, the prompt-and-reference-media change summary, and the configuration version of the preset list.
Translatable user-generated text produces its own audit stream because translation is a data-processing event in its own right. The audit logs translatable-source-text creation or update with the actor, the resource reference, the field path, the source language, the target-language set, the visibility, the translation configuration version, and whether translation was requested, skipped, or blocked. The text translation job itself is logged for queued, started, completed, failed, retried, cancelled, and marked-stale states; entries include safe provider, model, and configuration identifiers and cost metadata where available, but they never include raw provider secrets or unauthorised private text. Translation publication and search-index eligibility changes, moderation blocks, and fallback-to-source events are logged where they affect public content or support and audit workflows.
Listing-lifecycle events cover listing create, update, publish, unpublish, visibility change, status change, media change, price-and-royalty change, and disabled-remix setting display changes. Engagement and moderation events cover save and unsave listing, follow and unfollow designer, share action, question creation, and review-and-question moderation where it is implemented. Product-detail variant selection or configuration changes are logged when a surface-specific variant is served, so the audit captures which variant a user actually saw. Promo Studio launch attempts on a listing are audited including the authorisation result, so unauthorised attempts are visible as failures rather than invisible no-ops. The listing editor logs save, apply, and discard, platform-owned copy-change requests, moderation-rerun requests, similarity-match acknowledgement, and analytics-or-ad-panel configuration interactions with the configuration version where relevant.
The commerce audit trail is organised so that each phase produces an unambiguous record of what happened and what did not. Phase A interest-reservation events log creation, duplicate or reuse, cancellation request, cancellation success or failure, the non-binding acknowledgement version, the blocked state, conversion-invite creation, invite expiry, and conversion to a Phase A.5 pre-order. Interest-reservation audit events explicitly record that no card, charge, order, invoice, receipt, shipment, payout release, or legal pre-order occurred, so the absence of those side effects is itself part of the auditable record. Cart events cover item add, quantity update, remove, save-for-later, save-cart, resume-saved-cart, discard-saved-cart, promo apply and remove, and checkout start.
Checkout events log the delivery updates, the selected jurisdiction, the selected delivery method, collection-point selection, Stripe payment-reference selection, Stripe SetupIntent creation and update, Stripe checkout or payment session creation and update, review validation, and confirmation. Stripe card-verification and payment-state changes are logged without raw card data. Jurisdiction-support decisions, jurisdictional Value-Added-Tax calculation version, and the supported-card-copy configuration version are logged, and unsupported-jurisdiction checkout blocks and coming-soon notification display are audited explicitly so that blocked attempts are visible. Phase A.5 pre-order events cover creation, card-verification success and failure, the no-capture acknowledgement, the gate versions, the source interest reservation, cancellation request, cancellation success and failure, expiration, conversion-readiness change, and conversion to a Phase B order. Pre-order audit events record SetupIntent and payment-reference identifiers only as safe Stripe references, and they explicitly record that no capture, receipt, invoice, shipment, or payout release occurred.
Phase B order events log order creation, status changes, fulfilment-readiness changes, delivery-status changes, payment retry, charge success and failure, refund, receipt access, and invoice access. The fulfilment-state transitions are logged distinctly: immediate fulfilment, waiting-for-blocks, and waiting-for-production-readiness all produce their own audit entries, and the production-readiness wait logs the email-notification state but never a promised ship date. Order actions — cancellation request, cancellation success and failure, address change, delivery-preference change, return request, replacement request, issue-report request, dispute request, order-message submission, and support-conversation creation — are each audited as a discrete event with eligibility, validation, and outcome.
Return assessment produces a focused audit substream. The platform logs the create and update of an assessment, the damaged-block finding, the wear-sign finding, the change-of-mind reason, the diminished-value finding, the fee or deduction amount, the user notification, and the dispute or challenge result. Royalty accrual, payout eligibility, return-fee or reversal adjustment, and statement impact tied to a Phase B order return or refund state are all audited so the designer-facing impact of a return is reconstructable. Build-companion events cover open, progress update, step completion, stuck-help open, support escalation, pause and resume, finished-build photo upload, profile share, designer-feedback permission, and build-experience rating; build-companion audit events do not store private photo URLs beyond authorised media references. Tracking-detail access and update are logged where audited, alongside ETA-delta notification, parcel state changes, and order-notification create-read-and-mark-all-read events; tracking events carry the order identifier and a safe tracking reference only.
Designer listing edits, royalty-percent changes, Value-Added-Tax-inclusive listed-price recalculation, moderation-rerun jobs with their configured cost, similarity-and-uniqueness gating changes, ad-boost budget changes, ad-boost activation and deactivation, and boost-spend updates are all audited. Designer dashboard export actions — statement CSV or PDF downloads where active, and statement-preview access where Phase A.5 is active — are logged so any disclosure path leaves a trace.
Payout-account events cover the connect start, connect success and failure, payout-readiness change, payout-option change, payout request, below-minimum payout request, Value-Added-Tax number update, Unique Taxpayer Reference update, and tax-region update. The configured payout fee and threshold versions used for payout-on-request, below-minimum payout, and payout-eligibility calculations are logged so the policy in force at the moment of the decision is recoverable. Know-Your-Customer state changes received through payout-account status updates are logged without storing sensitive provider payloads. Phase A disabled-remix action attempts, disabled-message display, and any legacy or mock remix-item resolution that does not affect payouts are audited so future remix policy can be reconstructed. Designer engagement events include message reply, message report, claim action, review reply create-update-and-delete, question reply create and update, FAQ candidate creation, and action-queue item resolution.
Promo Studio produces its own audit stream covering scene create, update, and reset, custom-environment upload attachment, and source-model or media selection. Photo and video jobs each log their start, completion, failure, the configured cost applied, source-photo selection for video, result-asset creation, and retry. Promo Studio asset actions — keep and star toggle, download, download-all, archive and remove, animate-from-photo, and add-to-listing-gallery — are all audited. Designer sale lifecycle changes log every state the sale passes through, including attributedPreOrder, projectedRoyaltyCreated, reserved, sold, disputed, refunded, captured, cleared, bundledIntoPayout, and paid where present. Payout-movement events cover schedule changes, auto-payout pause and resume, notification-preference changes, payout request, below-minimum payout request, payout-release blocks, payout-transfer status changes, failed-payout resolution and retry, and tax-statement export. Reserve hold-and-release entries and dispute-state changes are logged with the linked sale or order, the amount, the reason label, the status, the configuration version, and the statement-and-payout balance impact.
Support-conversation creation, user-visible support replies, admin and staff replies, internal-note creation, status change, priority change, assignment change, escalation-flag change, service-level override, article feedback where implemented, Help comment create, reply, like, unlike, and report where implemented, and Help contact-form submission are all audited. Help comments, support messages, and report-or-dispute notes that trigger translation also emit the translation audit events described earlier, so the multilingual handling never escapes the audit trail.
Admin Help-and-Workshop content audit covers article create, update, publish, unpublish, archive, delete, reorder, topic update, content version change, Docusaurus publication trigger, and the Docusaurus publication result. Non-admin attempts to modify Workshop or Help content are logged as authorisation failures rather than dropped silently, so any probing of the admin boundary is visible. Cookie-preference updates, privacy-request submissions, data-request submissions where implemented, and newsletter-signup consent are audited as legal-and-privacy events. Audit retention for payout, tax, order, and Help-admin events supports business traceability unless a later approved compliance requirement changes it.
Beta operations produce audit events for product-event dictionary changes, analytics-provider configuration changes, telemetry-retention changes, alert-rule changes, support service-level configuration changes, and beta dashboard export and download actions, so every operational lever leaves a record. Reliability events cover incident create, update, and resolve, alert fire, resolve, suppress, and disable, readiness maintenance-mode changes, and operational export actions; the records carry safe summaries and the correlation identifiers needed to line them up with the underlying runtime events. Beta feedback triage, status change, tag change, link-to-work or support action, and deletion or redaction actions are audited; ordinary beta-feedback submission may be a product-feedback record rather than an audit event unless it creates a support conversation or triggers a security or trust workflow. Staff and founder access to raw support content, beta-feedback exports, analytics exports, incident details, and audit events is itself auditable, so the act of reading sensitive material is part of the trace.
Audit event access is restricted by role and purpose. A designer may see business events surfaced in their dashboard, statements, messages, and action queue, but only for their own designer profile. A buyer may see the order timeline, payment, refund, delivery, return, replacement, dispute, trust-challenge, and support history, but only for their own orders and account. Admin content events are visible only to authorised admins and authorised audit-and-support roles. Staff and support access to audit events is itself logged as an audit event, so the chain of accountability does not end at the person who reads the record.