Start a concept
Privacy

What we collect, and what happens to it.

This page describes what this website actually does with your information — read out of the code that runs it, not copied from a template. If something here does not match what you experienced, tell us and we will fix the page or the practice, whichever is wrong.

Last updated .

The short version

  • We collect what you type into our forms, the files you upload, and what your browser sends with the request.
  • The outside services that receive information are listed below, with what each receives and why. The recipient categories for the website and customer workflows covered here are described below, including what each receives and the provider details we have not verified. This is not an inventory of every internal company workflow.
  • Your files go straight into our own Microsoft 365 document library. There is no in-between store on our side.
  • Our staff use an AI assistant, Emma. While working on a staff member’s request, she can read their own mailbox and send what she reads to the AI service provider whose model writes her answers. If we know you and you email Emma’s own address, she reads it when it arrives and we keep it. She does not email you on her own.
  • Our page-view counter stores nothing in your browser, so those counts are not tied to you as a person.
  • Most of what we keep, nothing deletes on a schedule. Below we say exactly which, rather than leaving you with a comfortable generality.
  • Some of what we hold, we have not finished describing. We checked our own database against this document and found stores it did not cover — including your customer record, the largest of them. They are listed here rather than left out.

What we collect, and when

Each block below is one place on this site where information reaches us, what it asks for, and why.

Request access to the design tools (shown on /inquire and /configure to anyone not yet approved)

Who can reach it: Anyone on the internet can reach this and submit to it.

  • Your name (required) — so we know who is asking for access to the design tools.
  • Company (required) — to identify the business you are asking on behalf of.
  • Work email (required) — it is the account — the address the design-tools gate is built on, and where your sign-in link goes.
  • Phone (required) — so we can reach you about your request.
  • Company website (optional) — corroboration for whoever reviews your request, and the starting point for the background brief.
  • LinkedIn address (optional) — a link the reviewer can open for themselves.
  • Your IP address (required) — to stop our public forms being flooded. The network sends it with every request; we do not ask you for it.
  • A background brief about you, assembled automatically (required) — so whoever reviews your request has facts in front of them rather than a guess.

The booth concept / planner journey (/inquire, /configure, /configure/continue)

Who can reach it: Only an address a reviewer has approved for the design tools.

  • Your name (on the project inquiry) (required) — to know who the inquiry is from.
  • Email (on the project inquiry) (required) — to reply to you with a proposal.
  • Phone (on the project inquiry) (optional) — to call you back, when you have asked for a call.
  • Company (on the project inquiry) (optional) — to know which business the booth is for.
  • What you told us about the project (optional) — the brief itself, in your own words.
  • Show, venue and dates (optional) — to plan delivery and setup around your show.
  • The booth layout you built (optional) — so we quote for exactly the layout you designed.
  • Files you attach to an inquiry (optional) — so we have your reference material alongside your inquiry.
  • Your IP address (required) — to stop our public forms being flooded. The network sends it with every request; we do not ask you for it.
  • What browser you used (optional) — a phone-versus-desktop count for our own funnel report. We keep the category, not the full browser string.
  • Which page you submitted from, and any campaign tags on it (optional) — to tell which page or campaign an inquiry came from.
  • Which site you followed a link from (optional) — to tell which other sites send people to us, so we know where our work comes from.

Uploading artwork inside the booth designer

Who can reach it: Only an address a reviewer has approved for the design tools.

  • Artwork you upload into the booth designer (optional) — to show your own artwork on the displays in the 3D design.

Attaching files to a submitted inquiry

Who can reach it: Anyone holding the unguessable link we emailed to one person.

  • Files you attach to an inquiry (optional) — so we have your reference material alongside your inquiry.
  • Your IP address (required) — to stop our public forms being flooded. The network sends it with every request; we do not ask you for it.

Community / customer portal sign-in

Who can reach it: Anyone on the internet can reach this and submit to it.

  • Email (portal sign-in) (required) — it is your portal account — we email you a sign-in link rather than asking you for a password.
  • Your IP address (required) — to stop our public forms being flooded. The network sends it with every request; we do not ask you for it.

Track your order (/track)

Who can reach it: Anyone on the internet can reach this and submit to it.

  • The email or phone on your booking (required) — to check that whoever is looking up an order is on it. We match what you type and do not store it.

The site concierge chat

Who can reach it: Anyone on the internet can reach this and submit to it.

  • What you type to the site concierge (optional) — to answer your question, and so that a retry returns the same answer instead of asking again.
  • Goal, booth size, show date and venue mentioned in chat (optional) — so the conversation does not ask you the same question twice.

The files you upload

Files are different from the rest of a form, because we do not choose what is in them and neither, entirely, do you. A booth photograph or a walkthrough video can contain faces, name badges, other companies’ stands, or anything else that was in frame. We accept images, PDFs, PSDs and video.

The bytes go directly into our Microsoft 365 document library, into the folder belonging to your record — there is no in-between store on our side. Alongside them we keep the filename, the size and type we detected, and a checksum, so we can tell one file from another.

  • Artwork you upload into the booth designer — to show your own artwork on the displays in the 3D design.
  • Files you attach to an inquiry — so we have your reference material alongside your inquiry.

Please do not upload anything you would not want a member of our team to open. If you have already sent us something you would rather we did not have, write to us and we will deal with it by hand.

The background check we run automatically

When you ask for access to the design tools, our server assembles a short background brief about you before anyone looks at your request. It searches public sources: your name and company go to the US Securities and Exchange Commission’s public filings search, the domain part of your address goes to the public domain-registry lookup, and if you gave us a website our server opens it and up to two further pages.

It decides nothing. There is no score and no risk verdict — a person reads it and makes the decision. The brief is then stored with your request.

Emma, the AI assistant our staff use

Our staff use Emma to look things up and to prepare their work, and some of what she looks up is about you. This is what she does with your information, and with your email in particular.

  • Our staff can ask Emma, our AI assistant, to find or read emails in their own work mailbox, which can include emails you sent them or they sent you. She reads a staff member’s mailbox only while working on a request from that person, only in our staff chat, and only their own: she reads with their own Microsoft sign-in, using the permission Microsoft calls Mail.Read, and cannot open anyone else’s. She can also list people a staff member emailed over a requested period, from their own Sent folder, and offer to add people from that list to our records; nothing is added unless that staff member confirms it. For staff on this pilot, the request can cover their Sent folder from its beginning, with no total-message cap. That scan reads sent dates and To, Cc and Bcc names and addresses, not message bodies, subjects or previews. A paused scan is incomplete and can be continued; completion covers the selected folder and time range as observed, not deleted or moved-out messages or later arrivals. All of this is switched on only for the staff members we have added to it.

  • If we switch on our shared company mailbox for her, a staff member who asks about your emails lets Emma see, for up to eight of your messages there, the subject, the date, who sent it, whether it was unread and whether it came from us. Not the message itself. What she sees is kept in our record of her work.

  • The mailbox information used in Emma’s answer goes to the AI service provider whose model writes it, together with the staff member’s question and their recent conversation with her. A complete Sent-folder scan keeps its full recipient list in our system; the model receives a preview of up to 150 people with counts and coverage, not the working continuation or message identifiers. Each request uses its selected provider; other requests can use a different one. The dated provider information is below, under “Who else sees it”.

  • When Emma reads a staff member’s mailbox for them, we do not save the email itself. In an authorized private Teams chat, we keep an encrypted reference to the read, including search-result message identifiers and a fingerprint of the result, tied only to that staff member. This lets us withhold a reply when access changes or its source is erased; it is not a saved email body. These encrypted references follow the private-memory retention rule below. Linked result fingerprints and source references also remain in our work records, which have no automatic expiry.

  • We do keep what she made of it: her answer, which can quote or summarise your email, the shared-company-mailbox details described above, the list of people a staff member emailed when she makes one, and a record that she read it. Complete Sent-folder scans also retain their mailbox and scope, counts and progress. While incomplete, they retain continuation and message identifiers and colleague addresses; completion clears those working fields but keeps the recipient list and coverage. These records have no automatic expiry or source-erasure path in that scan feature. New mailbox search records keep the operation, time, who it was for, result count and outcome; they do not keep the search words or pagination links. Older work records may still contain those words: their cleanup has not been completed. The staff member’s question and Emma’s answer may also contain them. How long each of those is kept is under “How long we keep it”. Our record of her work has no deletion path today.

  • When her own email address is switched on, Emma processes incoming mail automatically, without a staff request.

    For incoming customer mail, CRM intake uses the verified sender, subject and headers to file correspondence or open an inquiry. It does not read a stranger’s message body, use an AI classifier or send an automatic external reply. Bulk, automatic and supplier mail is held for review. Mail from before routing was enabled, uncertain identities, unlinked older asks and conversations tied only to closed asks can also need review. Subject to the intake checks and review holds, mail attaches automatically to the one open ask identified by the existing conversation, or to the person’s only open ask. Staff choose when the match is ambiguous. When there is no open ask, a known person’s new conversation without a clear ask normally stays on their contact for staff review without opening a lead; a clear ask can open one. We keep decision and review records, message identifiers, dates, correspondence details and Outlook links; this release adds no automatic deletion schedule for them.

    For an already-known customer whose message is newly attached to an ask or opens one, we keep the whole message, encrypted, with our record of you, together with what she learns from it; she does not reply. Held mail and repeated processing do not use this learning path.

    If one of our staff forwards or copies your email to her, we keep the whole message the same way, but as a company record rather than with our record of you, so a request about you does not reach it today.

    Older inquiries may still contain up to 4,000 characters of filtered text from the first email. This release does not remove those excerpts. Their filtering was not a guarantee that all sensitive text was removed. The new CRM intake does not fetch attachments or itself send the body to an AI provider. Staff can later ask Emma about the inquiry or correspondence, which can send retained text to the selected provider.

  • Emma does not email you on her own. She can prepare messages to you, such as an invoice, a follow-up email, or a campaign email or text message, but none goes to you without a member of our staff sending it or confirming the send. An invoice goes only after that person confirms it by name, from their own mailbox. Her automatic replies go only to our own staff. The one exception is Microsoft Teams: if you are in a group chat with our staff and someone mentions her there, she may post one of a few short fixed notes, such as introducing herself and explaining that she cannot help with LumenART work there because someone in the chat is not set up with her yet. They say nothing about you.

What is stored in your browser

Kept in the tab only

Kept in the tab only, cleared when the tab closes, and never sent to us automatically.

  • emma-draft-v2: — Staff-only unsent Emma draft text, viewport and an interrupted-submission warning. No attachment bytes, attachment identifiers, answers or action cards are stored. File selections stay in memory during same-tab navigation and must be reselected after reload. Kept for: This tab, at most 30 minutes and no later than the authenticated token expiry; removed on observed login/account/access changes or sign-out. Suspended tabs purge on wake before reuse. Only once you have signed in.
  • lumen-booth-plan-v1 — The booth layout in progress, so a refresh does not lose it. Kept for: The browser tab. Present whether or not you are signed in.
  • lumen-concept-journey-v1 — The concept journey in progress. Kept for: The browser tab. Present whether or not you are signed in.
  • lumen-booth-inquiry-v1 / lumen-concept-inquiry-v1 — The half-filled inquiry form, including name, email and phone as typed. Kept for: The browser tab; removed on successful submission. Present whether or not you are signed in.
  • lumen-portal-prefill — Carries the email just submitted across to the portal sign-in form. Kept for: Read once, then removed. Present whether or not you are signed in.
  • lumen-first-touch — The site you followed a link from, read on your first page so an inquiry can say where it came from. Kept for: The browser tab. Present whether or not you are signed in.
  • lumen-olivia-chat-v1 — The concierge conversation, so it survives a page change. Kept for: The browser tab. Present whether or not you are signed in.

Kept in browser storage across tabs

Browser-wide storage, not sent to us automatically.

  • emma-draft-logout-v2 / emma-draft-clear-v2: — Content-free random invalidation markers for sign-out and cleared session drafts across tabs. No draft text or file bytes. Clear markers name the staff/access-epoch and conversation key, not its contents. Kept for: Until browser site data is cleared; draft readers and writers compare the markers before reuse. Only once you have signed in.

Cookies

A cookie the browser sends back to us on every request.

  • lumen_portal_session — The customer portal sign-in. httpOnly, sameSite lax, secure in production. Kept for: 30 days (maxAge), matching the server-side session expiry. Only once you have signed in.
  • sb-* (Supabase auth) — Staff sign-in to /admin. Kept for: Managed by the Supabase SDK. Only once you have signed in.

The page-view beacon

A page-view event sent to the analytics endpoint.

  • /_vercel/insights/event — Page-view counting on the public marketing site. Kept for: Not stored in the browser. Present whether or not you are signed in.

Our page-view counter, and what it cannot tell us

The analytics package we ship does not use cookies, local storage or session storage. That does not rule out server-side visitor recognition. Vercel documents a request-derived hash for counting visitors and says a visitor session is discarded after 24 hours.

Vercel’s visitor-counting explanation. the tracking script itself is fetched from /_vercel/insights/script.js at runtime and is not part of the package, so this repository cannot speak for its behaviour

What it records:

  • a page-view event per navigation on the public marketing site: route, path and referrer
  • NOT /admin, which is excluded, and NOT token routes, which the mount is structurally kept away from

The aggregate page-view information does not let us:

  • identify you by name from the page-view counts shown to us
  • identify a named person or reconstruct browsing across other websites from the aggregate analytics Vercel describes
  • see anything you type into a form — the counter records that a page was opened, not what happened on it

Who else sees it

These are the recipient categories for the website and customer workflows described here. Unverified provider details are listed under the open questions; this is not a complete inventory of internal company activity.

Vercel (application hosting)

The company that runs the servers this website is served from.

Every request to the site passes through them, including the IP address and browser the network layer sees, and anything typed into a form while it is on its way to us. Our own server error logs are written there too.

Service arrangement: We pay them to run the site. Nothing is given to them in exchange for it.

Vercel Web Analytics

The page-view counter on our public pages.

One event per page you open: which page, its path, and the page you arrived from. Not the staff area, which is excluded, and not any page whose address contains a link we emailed you.

Service arrangement: Part of the same hosting bill. We receive page counts; they are given nothing of value in return.

Microsoft 365 (SharePoint, Graph mail, Teams)

Our own Microsoft 365 tenant — SharePoint for documents, Outlook for mail, Teams for internal notifications.

The files you upload, stored there directly. Email we send you. And a short Teams card when something needs our attention. For a new project inquiry that card carries your name, company and the booth details, and not your email address, your phone number or your message. For a request for access to the design tools it also carries your email address, your requested tool and whichever of your website or LinkedIn you gave, because that is what the reviewer deciding is looking at. Each card is queued in our own database first, and those queued rows are kept — see “How long we keep it”.

Service arrangement: We pay a licence fee for our own tenant. Nothing moves the other way.

Supabase Auth (staff sign-in)

The sign-in system for our own staff accounts.

Our staff email addresses and passwords. Nothing about you: if you are not signed in as staff there is no sign-in cookie on your browser and nothing is sent.

Service arrangement: We pay for staff sign-in. Nothing about you is sent there at all.

Supabase — East US (North Virginia)

Supabase, which operates our application database in East US (North Virginia).

The application records described here are stored in our database. Uploaded file bytes are kept separately in Microsoft 365. Adam, our administrator, confirmed this operator and region on 1 October 2026. This identifies the application database location, not the processing locations of our other providers.

Service arrangement: We pay them to run our database. Nothing is exchanged for the data on it.

Brave Search API

A search engine we use for access-request research. Search is enabled in production; configuration was confirmed on 1 October 2026.

Searches built from your company name and website, and — where the other checks have not already connected you to it — your own name alongside the company. It decides for itself what it logs.

Service arrangement: We send search queries to this service; any service charge runs from us to them.

SEC EDGAR full-text search (sec.gov)

The US Securities and Exchange Commission’s public filings search.

Your name and your company name, sent as a search query. It needs no account and decides its own logging.

Service arrangement: A free public search run by a US regulator. Nothing is paid or received in either direction.

rdap.org (registry bootstrap) and the TLD registry it redirects to

The public lookup service for domain-name registrations.

The domain part of your email address or of the website you gave us — a domain, never your name. We deliberately do not read the registrant contact details out of the reply.

Service arrangement: A free public lookup of domain registrations. Nothing is paid or received in either direction.

The applicant's own website (and any host it redirects to)

Your own website, and anywhere it redirects to.

Our server opens your homepage and up to two further pages. Your website’s logs see our request and our address, not yours.

Service arrangement: We fetch a page you published. Nothing about you is sent to it beyond the request itself, and nothing is exchanged.

The AI service providers that power Emma, the staff assistant

The AI service providers whose models write the answers of Emma, the assistant our staff use. Each staff request uses its selected provider. Different requests can use different providers. The list below records the provider configuration when it was last checked, not a guarantee about every request running today.

What a member of our staff asks Emma, their recent conversation with her, and everything she looks up to answer, which can include your inquiry and the rest of our record of you. While Emma works on a staff member’s request, she can read their own mailbox; the information returned for her answer goes to the provider in use too. Complete Sent-folder scans return a bounded recipient preview, while the full list and working checkpoint stay in our system. See the section on Emma, above.

  • Anthropic: Claude models, through the Claude Code tool. In use when last checked. Emma was running on this provider on September 24, 2026. Emma signs in to it with an account on its own service, not with a developer key. The terms of that account are one of the open questions below. Our account administrator confirmed on September 29, 2026 that “Help improve Claude” was off for this account. This reports an account setting, not a promise about how the provider handles data.
  • OpenAI: ChatGPT models, through the Codex tool. Not in use when we last checked, on September 24, 2026. A request routed to it would send the information described above. Emma signs in to it with an account on its own service, not with a developer key. The terms of that account are one of the open questions below.

Service arrangement: We pay for the service Emma runs on, and nothing is paid to us. Whether the provider may also use what Emma sends it for its own purposes is one of the open questions below.

Built, but switched off — these receive nothing today

The connection exists in the software and is not running. We list them so that a capability one change away from being live is not a surprise.

Anthropic (public concierge model lane)

The AI service the site chat would be built on.

Nothing. If it were ever switched on it would receive what you type into the chat and the details the conversation has gathered — your goal, booth size, show date and venue.

What would turn it on: a deliberate change to the code, reviewed before it ships. The site refuses to use it in production, so obtaining a key would change nothing on its own.

Service arrangement: Would be a service we pay for, not a buyer. It is switched off and receives nothing today.

How long we keep it

Different rules for customer and private staff memory

Customer history has no automatic time-based deletion; on a valid legal or privacy request it can be removed by hand. A staff member’s private memory becomes eligible for scheduled erasure 30 days after their account is archived; removal depends on the cleanup job running successfully.

  • Optional private routine consent and schedule. Live routines are not available yet. The prepared feature keeps the asking staff member’s schedule, private destination and consent. Stop disables work; consent records have no automatic expiry.
  • The progress of an optional private routine. The prepared feature keeps progress separately from mail content. Completed or stopped run history is removed after 90 days when its scheduled cleanup can reach the database. Unfinished review is kept until reviewed or stopped. This is not a claim that live routines are running.
  • Correspondents awaiting private CRM review. The prepared feature retains names and email addresses only for the asking staff member’s review. Source erasure or Stop removes unreviewed content. Creating a CRM record still requires separate confirmation; scheduling alone never approves it.
  • The original sources behind a routine candidate. The prepared feature links each candidate to the original it came from so erasure can withdraw the derived copy. Source identifiers and hashes are linkable, not anonymous; they disappear when the associated candidate record is deleted.
  • The attributed facts our internal assistant learned. Our internal assistant can learn a sentence from an authorized staff chat, customer email or completed action. It keeps who supplied the sentence, when, and a link to the original that supports it. A valid privacy erasure removes both the assistant’s attributed memory copy and the learned sentences derived from it; canonical mailbox, file, CRM and financial records still follow their own legal process. Older facts whose originals were not captured remain visible only to administrators until they are classified.
  • The original material our internal assistant worked from. For connected sources, we keep an encrypted copy of the exact chat turn, authorized email body or completed-action input our assistant saw, with its source, author, date and audience. The encrypted original may contain sensitive words that the assistant is forbidden to turn into a learned fact. Customer history has no automatic time-based deletion; on a valid legal or privacy request it can be removed by hand. A staff member’s private memory becomes eligible for scheduled erasure 30 days after their account is archived; removal depends on the cleanup job running successfully. Files, attachments, calendar events, Teams, meetings, calls and computer-use sessions are not all connected to this ledger yet.

Kept indefinitely

There is no code in the product that removes these. They stay until we build something that does, or until we take them out by hand.

  • The original email and saved answer requiring a reply. Erasing the connected original removes routing addresses and mailbox message identifiers. Internal references, linked hashes and the send outcome remain with no automatic expiry, so erasure cannot enable another send. These retained records are not anonymous.
  • The record connecting an email to Emma to the answer being prepared. Erasing the connected original email removes its routing addresses and mailbox message identifiers. Internal references, linked hashes and the outcome remain with no automatic expiry, so erasure cannot cause the email to be answered again. These retained records are not anonymous.
  • Email reply acceptance or an uncertain send outcome. A mail service accepting a reply does not establish delivery or reading. Uncertain outcomes remain visible without automatic resend. Linked hashes and internal references have no automatic expiry.
  • The connection between a Teams identity and an authorized staff account. No automatic expiry is implemented for identity bindings and their provisioning references. Revoking a connection does not remove its history.
  • The record connecting a private Teams message to its answer. When the connected original is erased under its memory retention rule, routable addresses are removed and channel identifiers are replaced with hashes. Linked internal references and delivery outcomes remain, including uncertainty, so erasing content cannot cause a second send. These retained references are not anonymous and have no automatic expiry.
  • The record that a saved answer needs a Teams reply. When the connected original is erased under its memory retention rule, routable addresses are removed and channel identifiers are replaced with hashes. Linked internal references and delivery outcomes remain, including uncertainty, so erasing content cannot cause a second send. These retained references are not anonymous and have no automatic expiry.
  • The outcome of a Teams reply attempt, including an uncertain outcome. When the connected original is erased under its memory retention rule, routable addresses are removed and channel identifiers are replaced with hashes. Linked internal references and delivery outcomes remain, including uncertainty, so erasing content cannot cause a second send. These retained references are not anonymous and have no automatic expiry.
  • Your request for access to the design tools. Nothing removes this. Approved, rejected or withdrawn, the row stays where it is.
  • The history of what was decided about that request, including a reviewer’s private notes. Deliberately append-only: a decision that could be edited afterwards would not be worth keeping as a record of what was decided.
  • The background brief we assembled about you. It would only go if the request it belongs to went, and nothing removes a request.
  • The record that a prospect list was imported — the file’s name, its column headings and who imported it. There is no path in the product that removes an import record yet.
  • Your row from a prospect list a staff member imported, exactly as the list had it, and what we did with it. Goes only if the import it belongs to is removed, which nothing in the product does yet.
  • Your portal account — a verified email address. There is no path in the product that removes a portal account.
  • The single-use sign-in links we email you. The link itself stops working after 30 minutes and cannot be used twice. The row recording that we sent it is not removed — expiry is a check we run, not a deletion.
  • Your portal sign-in session. A session stops working after 30 days and can be cut off sooner. The row is not removed.
  • The record of each file you attached to an inquiry. Once stored, neither you nor we can change this row from the website, and nothing here removes the file it points at.
  • The counters that stop our public forms being flooded. A cleanup routine exists, but the reviewed application has no scheduled call to it. We have not established deletion of previously stored counters.
  • Our audit log of changes to records, which holds a before-and-after copy of anything that changed — including your details. The database itself refuses updates and deletions on this table, so it cannot be pruned without a schema change.
  • Our internal event log, which drives notifications and automation — and which keeps the name from a deleted inquiry after the inquiry itself is gone. Rows that have been processed are marked as done rather than removed.
  • The queue of messages we have sent you or are about to. There is no path in the product that removes a sent or queued notification.
  • The queued contents of each internal Teams alert about you — for an inquiry your name, company and booth details; for a design-tools request your email address and requested tool as well. A delivered row keeps its place so the same card is never sent twice, and nothing removes it afterwards. The card’s contents are written once and never cleared.
  • The project your inquiry became, so several quotes for it stay together. Nothing removes this. If your inquiry is deleted the project keeps its own record and simply stops pointing back at it.
  • The confirmed job that proposal became. Nothing removes an order. It is also the reason the quote above it cannot be removed once one exists.
  • Our record of each piece of work Emma does for a member of staff, including her answer, which can quote an email you sent them, and a record of her mailbox searches. Older work records may still contain the search words. Deleting the chat does not delete these, and nor does the staff member leaving us. No code removes them today.
  • A question a staff member dictated to Emma, turned into text on our own computer, which can name you. When a staff member starts dictation and grants browser microphone permission, the dock records audio and uploads it to a transcription job in our database. The recording stays while it waits for transcription. It is cleared when transcription finishes, whether it succeeds or fails. Transcription runs on our own computer; the recording never goes to an AI service provider. The text is kept, and no code removes it today. The transcript returns to an editable composer; it reaches Emma’s selected AI provider only if the staff member sends it as a question. Read-aloud uses the browser’s speech facility; which installed or platform voice processes that text depends on the device.

Until we delete it by hand

Nothing removes these on a schedule. They go when one of us removes them.

  • Your project inquiry. A person here can remove one by hand, and only while it never became a quote. Nothing is scheduled, and see the deletion note below for what stays behind afterwards.
  • Our internal notes and status changes on your inquiry. Goes only when the inquiry it belongs to is removed by hand.
  • The proposal we built from your inquiry, with our own notes on it. A person here can remove one by hand only while it is still a draft with nothing built on it. Once sent, signed or turned into an order it is archived instead — hidden from our working list, not removed.
  • A staff member’s chat with Emma, and its title. The staff member can delete a chat whenever they like, except while Emma is still answering in it. Starting a new chat only puts the old one aside.
  • The messages in that chat: the staff member’s questions and Emma’s answers, which can quote an email you sent them. They go when the staff member deletes the chat they belong to, and not before. A copy of each of Emma’s answers also stays in our record of her work, above, and in that staff member’s private memory, which becomes eligible for scheduled erasure 30 days after their account is archived. A failed or delayed cleanup can keep it longer.

You can delete these yourself

You can request removal of booth artwork from your own session. We mark its record removed after Microsoft acknowledges deletion from the active document library, or reports that the file is already absent. This does not establish permanent erasure of recycle-bin or other provider-retained copies. Their retention has not been verified.

  • The record of each artwork file you uploaded into the designer. You can remove booth artwork from the session you uploaded it in. Microsoft must acknowledge removal from the active document library, or report the file already absent, before we mark it removed. The metadata row remains as a record of removal. Microsoft’s deletion process uses a recycle bin; it does not prove that every provider-retained copy is gone. Nothing removes these files on a schedule.

Removed automatically

These become eligible for automatic removal after a fixed period. Removal depends on the cleanup job running successfully.

  • A short-lived cache of chat answers. Eligible for removal after 15 minutes. These turns are eligible for automatic cleanup after the period shown here; removal depends on the cleanup running successfully.

Not established

We have not established how long this is kept. It is listed as an open question below.

  • The files themselves, in our Microsoft 365 document library. We have not established this. It is set in our Microsoft tenant rather than by this website — see the open questions below.

The flood counters in that first group deserve saying plainly: they record the IP address a request came from, and on two of the forms the email address that was submitted, exactly as written. Nothing in the product removes those rows today.

What we found that this page did not cover

Everything above is read out of a record of what the software does. That record is also compared, automatically, against the actual structure of our database — and the comparison finds things the record does not describe. Those findings are printed here rather than kept internally, because a finding nobody reads is the same as no finding. None of these has an established retention period, and we would rather say that than invent one.

Your customer record

Created by staff or from the company named in an inquiry, and used when we prepare business with you. It holds your name, company, email address, phone number, billing and shipping addresses, and whatever notes and tags we have put on it. This is the largest store of personal information in the product and the one this document had least to say about. Nothing in the software removes it.

Our separate people records

We keep names, email addresses, phone numbers, organization details and marketing-channel consent in separate person records. A person may have no company and may be added or linked when an inquiry is submitted, or entered by staff. A company you name may also be created or linked at intake; a possible duplicate can require staff review. Removing the inquiry does not remove that person record or its contact details. Some people never used this website; we have not established what they were told when staff entered them.

Merging duplicate person records

The planned merge feature retains both person records, who confirmed the merge, their written reason, the chosen details, affected links and references to earlier values needed for Undo. Undo adds to this restricted history; it does not erase it. We have not established how long this recovery history is kept or a permanent removal process.

Your signature on a proposal

If you sign a proposal we keep your name, email address, job title and company, the IP address and browser you signed from, and the signature itself — stored twice, as an image and as data inside the record. This is the most sensitive thing the product holds, and this document did not previously mention it at all.

Where your booth is going

The street address, city, state and postcode of the site, and any notes about the location. When the site is somebody’s own premises that is personal information, and nothing in the software removes it.

Photographs taken on site

Photographs our crew takes on site keep the camera’s full metadata, including the GPS coordinates where the photo was taken. That is collected as a side effect of photographing equipment rather than on purpose, and we have not decided whether to strip it.

Shipping and delivery details

Contact and driver names, phone numbers, and pickup and delivery addresses for a shipment. A driver listed here may never have dealt with us directly, and we have not established where their details come from or how long they are kept.

Who a marketing campaign was sent to

The contact name, the company it belongs to, the destination address, and whether each person was judged eligible to receive it. This is the record of acting on a marketing permission, and this page did not describe it.

An artwork upload still in progress

While an upload is under way we keep the email address it belongs to and the filename. It is bookkeeping beside the artwork record described further up, and it is invisible to the tools we use to read our own schema — which is exactly why it went unlisted.

Every version of your booth layout

Each saved revision, with who saved it and any notes. This page described your booth plan as one thing stored with your inquiry; this is a second, lasting copy with its own history.

The folder your project is filed in

When your first file arrives we pick one folder in our document library for your project and record the exact path. The path is built from who you are, so the record of it identifies you on its own. It is written once and nothing in the product removes it.

When that folder is renamed

If your inquiry becomes an order the folder is moved, and we keep the path it came from, the path it went to, and a note about how the move went. That is two more lasting copies of the same identifying path.

Where each of your records is filed

For every record we keep about you we also store the folder path and the web link that reaches it in our document library. This is the third place that path is held, and this page had not described any of them.

Notes our crew wrote about your job

Once your order becomes work on site, our team writes notes against the job. This page described notes about you only while you were still an inquiry. These are the ones that come after, and nothing in the product removes them.

Service details preserved on your invoice

The invoice keeps a copy of its itemized lines, including selected dates and labor notes. Personal details written in those notes can therefore also be present in this financial record.

The service details passed to operations

When your accepted proposal becomes an order, its line dates and labor notes are copied into the order for our operations team.

Dates and labor notes on your proposal

Equipment and service lines keep the selected dates and our team’s description of the labor involved. Those notes may include people or arrangements specific to your event.

Details held inside the records above

The same comparison looks inside the records this page does describe, for content that is about you but that the description does not name. Some of it is a second copy of something already listed further up; the rest is not written down anywhere else on this page.

  • Prepared private routine candidates keep references to their original messages and permitted audience. These references are linkable to people, not anonymous. Not described elsewhere on this page.
  • The inactive routines feature can prepare names and email addresses from the asking staff member’s Sent email for their private review. It does not create CRM records without confirmation. Not described elsewhere on this page.
  • A routine’s saved mailbox continuation lets an interrupted listing resume. It is private operational state, not message text, and is cleared when unfinished work is stopped. Not described elsewhere on this page.
  • Routine consent records which of the staff member’s private chats should receive results. Private chat delivery is not connected yet. Not described elsewhere on this page.
  • The consent record keeps the staff member’s authorization role so later work can refuse changed access. Not described elsewhere on this page.
  • The staff member’s confirmed schedule includes weekdays, local time and time zone. Consent and schedule records have no automatic expiry. Not described elsewhere on this page.
  • Error details from processing a question or recording, which may contain personal words. Not described elsewhere on this page.
  • Error details from processing a question or recording, which may contain personal words. Not described elsewhere on this page.
  • Error details from processing a question or recording, which may contain personal words. Not described elsewhere on this page.
  • A staff member’s question to Emma, which can name you or quote your email. Not described elsewhere on this page.
  • What was sent to Emma with the question, including the records she was given, mailbox search metadata (with search words possibly remaining in older work records), and the names and addresses of people a staff member emailed, which can include yours. Not described elsewhere on this page.
  • Emma’s answer, which can quote or summarise your email. Not described elsewhere on this page.
  • A preview of that answer while it is being written. Not described elsewhere on this page.
  • The complete answer as delivered. Not described elsewhere on this page.
  • The staff member who asked. Not described elsewhere on this page.
  • The staff member who dictated a question. Not described elsewhere on this page.
  • Their recording, until it is turned into text. Not described elsewhere on this page.
  • The text of a dictated question, which can name you. Not described elsewhere on this page.
  • The staff member whose chat it is. Not described elsewhere on this page.
  • The start of the chat’s first question, which can name you. Not described elsewhere on this page.
  • A working copy of a quote being discussed, which can carry your show and booth details. Not described elsewhere on this page.
  • A staff question or one of Emma’s answers, which can name you or quote your email. Not described elsewhere on this page.
  • The record a message was about, which can be yours. Not described elsewhere on this page.
  • The records an answer listed, which can include yours. Not described elsewhere on this page.
  • Links to the records an answer mentioned. Not described elsewhere on this page.
  • A change Emma proposed, which can include your name and email address. Not described elsewhere on this page.
  • The directory identity of the mailbox the email arrived in. Not described elsewhere on this page.
  • The staff address authorized when the email was admitted. Not described elsewhere on this page.
  • The original sender address. Not described elsewhere on this page.
  • The single selected reply recipient. Not described elsewhere on this page.
  • The mailbox identity of the original message. Not described elsewhere on this page.
  • The original email message identifier. Not described elsewhere on this page.
  • The checked reply address on the original email. Not described elsewhere on this page.
  • A retained hash identifying the admitted email. Not described elsewhere on this page.
  • A hash binding the admitted email to the question asked. Not described elsewhere on this page.
  • The directory identity of the mailbox sending the reply. Not described elsewhere on this page.
  • The staff address authorized for this reply. Not described elsewhere on this page.
  • The original sender address. Not described elsewhere on this page.
  • The single selected reply recipient. Not described elsewhere on this page.
  • The mailbox identity of the original message. Not described elsewhere on this page.
  • The original email message identifier. Not described elsewhere on this page.
  • The checked reply address on the original email. Not described elsewhere on this page.
  • A retained hash identifying the original reply claim. Not described elsewhere on this page.
  • A hash binding the reply to its saved answer. Not described elsewhere on this page.
  • A hash of the reply payload. Not described elsewhere on this page.
  • A hash of the mail service acknowledgement. Not described elsewhere on this page.
  • The organization owning that directory identity. Not described elsewhere on this page.
  • The directory identity mapped to a staff account. Not described elsewhere on this page.
  • The reference establishing who provisioned that connection. Not described elsewhere on this page.
  • The authorized staff address at admission. Not described elsewhere on this page.
  • The organization owning the Teams conversation. Not described elsewhere on this page.
  • The Teams application identity. Not described elsewhere on this page.
  • The private Teams conversation identity. Not described elsewhere on this page.
  • The identity of the Teams message. Not described elsewhere on this page.
  • The service address used to deliver the reply. Not described elsewhere on this page.
  • The reply sender identity. Not described elsewhere on this page.
  • The reply recipient identity. Not described elsewhere on this page.
  • The reply identifier returned by Teams, hashed after original-source erasure. Not described elsewhere on this page.
  • When a staff member imports a list of prospects, we keep each row of that list exactly as the file had it — name, company, email, phone and any notes — so the import can be checked and retried without guessing. Not described elsewhere on this page.
  • When a row of an imported list is refused, we keep the sentence explaining why, and that sentence may quote the email address or phone number it refused. Not described elsewhere on this page.
  • The reason a reviewer typed when approving or rejecting you, kept with the request. Not described elsewhere on this page.
  • The reason recorded against each decision made about you. Not described elsewhere on this page.
  • Private notes a reviewer wrote about you while deciding. Not described elsewhere on this page.
  • What kind of project you said you were planning. The same information as “Show, venue and dates” above, kept again here.
  • Your own words about when you need it. The same information as “Show, venue and dates” above, kept again here.
  • Your own words about what you can spend. The same information as “Show, venue and dates” above, kept again here.
  • Notes our team typed about you and your inquiry. Not described elsewhere on this page.
  • An open field on those notes — nothing limits what about you can be recorded in it. Not described elsewhere on this page.
  • The email address a file belongs to, kept again on the file. The same information as “Email (on the project inquiry)” above, kept again here.
  • The address that actually sent the file, kept separately. The same information as “Email (on the project inquiry)” above, kept again here.
  • Your file’s name as it was on your own computer, which often contains a person’s or a company’s name. The same information as “Files you attach to an inquiry” above, kept again here.
  • The same filename tidied for storage — tidied for our filesystem, not to remove anything personal. The same information as “Files you attach to an inquiry” above, kept again here.
  • A note one of us wrote about your file. Not described elsewhere on this page.
  • The link to your folder in our document library; the path itself identifies you. The same information as “Files you attach to an inquiry” above, kept again here.
  • The approved address that owns an artwork file. The same information as “Work email” above, kept again here.
  • Your artwork’s own filename. The same information as “Artwork you upload into the booth designer” above, kept again here.
  • The name the same file was given in our library. The same information as “Artwork you upload into the booth designer” above, kept again here.
  • The folder path it was filed under, which is built from who you are. The same information as “Artwork you upload into the booth designer” above, kept again here.
  • Why your artwork was held back for someone to look at. Not described elsewhere on this page.
  • The sentence the assistant learned, which can contain your request, preference or project context. Not described elsewhere on this page.
  • The channel-established identity of the person who supplied that sentence. Not described elsewhere on this page.
  • The company record that contradicted the learned sentence, copied in words so the conflict stays visible. Not described elsewhere on this page.
  • The encrypted original content and its source locator — protected by encryption, but still your or a staff member’s content underneath. Not described elsewhere on this page.
  • The channel-established identity of the person or system that supplied the original. Not described elsewhere on this page.
  • The user or customer identity that original belongs to, cleared when the memory copy is erased. Not described elsewhere on this page.
  • A copy of a record exactly as it was before a change — when the record is yours, that is a verbatim copy of your details, and this log cannot be deleted. Not described elsewhere on this page.
  • The same copy taken after the change, reaching just as far. Not described elsewhere on this page.
  • The details attached to an internal event — a new inquiry carries your own details here, and a deleted one leaves your name behind. Not described elsewhere on this page.
  • The email address or phone number each message was sent to. Not described elsewhere on this page.
  • What was filled into the message — in practice your name and the details of your order. Not described elsewhere on this page.
  • The name our team gave your project, so several proposals for the same job stay together — usually your event or your venue. Not described elsewhere on this page.
  • Your show and service dates, plus any explanation our team records when on-site services are not needed. Not described elsewhere on this page.
  • Billing and shipping addresses chosen for this proposal when they differ from your customer account. Not described elsewhere on this page.
  • The service coverage or exclusions our team agreed for your project, their notes explaining the decision, and who recorded it and when. Not described elsewhere on this page.
  • Notes our team typed about your proposal, kept on the quote itself rather than with your inquiry. Not described elsewhere on this page.
  • The title of your own project, as it appears at the top of the proposal we send you. Not described elsewhere on this page.
  • The contents of the internal message our team is sent about you. For an inquiry that is your name, your company and your booth details; for a design-access request it also carries your email address. It is written once and never cleared after sending. Not described elsewhere on this page.

Asking for a copy, a correction, or deletion

Write to us. A person reads it and does the work by hand — there is no automatic path for this, and we would rather say so than point you at a form that does not exist.

Email hello@lumenart.ai

So you know what to expect, rather than being promised something we cannot do:

  • We will not give you a deadline we have not proved we can meet. We will tell you when it is done, and what we could not do.
  • A project inquiry that never became a quote can be removed by hand, along with our notes on it. Removing an inquiry is not erasure of every copy of your details. The event log keeps your name, and a separate person record can keep your name, email address, phone number and organization. Removing the inquiry does not remove that person record. These copies need separate review when handling a privacy request; nothing in the product deletes the event log.
  • An inquiry that did become a quote is archived rather than removed, because a quote is a commercial record — and once it becomes an order, nothing removes that either.
  • Some records have no deletion path in the software at all today — a request for design access and the decisions made on it, our audit log, and our internal event log. Removing those is something we would have to build, and we will say so rather than imply it is already done.

What we have not settled yet

Publishing these is the point. A page that quietly left them out would read as more certain than we are.

  • How long a file stays in our Microsoft 365 document library is set in our Microsoft tenant rather than in this website, and we have not established that period well enough to publish it here.
  • Our page-view counter loads a small script from our hosting provider when you open a page. We checked the code we ship and it stores nothing in your browser; we have not separately inspected that remote script, so we describe the result as what we verified rather than as a guarantee.
  • How long Emma’s AI service provider keeps what Emma sends it, and whether it may use it to improve its models, depends on the terms and data settings of the account we use with that provider. The provider list records the account setting our administrator confirmed; we have not established the complete terms, retention or processing location for that account. That setting is not a guarantee about what the provider keeps or how it uses data.
  • We have not established in which country Emma’s AI service provider stores and processes what Emma sends it, so it may be outside the country you are in.
  • There is no automatic way to ask us to delete your information — no button and no form. Write to us and a person will deal with it by hand. Some of what we hold has no deletion path in the software at all today, and the section above says which.

Changes to this page

This page is built from a record of what the software does, so it changes when the software does. The date at the top is the last time that record was reviewed. If you want to know what changed, ask us.

LumenArt · lumenart.ai · hello@lumenart.ai