In short
- Reading this site sets no cookies and writes nothing to your browser. The public pages count page views with Google Analytics and Vercel Web Analytics; nothing is counted after you sign in. enforced by test
- Requesting early access stores your email address and the one sentence you typed. Nothing else about you is recorded, including your IP address. enforced by schema
- OneLap runs no AI model of its own and sends nothing to a model provider. fails closed
- If you connect your own agent, such as Claude, ChatGPT or Grok, through OneLap MCP, it reads what you allowed under your account with that provider. You choose the workspace and can revoke the connection in Settings. revocable
- Retention periods are declared but no scheduled job runs them yet. not enforced
- There is no self-service export and no self-service deletion. Deletion is a manual operator process. no client action
The rest of this page is the same statements with the mechanism behind each one named. Where OneLap has no mechanism, it says so instead of describing an intention.
Who this is about, and who is responsible
This policy covers two different people. A visitor reading this site or asking for early access, and a member of a workspace signed in to the product. Almost everything on this page applies to only one of them, so each section says which.
The controller declared in OneLap’s processor registry is T4S Labs. That name is a fact about config/product-processors.json, which the product also renders to members inside their workspace. The registered company name and address behind it have not yet been supplied for publication.
- Controller
- T4S Labs
- Registered entity
- awaiting publisher · registered entity
- Registered address
- awaiting publisher · address
- Data contact
- awaiting publisher · contact address
For a member’s own business data the roles reverse: the client is the controller of what their systems measured, and OneLap processes it on their behalf. That split is written into the product and is visible in a workspace under Settings, Data and privacy.
Reading this site
Applies to visitors. Opening a public page counts one page view. Nothing is written to your browser, and nothing is counted on the sign-in pages or inside a workspace.
- Page views, counted twice. Google Analytics 4 (run by Google) and Vercel Web Analytics (run by Vercel, which hosts this site) receive the address of the page, the page you came from, what your browser reports about itself (browser, operating system, screen size, language) and, from your IP address, an approximate location. Google’s tracking script is not loaded: the page sends the page view itself, with an identifier made fresh for every page load, so a later visit is not recognised.
- Only the public pages. The home page and these documents are counted. Neither script is loaded on the sign-in pages or in a workspace, and a page view for any other address is dropped before it is sent. A test fails the build if a measurement script reaches any other page. enforced by test
- No other analytics or product telemetry. No PostHog, Mixpanel, Amplitude, Segment, Plausible, Sentry, or OpenTelemetry. The same test scans package manifests, imports, script tags, environment variables, and outbound hosts, and fails the build if any of them appears.
- No cookies for an anonymous reader. The only cookies this product ever sets are the session cookie and the time-zone cookie described in the next section, and both are written only after you sign in.
- One third party. The page view is sent to Google Analytics; no script is loaded from Google. Everything else is served from this domain: fonts are not fetched from Google Fonts, images are local files, and there is no tag, chat widget, or embedded video.
- No local storage. Nothing on this site writes to
localStorage,sessionStorage, ordocument.cookie.
There is no cookie banner because nothing is stored in your browser. A browser that blocksgoogle-analytics.com or Vercel’s analytics loses nothing on this site. Server logs kept by the hosting platform are covered under where data is held.
Asking for early access
Applies to visitors. The form on the home page is the only thing on this site that writes anything, and it is the only place in the whole product that accepts a write from someone who is not signed in.
It stores exactly five values, and three of them are generated by the database:
- Email address · from you
- The address you typed, lowercased.
- Goal · from you
- The sentence about what you are trying to move, up to 140 characters. Optional.
- Request identifier · generated
- An identifier for the row.
- Received at · generated
- The time the request arrived.
- Answered at · generated
- The time a person answered it, once one has.
Your IP address, your browser, the page you came from, and anything else your request carried are not stored. There is no field for them in the table.
The row cannot be read from a browser. The table grants nothing to any web-facing role, row level security is enabled and forced on it, and no policy is declared. The one way the application reads it is a database function that answers OneLap’s owners and refuses everyone else, so requests are read by a person on a page only an owner can open. Sending the same address twice produces the same answer as the first time, so the form cannot be used to find out whether someone has applied.
Your address is not added to a mailing list, a sequence, or a marketing tool, and it is not sent to any third party. A person reads the request. If OneLap fits, you receive one invitation to sign in, sent by the sign-in provider described below, and the request is marked answered. That invitation is the only automated message you will receive.
An early-access request is classified to be kept for ninety days. Nothing deletes it. The product’s purge routine works one workspace at a time and selects rows by workspace, and this row belongs to no workspace, so that routine cannot reach it. No other job, schedule, or script deletes it either. Until a sweep is written, treat the ninety days as a stated intention and not as a control. If you want your request removed before then, see your rights.
Signing in and working in a workspace
Applies to members. OneLap is invite-only and has no self-service signup. An operator issues an invite to one workspace.
- Sign-in. Authentication is by email link. Your email address and authentication state are held by Supabase, the authentication and database platform described below. Those emails are sent by Supabase’s own mailer. OneLap uses no separate email delivery vendor.
- Cookies. Signing in sets a session cookie so the server can tell who you are on the next request. It is strictly necessary for the product to work and is used for nothing else. Signing out clears it.
- Time zone. After you sign in, the server stores your browser’s time zone name (for example
Europe/Prague) in a functional cookie,onelap-tz, so dates and times appear in your local time from the first render. It holds only that name, is sent only to this site (SameSite=Lax), lasts at most a year, and signing out clears it. - What other members can see about you. Inside a workspace you belong to, other members see your display name, role, access status, and when you were last active. Email addresses, authentication details, and recovery data are visible to operators only.
- What you can see. Only the workspaces you belong to. The product never lists another workspace, its people, or the fact that it exists. An address for a workspace you cannot reach answers the same way as an address for one that does not exist.
Your business data
Applies to members. The material OneLap reasons over is your own go-to-market data: what your channels measured, what your funnel did, what you decided.
- How it arrives. A member connects each source in the workspace’s Settings, one at a time, and each connection shows its state there. A source nobody connected is shown as not connected, and OneLap reads nothing from it.
- Where the durable record lives. Normalized snapshots, lineage, decisions and approved reports are written to a repository you own, as plain files you can read without this product. If you leave, you keep that record.
- What OneLap will not infer. A reading that no source produced stays missing. The product marks it rather than filling it with an average, which is the reason the home page shows a red
NOT MEASUREDstate.
Connections listed in Settings that show as available on an operator’s own machine are not connections OneLap holds. The product has no access to them.
AI processing
OneLap runs no AI model of its own. The work is done by your agent, connected to OneLap by you. This is the current state of the code, not a policy preference.
Your agent, through OneLap MCP. A member may connect an agent they already use, such as Claude, ChatGPT or Grok, to OneLap MCP. The agent asks for access, the member signs in to OneLap, chooses one workspace or all of theirs, and allows it. From then on the agent can read that workspace’s week, save a report and propose a decision. It cannot accept a decision, send, publish or spend; a person does that in OneLap. What the agent reads goes to its provider under your account and your terms with them, so that provider is your choice and not OneLap’s processor. Revoking the connection in Settings ends its access at once.
OneLap’s own path to a model stays closed.
- The endpoint that used to carry chat to a model answers 404 and calls nothing.
- The production transport that would carry anything to an outside processor refuses every request with
No processor transport is admitted. There is no configuration that opens it. - No model provider library is installed, and a build gate rejects any import of one outside the approved transport.
If OneLap ever runs a model itself, that provider becomes a processor, and this page and the in-product data map will name it, its region, its retention, and any intermediary, before it receives anything. Until then, this policy names no AI provider as OneLap’s processor because OneLap uses none.
If no verified route is available, a request fails before transmission rather than falling back to another provider.
Where data is held
Two companies process data for OneLap. Both are in the United States, and there is no other processor of client content.
- Supabase · us-east-1
- Authentication, workspace operational data, and content-free audit metadata. This is where an early-access request is stored.
- Vercel · iad1
- Runs the application. Handles requests in transit, deployment metadata, and content-free runtime logs. Application payload logging is off.
Two further companies handle no client content at all: Doppler holds machine secrets, and GitHub hosts OneLap’s own source code and runs its build. Neither receives your data.
Both processor entries are recorded as needs_verification in OneLap’s own register, and the same status is shown to members inside the product. Two things are open on each: how long deleted data survives in the provider’s backups and replicas, and what completion evidence the provider will produce for a deletion. Until those close, OneLap cannot promise a deletion deadline that covers provider backups, and this page does not make one.
How long things are kept
OneLap classifies every table it owns into one of three schedules. The classification is real and is checked by a test that fails if a table loses its entry. What follows the schedule is the part to read carefully.
- Ninety days
- Conversation content, the signed payloads a run carried, and early-access requests.
- Twelve months
- Content-free evidence: which run happened, which authorization allowed it, which digest it carried. No message text.
- Until the workspace closes
- Business records: results, decisions, projects, sources. They stay while the workspace does, and go with it.
No scheduled job runs these clocks. A database routine that can perform the deletion exists, but nothing invokes it: there is no cron, no scheduled function, and no call to it anywhere in the application. It runs only when a person runs it by hand. Treat the periods above as the schedule OneLap has committed to implementing, and not as a description of deletions that are currently happening.
This page will stop marking the schedule in red when an executor exists and runs on it. That is the same standard the product applies to a measurement: a claim is blue when a mechanism holds it up.
Getting your data out, and having it deleted
Depending on where you live you may have rights to access, correct, export, or delete personal data, and to object to its processing. OneLap does not argue with any of them. What follows is what the product can actually do today.
- Export
- No export exists in the product. no mechanism
- Deletion
- Run by an operator, by hand. no client action
- Access and correction
- By asking. A member sees their own workspace data in the product.
- Your own record
- The repository your canon is written to stays under your control regardless.
A workspace deletion is a purge of that workspace’s content followed by a completion receipt from each processor above. The receipt stays incomplete until every store has confirmed, rather than being marked done when the request is accepted.
There is no published address to send a request to yet. Until one is set, the only working route to a person is the form on the home page, and a member should ask their operator directly. This is a gap, it is stated rather than papered over, and it closes when the publisher supplies a contact address.
Changes, and what this page is not
This page is versioned with the product. When a mechanism changes, the sentence describing it changes in the same commit, and the date at the top moves.
OneLap holds no certification and claims none. There is no SOC 2 report, no ISO 27001 certificate, and no compliance audit behind this page. It describes mechanisms in the code and nothing more. A claim that this product is compliant with a particular regime is not made here and should not be inferred.
Related reading: how OneLap handles data goes through the isolation and secret-handling mechanisms in more detail, and the terms cover the agreement itself.