Privacy Policy

1. The plain-English summary

Pulse is a personal CRM for macOS and iOS. It is built on a local-first architecture: your contacts, your notes, and your interaction history live on your own device, and — if you choose to enable iCloud sync — they are mirrored to your private CloudKit container, which is hosted and encrypted by Apple inside your own iCloud account. Your private data is always private. It is encrypted, it lives inside Apple's infrastructure under your Apple ID, and Pulse cannot access it.

For users who opt in to Pulse's optional cloud contact sync, we go a step further: we use zero-knowledge encryption. Your contacts are encrypted on your device with AES-256-GCM before they ever leave it. We store the encrypted blobs on our servers, but we cannot read them — only your devices have the key. If our database were stolen tomorrow, an attacker would see scrambled bytes and nothing else. Apple iCloud Contacts, Google Contacts, and every major CRM we know of can read your contacts on their servers. Pulse can't.

We do not sell your data. We do not have analytics, ad SDKs, or third-party trackers. We do not build a profile of you.

Two things do leave your device, both because you asked for them. If you turn on the Apple Contacts directory, the contacts you sync are stored on our CardDAV server so they can reach your other devices — you can delete them at any time. And AI features that cannot run on your device send your contacts' information to be processed, then discard it. Neither is kept for any other purpose, sold, or shared.

This document explains exactly what Pulse does with data, what your rights are, and how to exercise them.

2. Who we are

Pulse is built by Gouda Studios. For privacy questions, data requests, or anything else covered by this policy, contact us at privacy@pulserelationships.com.

For purposes of GDPR, Gouda Studios is the data controller for any personal data processed by Pulse. Because Pulse is local-first, the volume of data we actually process is intentionally minimal — see Section 4.

3. What data Pulse uses on your device

Pulse uses the following data on your device to provide its features. This data is stored locally in SwiftData and, if you enable iCloud sync, in your private CloudKit container — a personal database that only your Apple ID can access.

Contacts

Pulse reads your Apple Contacts (via the system CNContactStore framework) and creates a local copy in its own database. Pulse never modifies Apple Contacts automatically. It never writes contact data to any server.

Mail, Calendar, and Messages metadata

Pulse uses metadata from your communication apps to compute "time since last interaction" with each contact. This is metadata only — sender, recipient, and date. We do not read message content, subject lines, or attachments.

• Apple Mail — sender address, recipient address, date received
• IMAP email — From, To, and Date headers only
• iMessage — participant handle (phone or email) and message date
• Apple Calendar — attendee email addresses and event start dates
• CalDAV calendars — attendee email and event start date

We never read message bodies, subject lines, calendar event titles, calendar notes, attachments, or any other content. This is a hard architectural constraint, not a policy choice — see our engineering documentation for the per-source breakdown.

Notes, tags, and CRM fields

Notes, tags, custom fields, relationship tiers, and any other CRM data you add to a contact in Pulse are stored locally in your device's SwiftData store and synced to your private iCloud container. They never leave your Apple account.

Public news and signals

Pulse fetches public news articles from RSS feeds, Google News and public search engines to surface relevant information about people in your network. Only the article URL, title, and a short snippet are stored. Articles are fetched anonymously — the source server only sees a generic web request, not who you are or who you're tracking.

4. What data leaves your device

Pulse minimizes the data that leaves your device. There are exactly four categories of outbound network activity:

(a) Public content fetches

Pulse fetches RSS feeds, Google News and public search-engine results, and public news articles from their original URLs. These requests are anonymous — they go directly from your device to the publisher's server with no Pulse intermediary. The publisher sees a normal web request and never learns who you are or which contacts you care about.

(b) AI inference

Pulse runs AI inference in our cloud AI sidecar — a stateless service hosted on Amazon ECS (Fargate) in the us-west-2 (Oregon) region, which runs Claude Haiku via Amazon Bedrock.

The sidecar itself stores nothing. It is pure compute: each request comes in, gets processed, and the response goes back. There is no database attached to the sidecar service. Anything the sidecar produces that needs to persist is written to CloudKit (see (d) below).

When Pulse calls the sidecar, it sends only the minimum data needed for the task. This means:

• Hashed identifiers for matching, not contact names or email addresses
• Public information only — for example, an article's title and snippet to extract entity names, or a person's name and current company to look up public professional information
• No interaction metadata — message dates, calendar attendees, and similar private metadata never reach the sidecar

(c) Private iCloud sync (your personal data, encrypted by Apple)

Pulse syncs your private data — your local copy of Apple Contacts, your notes, tags, custom fields, relationship tiers, audit log, and any AI-generated content tied to your personal use — to your private CloudKit container. This is a database hosted entirely by Apple inside your own iCloud account. It never passes through any Pulse-owned server, and Pulse never has access to it.

Your private CloudKit container is governed by the same protections as the rest of your iCloud account:

• Encrypted at rest by Apple with AES-256
• Encrypted in transit with TLS
• Per-user isolation enforced by Apple at the platform level — no other Pulse user can see your private CloudKit data, ever
• Access tied to your Apple ID — only you, signed in with your Apple ID, can read or write the data in your container
• Eligible for Advanced Data Protection — if you enable Apple's Advanced Data Protection on your iCloud account, your private CloudKit data is end-to-end encrypted such that even Apple cannot read it

Apple's CloudKit infrastructure is compliant with GDPR, CCPA, HIPAA (where configured), and equivalent international privacy frameworks. The full security model is documented in Apple's CloudKit and iCloud privacy policies.

Practically, this means: if you delete your iCloud account, your private Pulse data goes with it. If you delete the Pulse app from one of your devices, the data on that device is removed but the synced copy in your iCloud container remains until you explicitly delete it. We cannot delete your private CloudKit data on your behalf because we cannot access it — only you can.

(d) CloudKit public database (community-enriched professional information)

Pulse maintains a public CloudKit database that holds publicly-available professional information about people and organizations: job titles, employers, industry, public news mentions, public social media URLs, and similar data sourced from the open web. Records in this database are keyed by a SHA-256 hash of name + company so the same person can be referenced across users without exposing identifying information.

When you use Pulse's "AI Enhance" feature on a contact, the app calls the sidecar to look up that contact's public information, and the result is written to this public database. Subsequent users who happen to have the same contact benefit from the cached enrichment — this is the network effect that lets Pulse deliver richer search and recommendations without storing your personal data centrally.

What goes into the public database:

• Professional name, current job title, current employer, industry, public bio
• Public social media URLs (LinkedIn, X, GitHub, personal website)
• News articles and signals that mention the person or organization
• AI-generated semantic embeddings used for search (these are anonymous vectors that cannot be reversed back to the source data)

What never goes into the public database:

• Your private notes, tags, relationship tiers, or any CRM annotations you have added to a contact
• Phone numbers, email addresses, or any other private contact details
• Your interaction history with the contact — when you last spoke, met, or messaged
• Any data that identifies you as the person who triggered the enrichment

The lawful basis for processing under GDPR is your explicit action: you trigger AI Enhance, and that triggers the lookup. We do not enrich contacts in the background without your action. Separately, Pulse periodically refreshes records that already exist in the public database from open web sources (company websites, press releases, public bios) under our legitimate interest in keeping the shared cache accurate; this never changes anything in your own contacts, which only change when you trigger AI Enhance and then approve the result. You can request removal of any record from the public database by contacting privacy@pulserelationships.com — see Section 8.

(e) Pulse Cloud CardDAV sync (zero-knowledge encrypted)

Pulse can optionally sync your contacts through a cloud server we host so that they appear inside the system Apple Contacts app on every Apple device you own. This is implemented as a hosted CardDAV server at carddav.pulserelationships.com, deployed on Amazon ECS (Fargate) in the us-west-2 (Oregon) region with DynamoDB as the storage backend (replicated to us-east-1 for durability).

Connecting to the CardDAV service is fully opt-in. If you do not enable Pulse Cloud Sync in Settings, no contacts ever leave your device through this path. The architecture below describes what happens when you choose to opt in.

Zero-knowledge encryption for the Pulse app sync path

When the Pulse app syncs your contacts to our CardDAV server, the contact data is encrypted on your device before it ever leaves it. We store the encrypted blob on our servers, but we cannot read it. Only your devices, signed in with your Pulse account, have the key.

The technical specifics, for the curious or the security-conscious:

• Algorithm: AES-256-GCM (authenticated encryption with a 96-bit random nonce per operation), implemented via Apple CryptoKit
• Key derivation: HKDF-SHA256 from your Pulse password and username — derived on-device and never transmitted. We use HKDF (rather than a slow password-stretching function like Argon2) because your Pulse password is generated automatically as a random UUID with ~122 bits of entropy, not chosen by you. That's roughly 5.3 × 10³⁶ possible values — even at billions of guesses per second, brute-forcing it would take longer than the age of the universe. Slow KDFs like Argon2 exist specifically to defend against brute-forcing weak human-chosen passwords; because Pulse never uses a human-chosen password for cloud sync, the slow-down would just hurt legitimate users without adding any security. If we ever support user-chosen passwords, we will switch to Argon2id or an equivalent slow KDF before doing so.
• Key storage: the key lives in your macOS or iOS Keychain (hardware-encrypted on devices with the Secure Enclave) and is mirrored to your other Apple devices via iCloud NSUbiquitousKeyValueStore, which Apple encrypts under your Apple ID
• What's encrypted: the full vCard payload (every contact field, including name, email, phone, and any Pulse CRM data), and the display name shown to the server for sync metadata
• What's not encrypted: the username (used as a partition key for isolation), the contact UID (a random UUID), the etag (a content hash), and the updated-at timestamp — none of these reveal anything about your contacts
• Server detection header: uploads from the Pulse app include an X-Pulse-Encryption: aes-256-gcm header so the server knows the payload is encrypted and treats it as an opaque blob

Practically: if our DynamoDB table were stolen by an attacker tomorrow, or if a Gouda Studios employee tried to read your contacts directly, they would see encrypted bytes — not names, not email addresses, not phone numbers. There is no Gouda Studios path to decrypt your data. The key has never been on our servers and never will be.

If you forget your Pulse password, your encryption key is still synced across your other Apple devices via iCloud. If you lose access to all of your devices, the encrypted data on our servers becomes unrecoverable — this is by design, and is what zero-knowledge means.

Apple Contacts CardDAV path (separate, not zero-knowledge)

Pulse also supports a second CardDAV path for users who want their Pulse contacts to appear inside the system Apple Contacts app on devices that aren't running Pulse. This path uses Apple's built-in CardDAV client, which we do not control, and which sends contact data as plaintext vCards over TLS. Apple's CardDAV client does not support client-side encryption.

If you connect Apple Contacts to Pulse Cloud Sync directly (rather than syncing through the Pulse app), the data on the server for that path is plaintext, encrypted only at rest by DynamoDB's AES-256 default and in transit by TLS. This is the same security model that iCloud Contacts, Google Contacts, Exchange CardDAV, and every other major contact service uses today.

We are honest about this trade-off rather than hiding it: zero-knowledge only works when we control the client. The Pulse app gives you zero-knowledge encryption. The Apple Contacts CardDAV path gives you the same security as iCloud — which is to say, very good, but not zero-knowledge. We recommend syncing through the Pulse app for full zero-knowledge protection, and using the Apple Contacts CardDAV path only when you need contacts to appear in Apple Contacts on a device where Pulse is not installed.

How Pulse Cloud Sync passwords work

Pulse generates your cloud sync username and password for you automatically. Most users never see them: they are random strings created on your device, stored in your Keychain, and synced to your other Apple devices through iCloud. You don't need to remember a password because the app handles it for you.

On the server side, your password is stored as a bcrypt hash with cost factor 12 — we never store your plaintext password. The server uses your password to authenticate you over HTTPS Basic Auth (the same standard iCloud, Google, and Exchange CardDAV use), and then uses your username as the DynamoDB partition key to enforce per-user isolation: there is no query path on our server that can return data across users.

To reduce brute-force risk, the server enforces account lockout (10 failed authentication attempts trigger a 15-minute lock) and rate limiting (120 requests per IP per minute, 3 user registrations per IP per day).

You can revoke your Pulse cloud sync at any time from Settings, which will stop the app from syncing further contacts. To delete the encrypted contact data we hold for you, see Section 8 — there is a self-serve endpoint that permanently deletes your account and all data on the server in one call.

(f) Apple StoreKit (subscription and credit purchases)

Subscription purchases and credit pack purchases go through Apple's StoreKit and App Store. We see only the receipt — a server-to-server confirmation from Apple that you completed a purchase. We do not see your credit card, your Apple ID email, or any other Apple account information beyond what is necessary to validate the purchase.

What never reaches our servers

• The content of any email, message, or calendar event
• Your private notes, tags, or CRM annotations
• Your interaction history with anyone
• Any data that links you (the user) to specific contacts in the public database
• Any data we could use to identify or track you across services

5. What we don't do

• We do not sell your data. Pulse has no advertising business model and never will. Our entire revenue comes from subscriptions and credit packs paid through the App Store.
• We do not use third-party analytics or trackers. No Google Analytics, no Mixpanel, no Segment, no Firebase, no Crashlytics, no Sentry. We don't know how many people use Pulse on a given day, and we're fine with that.
• We do not use third-party advertising SDKs. No IDFA, no AppTracking Transparency prompt, no ad networks. Pulse is invisible to the ad ecosystem.
• We do not sync your data through our servers. CloudKit sync goes directly between your devices through Apple's infrastructure.
• We do not have a database of users. Beyond Apple's record of who paid for the app, we don't maintain a customer database. We don't know your name, email, or anything about you.

6. Permissions Pulse requests

Pulse requests the following macOS and iOS permissions. Each one is optional except where noted, and each can be revoked at any time in System Settings.

• Contacts — required. Pulse needs read access to Apple Contacts to import them into its own local store. Pulse never modifies your Apple Contacts automatically.
• Calendar — optional. Used to track meeting attendees and generate meeting briefs. Read-only, attendee email + start date only.
• Mail and Messages — optional. Used to compute "time since last interaction." Reads metadata only (sender, recipient, date). Never reads message content.
• Notifications — optional. Used for the weekly digest only.
• Network access — required. Used to fetch public news, contact the AI sidecar, and sync via iCloud.

6a. Google account data

Connecting a Google account is optional. Pulse works fully without it. This section describes exactly what Pulse accesses if you do connect one, and exists because Google requires it for the scopes below.

What Pulse requests, and why

• openid, email— reads your Google account's email address. Needed as the username for the IMAP connection below. Nothing else.
• contacts.readonly and contacts — read your Google Contacts so they appear in Pulse, and write back changes you make in Pulse so the two stay consistent. Without write access, edits in Pulse would silently diverge from Google.
• https://mail.google.com/ — grants IMAP access. Pulse uses it to answer one question: when did you last exchange email with this person?

What Pulse actually reads from Gmail

Only the From, To and Date headers. The IMAP command Pulse issues is literally UID FETCH (BODY.PEEK[HEADER.FIELDS (FROM TO DATE)]).

• Never message bodies, subject lines, attachments, labels or drafts.
• BODY.PEEK means Pulse does not even mark messages as read — your mailbox is unchanged by Pulse looking at it.
• Pulse never sends email through this scope.

Google classifies https://mail.google.com/ as a restricted scope because it can grant full mailbox access. Pulse requests it because IMAP XOAUTH2 offers no narrower alternative — there is no header-only Gmail scope. What Pulse does with the access is the header fetch above, and nothing more.

Where it goes and how long it stays

• Header metadata is stored on your device and in your own private iCloud database. It is never sent to our servers.
• Contacts imported from Google are treated exactly like any other Pulse contact — see sections 3 and 4.
• OAuth tokens are held in your device Keychain, never on our servers.
• Retention follows your setting in Settings → Data (default 90 days, range 30–365).

How to remove it

• Disconnect the account in Pulse — Settings → Connections. This deletes the stored tokens and the derived interaction metadata.
• Revoke Pulse independently at myaccount.google.com/permissions.
• Deleting your Pulse account removes all of it.

Limited Use

Pulse's use and transfer of information received from Google APIs to any other app adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Concretely: data obtained through Google APIs is not used to train generalized AI or machine-learning models, is not read by humans, and is not sold or transferred except as needed to provide the features described above. Cloud AI runs on Amazon Bedrock, which under AWS terms does not retain or train on customer data — see section 4.

7. Data retention

You control how long Pulse retains data. By default, signals and news events are kept for 90 days, after which they are automatically purged. You can change this retention period (between 30 and 365 days) in Pulse → Settings → Privacy → Data retention.

Notes, tags, contact CRM data, and audit logs are retained until you delete them. The audit log is append-only — it can be exported or deleted in full but individual entries cannot be modified. This is intentional: it provides a tamper-evident record of any AI-suggested changes Pulse makes.

When you give or withdraw a consent in the app (such as acknowledging AI processing or opting into news radar), we keep a record of that choice — what you agreed to, the version of the text shown, the date and time, and the platform — attached to your account so we can honor and demonstrate your choices. These records are deleted with your account.

8. Your rights

Because Pulse stores almost everything on your device, you have direct, first-class access to your data at all times. You don't need to file a request to see what we have on you — you can open the app and look.

Right to access (GDPR Art. 15, CCPA § 1798.110)

For data on your device: use Settings → Privacy → Export all data to download a complete JSON export of every Pulse record stored locally.

For data on Pulse Cloud Sync (if you opted in): we expose a self-serve API endpoint at GET /privacy/export on carddav.pulserelationships.com, authenticated with your Pulse cloud sync credentials. The Pulse app provides a UI for this in Settings → Privacy → Cloud sync → Export cloud data. The export contains all the encrypted contact records stored for your account, plus the metadata required to interpret them. Because of zero-knowledge encryption, the export is decrypted on your device after download.

Right to rectification (GDPR Art. 16)

Edit any contact, note, tag, or CRM field directly in the app. AI-suggested changes always have an undo option in the audit log.

Right to erasure (GDPR Art. 17, CCPA § 1798.105)

For data on your device: use Settings → Privacy → Delete all data to permanently delete every Pulse record stored locally. This does not affect your Apple Contacts.

For data in your private CloudKit container: sign out of iCloud in System Settings, or use Settings → Privacy → Delete iCloud data inside the Pulse app.

For data on Pulse Cloud Sync (if you opted in): we expose a self-serve API endpoint at DELETE /privacy/account on carddav.pulserelationships.com, authenticated with your Pulse cloud sync credentials. The Pulse app provides a UI for this in Settings → Privacy → Cloud sync → Delete cloud account. This call permanently deletes your user record, every encrypted contact stored under your account, and the bcrypt password hash, in a single atomic operation. Because we operate zero-knowledge, we cannot recover any of this after deletion — there are no backups we can dig the data out of.

For data in the CloudKit public database (records about a person or organization that were created when you or someone else triggered AI Enhance): contact privacy@pulserelationships.com with the contact name. Public records are not linked to any user identity, so we delete the record itself rather than "your copy of it." We will process the request within the 30-day GDPR statutory window.

Right to restrict processing (GDPR Art. 18)

Pulse supports per-contact opt-out: open any contact and toggle "Pause syncing this contact" to stop Pulse from updating, scoring, or running AI on that specific contact while preserving the existing record.

Right to data portability (GDPR Art. 20)

The JSON export from "Export all data" is a machine-readable format you can import into any other tool.

Right to object (GDPR Art. 21)

You can disable any individual processing pipeline (signal ingestion, AI inference, embedding generation, etc.) in Settings → Privacy → Processing.

CCPA "Do Not Sell or Share My Personal Information"

Pulse does not sell or share personal information. There is no data to opt out of selling — selling is architecturally impossible for us because we don't have access to your data in the first place.

How to exercise your rights

The fastest path is to use the in-app controls — they take effect immediately, on your device, without us in the loop. If you cannot access the app, or you want a written confirmation, email privacy@pulserelationships.com and we will respond within 30 days as required by GDPR.

9. International data transfers and where data lives

Your data lives on your devices and, if iCloud sync is switched on, in your own private iCloud database — never on ours. Here is a complete inventory of where data could end up:

• Your device — your contacts, notes, tags, audit log, and interaction metadata live in local SwiftData storage on your Mac, iPhone, and iPad. Encrypted at rest by macOS FileVault and iOS Data Protection when those features are enabled.
• Your private iCloud (Apple's CloudKit) — your private CloudKit container holds the same data your device holds, replicated for cross-device sync. This data is encrypted at rest by Apple with AES-256, and in transit with TLS. Per-user isolation is enforced by Apple at the platform level. Pulse cannot access this data — only your Apple ID can. Apple's CloudKit infrastructure is compliant with GDPR, CCPA, and equivalent international privacy frameworks.
• The shared CloudKit public database — also hosted by Apple, but in a separate "public" container that holds professional information about people and organizations (not about you). Records are keyed by hashes, not by user identity, so there is no link from a public record back to you. Apple is the data processor for this database; we are the data controller.
• AWS us-west-2 (Oregon) — the stateless AI sidecar runs here on Amazon ECS (Fargate). The sidecar has no database. It receives a request, calls Claude Haiku via Amazon Bedrock (also us-west-2), and returns the result. Nothing is persisted beyond the lifetime of the request. For users in the European Union, the data we send to the sidecar (your contacts' information for the request in hand, plus public news) does not constitute personal data under GDPR Article 4(1) because individuals cannot be identified from it. We will publish Standard Contractual Clauses with our cloud providers as required.
• AWS us-west-2 (Oregon) — the Pulse Cloud CardDAV server runs here on Amazon ECS (Fargate) with DynamoDB as its backend (replicated to us-east-1 for durability). Only users who opt-in to CardDAV sync have any data here. Each user's contacts are stored in their own DynamoDB partition, encrypted at rest with AES-256, with credentials stored as bcrypt hashes.
• Public content fetches — go directly from your device to the publisher's server, with no Pulse server in between. RSS feeds, Google News, and individual article fetches are anonymous web requests.

10. Children's privacy

Pulse is rated 16+ in the App Store and is intended for adults using professional contact management tools. We do not knowingly collect data from anyone under 13. If you believe a child has installed Pulse and you want their data deleted, note that uninstalling the app is not sufficient on its own — it removes the app and its local store, but anything already synced to iCloud stays in that iCloud account. Use Settings → Privacy → Delete all data to erase the local records and Settings → Privacy → Delete iCloud data to erase the synced copy, as described in section 8. Contact us if you need help.

11. Security

Pulse implements defense-in-depth security across every layer that exists in our architecture. Specifics, with no marketing fluff:

On your device

• Encryption at rest: macOS FileVault and iOS Data Protection (when enabled) protect the local Pulse SwiftData store
• Sensitive credentials (IMAP passwords, OAuth tokens for social media APIs, Pulse cloud sync password, zero-knowledge encryption key) are stored in the macOS or iOS Keychain — hardware-encrypted on devices with the Secure Enclave, never in regular files or in our database
• The Pulse cloud sync password is generated automatically by the app — you never have to choose, type, or remember it. It is a random UUID created on-device and stored in your Keychain

In transit

• All cloud network connections use TLS 1.2 or later with AWS-managed certificates (Pulse Cloud Sync, AI sidecar)
• iCloud sync uses Apple's TLS-encrypted CloudKit transport
• HTTPS-only — Pulse does not fall back to plaintext HTTP for any cloud endpoint

At rest, on our servers

• DynamoDB (Pulse Cloud Sync, us-west-2 with us-east-1 replica) — AES-256 by AWS default, with AWS-managed keys
• Plus zero-knowledge encryption for the Pulse app sync path: AES-256-GCM applied client-side before upload (see Section 4e)
• CloudKit (Apple) — AES-256 by Apple, eligible for Apple's Advanced Data Protection (end-to-end encryption)
• The AI sidecar has no database — it stores nothing, ever, between requests

Authentication and authorization

• Pulse Cloud Sync passwords: bcrypt with cost factor 12 — we never store plaintext, and never see your password after it leaves your device for the initial registration call
• Account lockout: 10 failed authentication attempts on the same account triggers a 15-minute lock
• Rate limiting: 120 requests per IP per minute, 3 user registrations per IP per day. Health checks are exempt from rate limiting.
• Per-user isolation: every database query on Pulse Cloud Sync is scoped by the authenticated username via DynamoDB partition keys. There is no query path that can return data across users — not even an admin path.
• IAM scoping: the AWS role used by Pulse Cloud Sync is scoped to PulseCardDAV* tables only. It cannot reach any other AWS resource in our account.

Logging policy

We log only what we need to diagnose issues and enforce rate limits. We deliberately do not log anything that could be used to reconstruct user activity:

• What we log: request method, request path, response status code, processing time in milliseconds, source IP for rate limiting, authentication failures (username only)
• What we never log: request bodies, response bodies, vCard contents, contact names, contact emails, contact phone numbers, successful authentication usernames, passwords (ever)
• Where logs go: AWS CloudWatch, retained for 30 days, access scoped to the platform team

Reporting a security issue

We do not run a formal bug bounty program at this stage, but we take security reports seriously. If you believe you've found a vulnerability in Pulse, please email security@pulserelationships.com with reproduction steps. We aim to respond within 5 business days. Please give us a reasonable disclosure window before publishing — we will credit you in the security acknowledgments page once a fix ships, if you'd like.

12. Changes to this policy

If we materially change how Pulse handles data, we will update this policy and notify users via an in-app notification before the changes take effect. Past versions of this policy will be archived on this page for transparency.

Routine clarifications, typo fixes, and contact-info updates do not trigger a notification but will still be reflected in the "Effective" date at the top of this document.

13. Contact

Questions about this policy, data requests, or anything privacy-related:

privacy@pulserelationships.com

For general support, use support@pulserelationships.com.

For security issues, use security@pulserelationships.com.