Privacy

The behavioral layer runs locally

This site observes how you move through it — which zones you visit, which projects and research entries you open, how long you dwell — and infers a rough interest profile (researcher, developer, partner, explorer) to prioritize a link or offer a hint. All of that is computed in your browser, inside the current tab session.

None of it is transmitted anywhere. There is no behavioral beacon, no server-side profile, no identifier tied to you. The session model is discarded when you close the tab; the only traces kept in sessionStorage are which hints were already shown (slp-hints-fired) and whether you dismissed the adaptive signal line (slp-spotlight-dismissed) — so the interface does not repeat itself within a session.

Ask Lab — the site guide

When you use Ask Lab, your question is sent from the laboratory’s own server to a third-party, managed large-language-model inference service, which runs an open-weight model to generate the answer. Your browser never talks to that service directly, and no analytics, cookies or identifiers travel with the request — only the question text and the laboratory’s own catalogue of projects and research that the answer is grounded in.

The laboratory does not use your questions for profiling or advertising and keeps no long-term conversation history of them; the provider processes each request to return a reply and is bound by its own terms. The endpoint is rate-limited by IP address to keep it available — that is the only use made of your IP there. If you would rather not have a question leave your browser, the terminal (type terminal or > in Ask Lab) answers entirely on-device from the same catalogue.

Command Center rooms

Creating or joining a room stores your self-chosen guest name, shared goal, tasks and room messages on the lab server. Names do not verify identity. Anyone with the invitation link can join. Shared tasks and messages are visible to room members; personal tasks are accessible only through your guest session. Losing that session loses access to those personal tasks; account recovery is not available.

The necessary HttpOnly slp_command_session cookie grants room access for seven days after the last activity signal. The creator’s invitation is kept in the current tab’s sessionStorage for copying; messages are not stored there. Authenticated live updates, with periodic reads as a fallback, keep participants synchronized. Presence comes from the open tab’s activity signals and becomes away after 60 seconds without a signal.

The server retains the latest 500 room messages and returns the latest 200. Each room allows 100 guest identities and 500 tasks. Shared Lab settings, job requests and statuses, public role conclusions, generated instruments, votes and links to created tasks are also stored. Old job and instrument history is pruned; recent jobs, retained instruments and the usage-limit ledger remain. Rooms and their content are deleted on the next service access after 30 days without participant activity. Signing out revokes your session; it does not delete the room’s shared work.

The personal assistant in Atrium

Atrium personal conversations are stored on the lab server, with up to 400 recent messages per guest identity. Only your room session can read them. A request sends the room goal, shared and your personal tasks, the selected private thread, team and personal instructions, and selected authorized extracted files to the configured model provider. Conversation context is limited by the room setting (up to 40 messages). An answer becomes shared only when you explicitly share it. Edits and deletion change your stored history; they cannot recall input already sent to the provider. Losing the guest session loses access to this history. The provider processes requests under its own terms.

Shared Lab — enabled for the room

Shared Lab starts disabled. The room creator controls shared settings and can permit other members to change them. Proactivity settings select message, completed-task and file-upload triggers, intensity and the default skill. In mention mode, Lab responds to @Lab and explicit skill requests. Enabling Lab requests an initial brief. These are room-wide settings.

An enabled Lab sends a bounded shared snapshot to the configured model provider: goal, up to 30 guest names, 60 shared tasks, up to 40 recent messages in the selected thread (1800 characters each), eight existing instruments, room instructions and selected enabled shared files. File text has a combined context limit of 24,000 characters; shortened sources are marked. Records include internal identifiers. Personal tasks, personal files, private conversations, invitation tokens and cookies are excluded. Independent architect and challenger passes feed a composer, normally using three requests with bounded fallback or repair. Only public conclusions and execution evidence are shown.

Validated replies and instruments are saved in the shared room, and Lab can change an unlocked layout. Generated content is rendered as text and predefined controls; it cannot run arbitrary code. Participants choose whether to vote, pin, dismiss or turn a proposed item into a task. Queued work, retries and request sizes have limits. Lab settings follow the room permissions; available run cancellation controls remain explicit. Stopping cancels queued and running work and prevents its later publication, but does not erase existing materials or recall context already sent to the provider. Hidden model reasoning and provider error bodies are not stored as room history.

Workshop — creating and refining team instruments

A Workshop request sends the prompt, room goal and instructions, shared members and tasks, the selected Workshop thread and selected enabled shared files through the lab server to the configured model gateway. Files have a combined context limit of 24,000 text characters. Refining an instrument also includes its program, tests and current shared state. Personal tasks, personal files and private conversations are excluded. The provider processes requests under its own terms.

Workshop messages, build requests, progress, generated instruments and their revisions are stored on the lab server and are shared with room participants. Values saved through an instrument’s controls become its shared state and are visible to other participants. Generated programs run in an isolated environment on the server; the browser displays validated controls and results. A request to refine an instrument can send its saved inputs and results back to the model as part of the current state.

Export requires an explicit action: “Download widget and current state” downloads a JSON file containing the instrument specification, generated program and current shared state. “Copy JSON” copies the same content to your clipboard. These exports can contain the team’s saved inputs and results.

Analytics — off until you consent

No analytics scripts load before you make an explicit choice in the consent bar. Your choice is stored as a single JSON entry in localStorage under the key slp-consent — it records the decision and its timestamp, nothing else.

At the time of writing, no analytics are wired into the site at all: the consent gate exists ahead of them, and any future analytics can only load through it.

To withdraw consent, reset your stored choice here — the consent bar reopens and analytics will not load from the next page view on. Clearing this site’s data in your browser has the same effect.

What this site never does

• No device fingerprinting for identification or tracking.
• No advertising and no marketing pixels.
• No verified accounts or server-side browsing-interest profiles. Guest rooms store the collaboration data described above.
• No cross-site tracking or sale of data. Shared room content is available to room participants.

Honesty about the agent layer

Parts of the interface show the laboratory’s ambient agent population. When the site’s own verification of the observer’s hash chain succeeds, that activity is real, model-backed agent behavior from the Genesis-Live universe. When the observer is unreachable, the interface falls back to a labeled simulation of the same working structure. Either way, real metrics — counts, statuses — come only from the laboratory’s content registries, build state, and, when available, the verified observer chain.

Questions

For anything about this policy or the data practices behind it, write to andrew@xteam.pro.