Docs/Getting started/Introduction
Introduction
Bill-y is phase attribution for AI coding spend. It splits an engineering team's AI token spend across the phases of building software (understand, design, build, test, review) so leaders can see whether AI is used well, not just heavily.
A token count tells you how much you spent. It never tells you whether that spend produced understanding, design, working code, tests, or review. Bill-y attributes every unit of spend to a phase of work, on the developer's own machine, and ships only derived metrics to a server you run on your own infrastructure.
Who Bill-y is for
- Engineering leaders who want to know where AI spend goes and whether the distribution of that spend looks like healthy engineering work.
- Platform and IT teams in organizations that cannot send telemetry to a third party: Bill-y for Enterprise is on-premises by design.
- Security and privacy reviewers who need structural guarantees, not policy promises. Bill-y's core privacy property is enforced by architecture and database grants, not by configuration.
- Finance partners who need spend, budgets and forecasts stated honestly, with method and confidence attached.
What makes Bill-y different
| Property | What it means in practice |
|---|---|
| Phase attribution | Spend is classified into workflow phases, not just totaled. |
| On-device classification | Raw session text is analyzed on the developer's machine and never leaves it at the default policy. |
| On-premises server | One Linux VM you run. No SaaS backend, no third-party data processor. |
| Team-level analytics | The analytics plane structurally cannot query individual developers. |
| Facts, never verdicts | Bill-y reports what happened. It does not score developers. |
How these docs are organized
- Getting started explains the product and the path from a coding session to a governed answer.
- Concepts defines the phase model and every metric term precisely. If you read only one group, read this one.
- Architecture and trust shows how Bill-y deploys, what travels, and the guarantees your reviewers will ask about, plus how to request the full security pack.
- Reference holds the FAQ and the glossary.
Where the deep documentation lives
These public docs cover the concepts and the guarantees. The full operational documentation (installation, configuration, fleet rollout, security mechanics, administration) ships with the product and is available to evaluating teams as part of the security pack.