Product Data Processing Policy

1. Design principle

We build on privacy by design: the product is architected to need as little of your data as possible.

2. Two separate questions

Where data processing has different answers and owners:

• Data Privacy — what data we read, copy, cache, or store, and why. Covered in this section (§3–§6).
• Security Permissions — what access rights we need to operate (e.g. repo write access), independent of what data that access touches. Covered in §7.

3. What we read, copy, cache, and store

To be useful, RidgeLine tracks logic, metrics, and key objects — specifically:

• Actors — the people and AI-Agents or AI-platforms (AI/API identities) generating activity
• Entities — the objects that make the insights and actionable directives possible (commits, PRs, token-usage events, and similar)

This is deliberately described at the principle level here. The exact field-level schema (precisely which properties of each actor and entity are captured) is provided on request under commercial terms and restrictions.

What we do not store, as a hard rule: file contents, code values, or anything reversible to source.

4. Data residency and international transfers

• Data is stored in London.
• Where any processing occurs outside the UK/EU, transfers are covered under Standard Contractual Clauses (SCC).

5. Retention

• Standard retention: 1 month after contract end, applied as the default across self-serve tiers.
• Enterprise agreements: 3 months for annualised data — where an account has more than 12 months of stored history, that longer-run data is retained for 3 months post-contract rather than 1, reflecting its value for trend and benchmarking purposes.
• Community metrics — we reserve the right to retain aggregated, obfuscated metrics contributed under the Community tier data covenant indefinitely. This data contains no PII and is handled under the same privacy-by-design principle as everything else in this document. This is consistent with, and does not expand, the existing Community tier covenant.

6. Real-time usage tracking and per-seat visibility

• Real-time usage tracking is on by default for all provisioned seat licenses — this is how the product delivers its core value (token attribution, budget control).
• Organisations with works council or equivalent employee-representation obligations can specify which seats are tracked.
• Responsibility for compliant use sits with the customer organisation. If an organisation uses RidgeLine data for individual performance evaluation, they must do so within the parameters of their own works agreements and local labour law. We provide the data; how an organisation governs its use internally is a decision the organisation makes and is accountable for.
• Per-person data exists for accountability. Access to any individual's data is gated to the seat holder themselves, plus whatever visibility the customer organisation has configured under the above.

7. Security Permissions — auto-instrumentation and repo write access

Auto-instrumentation requires write access to a connected repository, so RidgeLine can attribute token usage via PR. This is a Security Permission question, not a Data Privacy question: the access granted is constrained to the minimum required to support the specific service the customer has purchased, following the principle of least privilege. Broader access is never requested as a default, and any expansion of scope is opt-in and purpose-specific.

8. Account closure and deletion

On termination, data is deleted in line with the retention periods in §5.