Product · Team Dashboard
The team's evidence, visible to the people it is about
Organization inventory, named and permissioned comparisons, baseline and drift workflow, and an audit trail — built so that anything an administrator can see about a developer, that developer can see about themselves.
How it works
Three ledgers, joined once
Each ledger on its own is a curiosity. The team value is in the join — and the join is only honest because every link carries how it was made.
- 01
Setup ledger
Which MCP servers, skills, and plugins exist, at which scope, at which version, from which provenance — across every connected device.
- 02
Usage ledger
Sessions, models, token classes, context load, and which tools were actually observed running, with coverage stated per device.
- 03
Delivery ledger
Repositories, branches, commits, and merged pull requests, with an attribution method and confidence on every link back to a session.
Capabilities
What the dashboard is for
The paywall sits here for a reason: cross-developer coordination is the thing one machine genuinely cannot do, not a feature withheld to force an upgrade.
Organization inventory
Every device, developer, and repository in one place — with counts that reflect coverage rather than assuming it.
Named comparisons, permissioned
Developer, repository, and tool comparisons for the people entitled to see them, restricted to high-confidence attribution by default.
Baseline workflow
Proposal, approval, drift, exceptions, and adoption records — including which baseline version each machine actually pulled.
Coverage and data health
Where our evidence is thin, stated as its own screen rather than hidden behind an average.
Audit trail
Every approval, exception, remediation, and adoption, with who did it and when. Fleet-wide, not buried inside individual findings.
Before and after
What a setup change did, compared against the same developer before it — the strongest evidence this product can honestly offer.
What we never see
A dashboard is not a reason to collect more
The data contract does not loosen because the data arrived in the cloud. The boundary is enforced at the reader on the device, before anything is sent.
Stored
Tenant-scoped or pseudonymous actor and device identifiers, versions, session IDs, timestamps, counters, token classes with explicitly labelled estimated cost, canonical repository and pull request metadata, safe asset identity and fingerprints, and finding records.
Never stored
Prompts and responses. Source code and diffs. Shell command text. Tool payloads. Secrets and environment values. CLAUDE.md contents. None of it is uploaded, so none of it can be stored.
Not a surveillance tool
The rules that make named views acceptable
This is the surface where a product like this goes wrong. These constraints are what keep a named view a support tool rather than a monitoring one.
Symmetric visibility
Anything an administrator can see about a developer, that developer can see about themselves. There is no manager-only view of a person.
No score, no rank
No hidden scoring, no leaderboard, no collapsing quality, speed, and cost into one number about someone. The vocabulary rules out the language too — no “low performer”, no “wasted tokens”.
No causal claims
Setups and delivery may differ visibly. The product will not say one caused the other, and will not name a best developer or a best setup.
Where it stops
No payloads are read. A tool the collectors cannot defensibly match is counted as unattributable rather than guessed into a category.
Related
Each surface feeds the next: what the scan finds becomes a finding, and a finding becomes a reversible change.
FAQs about Team Dashboard
Can an administrator see things about me that I cannot?
No. Developers can see everything about themselves that an administrator can see. That symmetry is a design rule, not a setting.
Is there a leaderboard or a developer score?
No. There is no hidden score, rank, or leaderboard — not disabled by default, not built. Named views exist to explain setup variance, support exceptions, manage seats, and handle incidents.
What does the control plane store?
Organizations, memberships and roles, device and installation identity, inventory snapshots and approved baselines, session and delivery attribution, findings, exceptions, approvals, remediation and verification records, and billing entitlements. Sanitized metadata — never prompts, code, or tool payloads.
How is tenant isolation handled?
Tenant resolution fails closed. There is no fallback tenant — a record that cannot be resolved to an organization is rejected rather than filed somewhere convenient. Cross-tenant negative tests are release blockers.
How would this be billed?
By paired devices beyond the free 10-device fleet, not by people. Admin and read-only viewer seats are free at every tier.
Can I export or delete our data?
Yes. Customers get data inventory, retention, export, and deletion controls, and every field has a documented source, retention, and deletion behavior.
See what your fleet is actually running
The scan runs locally and reports in your terminal. No account, no upload.
keeprails scan