← All news
Policy

Trust, data protection, and compliance

UK GDPR, our data-processing commitments, and the company behind Lineman.

The Lineman team

When you let a tool process your code, you're really trusting the company behind it. So it's worth being plain about who Lineman is, the law we operate under, and the commitments we make about your data. This post pulls those together in one place.

The detail lives in two documents that govern everything we do: our Privacy Policy and our Terms and Conditions.

The company behind Lineman

Lineman is the trading name of Goo Holdings Ltd, a company registered in England and Wales. "Lineman" is the name you'll see across the product and this site. "Goo Holdings Ltd" is the legal entity named in our Privacy Policy and Terms. Being a UK-registered company means we operate under UK law, including UK data-protection law.

Built around UK GDPR

We follow UK GDPR principles. In practice that means:

  • A lawful basis for everything. We process personal data only where we have a lawful basis under UK GDPR, such as performing our contract with you, or a legitimate interest in operating the service safely.
  • Your rights are honoured. UK GDPR gives you rights over your personal data, including access, correction, and erasure. How to exercise them is set out in the Privacy Policy.
  • The ICO is our supervisory authority. As a UK company we answer to the Information Commissioner's Office.

Our data-processing commitments

The commitments that matter most for code-handling teams:

  • Transient processing. Your code is processed in real time and discarded after the response is delivered. We keep no persistent store of your files.
  • No training on your code. Your content is never used to train, fine-tune, or improve models. This applies to every tier.
  • Separation. Anonymised operational usage data is kept separate from any code you process and never contains it.
  • Processor for business customers. Where we process code on a business customer's behalf, Lineman acts as a data processor, and a Data Processing Agreement is available as part of the Terms.

Where to read more

This post is a summary, not the contract. The binding detail (categories of data, retention, international transfers, your full rights, and the obligations on both sides) lives in:

We'd rather you read those than take a marketing page's word for it. If anything is unclear, or you want to discuss a Data Processing Agreement, reach us via contact.

Related

Policy

Your code is yours

Lineman processes tool output to compress it, then moves on. We don't train on your code. A plain-English account of how your data is handled.

Policy

Security at Lineman

Security isn't a page you visit once. Our posture, from how we guard your account to how your code is handled in transit.

Product

How to Build an LLM Spend Audit by Department in 7 Steps (2026)

Quick Guide: How to Build an LLM Spend Audit by Department in 7 Steps Define your cost attribution dimensions — Decide whether you'll track by department, team, repository, or individual developer. Set up token telemetry collection — Install an SDK wrapper or proxy that captures every LLM API call with metadata. Configure department tagging — Map each request to a department using git context, API keys, or manual labels. Aggregate costs by time window — Build hourly, daily, and monthly rollups so you can spot trends and spikes. Add prompt compression middleware — Use Lineman to cut token costs by 40%+ while maintaining output quality. Create budget thresholds and alerts — Set per-department limits that notify you before overspending. Export to your FinOps dashboard — Push data to CloudWatch, Prometheus, or your existing observability stack. How to Build a Department-Level LLM Spend Audit 1. Define Your Cost Attribution Dimensions Start by mapping how your organization actually uses LLM APIs. Most engineering teams find that repository-level attribution gives the clearest picture of spend.