Privacy Policy

Personal information is information or an opinion about an identified individual, or an individual who is reasonably identifiable, whether the information or opinion is true or not, and whether the information or opinion is recorded in a material form or not.

We may collect personal information through various means, including:

• Direct correspondence with you
• Telephone conversations
• Email communications
• Our website and platform
• Mobile applications
• Publicly available sources

The types of personal information we collect may include your name, email address, contact details, billing information, and any other information you provide when using our services.

Sensitive information includes information about an individual's racial or ethnic origin, political opinions, membership of a political association, religious beliefs or affiliations, philosophical beliefs, membership of a professional or trade association, membership of a trade union, sexual orientation or practices, criminal record, health information, genetic information, or biometric information.

We will only collect sensitive information where it is reasonably necessary for our functions or activities, and either you have consented, or we are required or authorised by law to do so. Any sensitive information collected will only be used for the primary purpose for which it was collected, a directly related secondary purpose, or with your consent.

We may collect personal information about you from third parties. If we do so, we will take reasonable steps to notify you that we have collected this information and the circumstances of its collection. Third-party sources may include service providers, business partners, or publicly available sources.

We may disclose your personal information to third parties in the following circumstances:

• With your consent
• Where required or authorised by law or a court/tribunal order
• To our service providers who assist in operating our platform
• To protect the rights, property, or safety of Altacomm, our users, or others

We take reasonable steps to ensure that any third parties to whom we disclose your personal information are bound by privacy obligations in relation to your personal information.

We take reasonable steps to protect your personal information from misuse, interference, loss, unauthorised access, modification, or disclosure. We implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.

Client files are retained for a minimum of seven years after the conclusion of our services, unless a longer retention period is required by law or for legitimate business purposes.

You have the right to request access to your personal information that we hold. You also have the right to request that we correct any personal information that is inaccurate, out-of-date, incomplete, irrelevant, or misleading.

We do not charge a fee for you to access your personal information, although we may charge a reasonable fee for providing copies of information. We will respond to requests within a reasonable timeframe.

We take reasonable steps to ensure that the personal information we collect, use, and disclose is accurate, up-to-date, complete, and relevant. We encourage you to contact us if your personal information changes or if you believe the information we hold is inaccurate.

When you connect your tday account to Slack, we collect and process certain data from your Slack workspace. This section details what data is collected, how it is used, how long it is retained, and how you can manage it.

Data We Collect

When you install the tday Slack app, we collect and store the following:

• Your Slack workspace ID and name
• Your Slack user ID and display name
• An OAuth access token (encrypted at rest using AES-256-GCM) and granted scopes
• Conversation state related to design creation (current step, prompts, and preferences)
• Brand-to-workspace associations you configure

We may also retrieve your email address from the Slack API on-demand to match your Slack identity with your tday account. Email addresses fetched this way are used only for account matching and are not stored separately.

How We Use This Data

We use the data collected through the Slack integration to:

• Authenticate and maintain your connection between tday and Slack
• Process design creation requests you initiate via Slack commands and messages
• Deliver generated designs and notifications back to you in Slack
• Associate your preferred brand with your Slack workspace

We do not use Slack data to train large language models (LLMs) or for any purpose unrelated to providing the tday service.

Data Retention

When you disconnect your Slack workspace from tday, your OAuth access token is revoked with Slack and your connection and conversation records are deactivated. Deactivated records are retained for up to 90 days for troubleshooting and audit purposes before being permanently deleted.

Webhook delivery records (containing only event type and deduplication identifiers, not message content) are retained for operational integrity.

Access, Portability & Deletion

You may request access to, export of, or deletion of your Slack integration data at any time by contacting us at privacy@altacomm.co. You can also disconnect your Slack workspace directly from your tday dashboard or by using the /markup disconnect command in Slack, which will immediately revoke access and deactivate all associated data.

We will respond to data requests within 10 business days.

Meeting Assistant helps authorised tday administrators transcribe standups, attribute speech, and prepare rolling notes. Meeting audio, transcript text, speaker names, and generated notes can contain personal or sensitive information about people other than the person operating Meeting Assistant.

Browser Extension Speaker Attribution

The extension's single purpose is to route a speaker name extracted from supported meeting-service active-speaker interface elements to tday Meeting Assistant so the live transcript can be attributed.

Speaker attribution is off by default. After the extension user turns it on, the extension reads text and name attributes from visible interface elements matched by its active-speaker selectors on Google Meet, Zoom, and Microsoft Teams pages. Its content script can run on every page path covered by the allowlisted host patterns and observes document changes across the page for selector candidates. Observation can continue while that extension-wide setting is enabled, even when live audio capture is not running.

The extension forwards these speaker-attribution fields:

• Speaker display name and meeting platform
• Confidence and signal timestamp
• A temporary source ID, sequence number, and source type used to route and validate the signal

The current meeting-page URL, sender URL, and browser tab ID are used locally to recognize and validate the source and platform. The full meeting URL is not forwarded or persisted. The forwarded speaker signal does not include audio, chat, or cookies. Speaker signals pass through the extension runtime to an open tday standup review page and, when installed, the local tday Mac native host. Meeting Assistant uses them to label transcript segments. The extension popup provides a control to turn attribution off.

Extension Consent and Local State

The browser's extension storage and a matching IndexedDB mirror keep a version number, whether speaker attribution is enabled, the time that setting was last changed, and an opaque decision ID used to reconcile changes safely. This is an extension-wide setting with no automatic expiry. It is not a per-meeting setting and does not record consent from each meeting participant.

A separate, metadata-only local journal keeps browser tab IDs, opaque source IDs, timestamps, and removal records so stale sources can be removed safely. It does not keep names, transcript text, platform, meeting URLs, cookies, or audio. Active mappings become eligible for pruning after 24 hours and removal records after 60 seconds. Pruning occurs when the journal is next loaded or updated, so those periods are not guaranteed physical deletion deadlines. A journal write failure does not currently stop otherwise valid live routing, so restart reconciliation is not guaranteed after a failed write.

The meeting-page content script can keep the last detected name in memory until the name changes or observation stops. The popup can keep the latest speaker status while it remains open. The background registry treats a speaker signal as fresh for 30 seconds and prunes it lazily during later operations. A port waiting for an asynchronous restart snapshot can buffer up to 512 named signals in memory until the snapshot settles or the port disconnects; that buffer has no separate time limit. Speaker names are not written to the persistent source journal.

Browser and Mac Audio Capture

In the hosted browser experience, audio capture starts only after an explicit user action. It combines audio from a browser tab selected by the user, which should be the meeting tab, with that user's microphone. Hosted capture rejects a whole window or monitor as the selected source, but it cannot verify which browser tab the user chose.

The Mac app uses a different capture boundary. Its capture notice explains that it captures whole-Mac audio together with the microphone, so audio from unrelated applications may be included. The browser extension itself supplies speaker-attribution metadata and does not capture or forward audio.

Chromium requires the capture picker to return a temporary display video track even though Meeting Assistant processes audio only. After checking the selected capture type and confirming an audio track, tday stops every video track immediately before requesting microphone access. Meeting Assistant does not read, encode, transmit, or save the screen or tab pixels.

For native speaker attribution in Zoom and Microsoft Teams, the Mac app requires macOS Accessibility permission. Native attribution is off by default even if macOS has already granted that permission. Enabling it requires a currently authenticated and exact-device-approved desktop session. The choice is bound to the approved tday account and can resume on a later launch only for the same approved tday account after the app validates a current approval lease.

While enabled and the Mac app and approved session remain active, a local helper continuously checks Zoom and Microsoft Teams Accessibility trees twice per second for role and description fields that identify a speaker. This scanning continues while audio capture, Live Notes, and the overlay are off. The helper returns the first matching speaker label to Meeting Assistant. This native path is separate from the browser-extension setting, which must be controlled separately.

The local native setting stores only a format version, whether native attribution is enabled or disabled, and, when enabled, the approved tday user ID that owns the choice. It does not store participant names, transcript text, notes, meeting URLs, cookies, or audio. The Mac app revalidates exact-device approval periodically and before enabling. On expiry, revocation, a validation failure, sign-out, or the start of a full browser authentication flow, it blocks new native signals, asks the helper to stop, clears current live native sources, and attempts to record Off locally.

Separately, the Mac app stores an encrypted approval ID and device nonce in its local application-data directory using Electron safeStorage. The app presents that proof with the current desktop session so the same Mac can prove its exact-device approval after a restart. The proof is not a participant name or meeting record. The app clears or replaces it during the corresponding sign-out, revocation, invalid-session, or approval-replacement paths, subject to the local storage operation succeeding.

Better Auth Electron storage keeps safeStorage-encrypted session and cache values, including desktop authentication data, in the Mac app's local application-data directory. The app's local sign-out paths attempt to clear that encrypted file. Protected authentication cookies are filtered out of the embedded Chromium cookie jar and attached to trusted tday requests from the separate encrypted store.

The Mac app also attempts to write a pending sign-out marker to local application data before asynchronous server revocation or sign-out cleanup begins, including when a hosted sign-out request starts or a full account switch begins. The marker contains only a format version and no authentication, meeting, or participant data. If the app stops before cleanup finishes, the next launch treats a complete or interrupted marker as pending and attempts to clear the encrypted session cache and exact-device approval proof before loading desktop authentication. The marker is removed only after the required local cleanup succeeds. A cleanup failure keeps the marker so a later launch can retry and the app fails closed rather than restoring that retained session. If marker creation fails, the app blocks the current authentication in memory and attempts to clear the local proof and session immediately. It cannot guarantee restart recovery if both marker creation and that immediate local cleanup fail.

The embedded tday surface uses a persistent Chromium profile with its cache enabled. Ordinary Chromium cache, site storage, permissions, and other profile state may therefore remain in local application data after the app closes. The app does not currently run a general profile or cache erasure during sign-out. This profile is separate from the encrypted Better Auth file and approval proof described above.

Desktop approval security records are also kept on the tday server. They include the target and approving user and session references, hashes of the approval code and device nonce, the scheduled expiry, approval, consumption, denial, and revocation timestamps, and creation and update times. The raw approval code and device nonce are not stored in that database record. Expiry is derived from the scheduled expiry when the record is read and does not itself write a separate expiry timestamp or update the row. Approval, consumption, denial, and revocation update the applicable lifecycle timestamps. These records are not automatically deleted merely because the approval expires.

Each successful desktop approval action also attempts to create a separate administrative audit row. It can include the acting administrator, action, target session reference, approval reference, browser session or scheduled expiry details when applicable, client IP address, and creation time. An audit-write failure does not block the approval action. These administrative audit rows have no automatic deletion period in the current system.

Turning native attribution Off from the menu has the same immediate signal block, stop request, and current live native-source cleanup. It does not turn off the browser extension. It does not revoke the Mac app's Accessibility permission in macOS System Settings, and it does not erase names already applied to transcript segments, rolling notes, or saved notes. If both replacing and removing the local setting fail, signals stay blocked for the current app process and the menu asks the administrator to Retry Saving Native Speaker Names Off. Revoke Accessibility in System Settings before reopening tday if Off could not be saved. Quit tday and revoke Accessibility if the menu reports that helper exit could not be confirmed.

Processing by tday and Google

Google is an AI service recipient in the following separate processing paths:

• Live transcription: the hosted browser or Mac renderer sends 16 kHz PCM audio directly to Google over a live connection using a one-use, short-lived credential. The long-lived Google API key stays on the tday server. Speaker-attribution metadata is attached to returned transcript text locally and is not sent alongside that live PCM stream.
• Diarisation: a separate audio window is sent through tday to Google approximately every 10 seconds. Each request is limited to 30 seconds and 2 MiB. tday sends the audio inline in a request configured with store: false and does not create a Google File API object.
• Rolling notes: the hosted browser or Mac renderer automatically sends tday the meeting title, prior outline, and up to 200 recent final transcript segments, including timestamps and any applied speaker names. tday sends Google up to 40,000 transcript characters, speaker labels, the meeting title, and the prior outline to generate updated notes. This rolling window may be sent again as the transcript changes.

The request settings described above do not state or guarantee Google's own logging, abuse-monitoring, data-residency, training, or retention practices.

Transient State and Saved Notes

During a live session, the browser client keeps the current transcript and interim text in application memory. Extension signals are treated as fresh for 30 seconds in the background registry and are removed lazily during later registry operations. The hosted client keeps at most 80 raw attribution events for 60 seconds. Its diarisation audio ring is bounded to 30 seconds. The client schedules a failed diarisation window for discard 30 seconds after its first failure and checks that deadline before each retry. It aborts a retry that is still running when the discard callback executes. Browser timer suspension may delay physical release until page execution resumes. A normal diarisation request is aborted after 30 seconds. The ring and retry window are cleared when capture is stopped or discarded, the meeting changes, or the page is unmounted. The transcription pre-roll is capped by chunk and encoded-size limits. Stopping capture closes audio tracks, connections, and audio buffers, but final transcript segments remain in the current page state until the transcript is cleared, the meeting changes, or the page is unmounted.

Meeting Assistant creates a durable note record only when an administrator explicitly selects Save. The saved record contains formatted notes and structured summaries, updates, blockers, decisions, actions, and questions. Generated notes may include participant names, statements, decisions, or other transcript-derived information. The durable record also keeps a meeting reference and snapshot, revision, actor identifiers, and creation or update timestamps.

The Save action does not persist raw audio, the full transcript, raw extension signals, source IDs, or diarisation words and turns in the saved note record. Saved Meeting Assistant notes do not currently have an automatic expiry or deletion action. A Save audit record stores the administrator, meeting reference, action, note kind, client IP, and time, but not the note or transcript body. Deleting a user or meeting reference does not currently guarantee erasure of the saved note or its meeting snapshot.

Usage Metadata and Operational Logs

Model-usage records keep the associated actor or user, model and provider, operation and category, token counts, cost, and timestamps. They do not contain the prompt, transcript, or generated note content.

The hosted tday application also loads PostHog, Databuddy, Vercel Speed Insights, and Cloudflare Web Analytics on Meeting Assistant routes when those services are enabled for the deployment. They may receive standard technical and usage metadata, such as network and browser details, route or occurrence references, navigation, interactions, element attributes, performance measurements, and errors. PostHog session replay is enabled. tday marks the standup workspace for PostHog content masking, sanitizes Meeting Assistant pageview and exception locations, and omits standup-review API requests from PostHog network capture. These controls do not mean that every analytics provider receives identical fields or applies the same retention practices.

When configured in a deployed build, Sentry receives client error reports and structured client logs through a first-party tday endpoint. Its error-triggered session replay is sampled for every captured error, with all text masked and all media blocked. Idle sessions are not sampled for replay, and default PII transmission is disabled. These controls do not prevent an error report or masked replay from carrying other technical context permitted by the Sentry configuration.

The embedded Mac Chromium renderer loads the same hosted routes as a browser. Deployment-enabled analytics and error telemetry can also run there under the same hosted-client configuration.

If an admin route fails unexpectedly, operational logs may include the user ID, route path and meeting reference, route parameters, error message, and stack trace. Internal mirrored copies of ordinary runtime logs are retained for 60 days, and warning, error, or fatal logs for 120 days. Copies retained by hosting or AI providers are governed separately and are not covered by those internal periods.

Access, Notice, and Privacy Requests

In-product Meeting Assistant access is limited to authenticated tday administrators who pass the applicable browser or desktop security gate. The current standup review does not provide a separate attendee, company-member, or per-meeting access list. An authorised app administrator can therefore access configured standup occurrences.

The organisation and person operating Meeting Assistant are responsible for giving participants appropriate notice and obtaining any permission or other lawful basis required before capturing or processing a meeting. Requirements vary by location and context, including recording, workplace, and privacy laws.

To ask about access, correction, or deletion of Meeting Assistant information, contact privacy@altacomm.co. We may need to verify your identity, authority, and the relevant account or meeting before assessing a request under applicable law. Submitting a request does not itself automatically erase a saved note.

Chrome Web Store Limited Use

The use of information received from Google APIs will adhere to the Chrome Web Store User Data Policy, including the Limited Use requirements.

We limit raw, scraped, and derived user data collected through the extension to providing or improving its disclosed single purpose and related operations permitted by that policy. We transfer that data only where the policy permits, such as where necessary for that purpose, to comply with law, to address security or abuse, or as part of a corporate transaction with the required prior consent. We do not sell or transfer it to data brokers, use or transfer it for personalised advertising, or use it for creditworthiness or lending.

This Privacy Policy is available on our website. We may update this policy from time to time to reflect changes in our practices, technology, legal requirements, or other factors. We encourage you to periodically review this page for the latest information on our privacy practices.

If you have any questions, concerns, or complaints about how we handle your personal information, please contact us:

We will respond to your enquiry or complaint within 10 business days. If you are not satisfied with our response, you may lodge a complaint with the Office of the Australian Information Commissioner (OAIC).