Arbor is a performance-review tool that reads activity data from third-party systems you choose to connect (today, GitHub and Jira) and produces evidence packets that managers and calibration committees use as input to performance reviews. This policy describes what data Arbor collects, how it is stored and used, and the choices you have.
Arbor is in early beta. We will update this policy as the product matures; the “Last updated” date at the top of this page always reflects the current version.
1. Who is responsible for your data
Arbor is operated by an independent developer based in India. For any question about this policy, data access, correction, or deletion, email madhavsainanee123@gmail.com.
2. Data we collect from connected systems
When an administrator at your company connects Arbor to a third-party system, Arbor reads only what it needs to generate review evidence. Arbor never writes back to the connected systems.
GitHub
- Pull requests authored, reviewed, or merged by employees in scope.
- PR titles, descriptions, comments, review bodies, status labels.
- Optionally (controlled by your org's diff-mode setting) file-level metadata or full diffs.
- Commit metadata (author, timestamp, repo, branch).
Jira
- Issues where the employee is assignee or reporter.
- Issue summary, status, project, priority, type, comments, changelog, resolution date.
- The display names of assignees and reporters on those issues.
Arbor does not read calendar events, email, chat messages, code outside the configured repositories, or any data from systems you have not explicitly connected.
Arbor parses Atlassian accountIdvalues from API responses but does not persist them in its database. Stored review evidence references users by display name as resolved through your identity mapping, not by Atlassian account identifier. We expose Atlassian's required Personal Data Reporting API at /api/atlassian/personal-data-report; because we do not index by accountId, the endpoint returns not_found for every queried account.
3. Data you provide directly
- Account email and a salted, hashed password (never stored in plaintext).
- Employee roster you upload — name, role, optional level, and GitHub / Jira usernames used to resolve their identity in connected systems.
- Team structures and uploaded performance documents (level rubrics, role expectations) you choose to attach.
- Integration credentials — see the next section.
4. How credentials are stored
- GitHub App installation IDs and Atlassian OAuth refresh tokens are encrypted at rest with AES-256-GCM using a server-only key (
ARBOR_ENCRYPTION_KEY) before being written to the database. The key is never exposed to clients and is rotated when we rotate server secrets. - Atlassian OAuth access tokens are minted on demand from the stored refresh token and held only in process memory; they are never written to disk.
- Your account password is hashed with Argon2id; only the hash is stored.
- Session cookies are HTTP-only, Secure, and SameSite-protected.
5. Where data is stored
Arbor runs as a single application instance in Mumbai (Fly.io bom region) backed by a SQLite database on an attached persistent volume. Data does not leave that machine except for outbound calls to systems you have connected (GitHub, Atlassian) and the Large Language Model (LLM) provider configured for your tenant (see next section).
6. Use of LLM providers
Arbor sends activity excerpts and the rubric you provide to a Large Language Model so it can produce review-evidence narratives. You choose how this happens:
- Self-hosted (default).Arbor calls xAI's Grok API on your behalf using a key the operator controls.
- Bring your own key (BYOK).You supply an API key for OpenAI, Anthropic, xAI, or another supported provider, and your tenant's prompts are routed through your own account at that provider.
Whichever provider is configured will see the prompt content. Arbor does not use prompt content for training and instructs the provider not to retain it where the provider exposes such a flag, but the provider's own privacy terms also apply to that data.
7. Sharing and disclosure
Arbor does not sell data, share it with advertisers, or use it for any purpose unrelated to delivering review evidence to your organization. We share data only:
- With the LLM provider you have configured, as described above.
- With infrastructure providers strictly needed to operate the service (Fly.io for hosting).
- If required by law, after attempting to notify the affected customer where legally permitted.
8. Retention and deletion
- Activity data is retained while the corresponding integration is active, so reviewers can re-run or re-open historical reviews.
- You can delete a single review, an integration, or your tenant account at any time from the dashboard.
- Deleting an integration purges its credentials and disconnects Arbor from the source system.
- Deleting your tenant account purges the tenant and all its employees, integrations, jobs, and review outputs from the database within 7 days.
- Encrypted backups are retained for up to 30 days and then overwritten.
9. Your rights
You can request access to, correction of, export of, or deletion of your data at any time by emailing madhavsainanee123@gmail.com. Most of these are also self-serve from the dashboard.
10. Cookies
Arbor uses a single first-party session cookie (arbor_session) to keep you signed in. It is HTTP-only, Secure in production, and SameSite-protected. There are no third-party tracking cookies and no analytics scripts on the marketing pages or in the application.
11. Children's privacy
Arbor is a workplace tool not directed at anyone under 16. We do not knowingly collect personal information from minors.
12. Changes to this policy
Material changes will be announced in-product and via email to tenant administrators at least 14 days before they take effect, and the “Last updated” date at the top will change to reflect the new version.