SightLift

How your Toolbox works

The Toolbox tab is every AI skill your team actually uses, in one place — the capabilities you've published in SightLift, and the skills in use outside it. It's the readout: what your team runs, who it reaches, and what that work is worth. This page explains what each number means and where it comes from.

← How capabilities work

The Toolbox is a readout, not a workbench. Nothing here changes your setup — you read it, then act from the Capabilities tab (publish, verify, retire) or your Action plan (the plays SightLift builds from what it found).

The two rooms

The tab has two sub-tabs, for two different readings:

Overview — the readout. What your team runs, what it's worth, what to add next. No toggles, no setup.
Departments — the analytics workspace. Team scores, who uses what by department, and groups of skills doing the same work.

Three kinds of thing, deliberately kept apart

Overview shows three lists, and the split matters: the difference between them is whether you can do anything about them, and how well we can measure them.

What you'll see	What it is	What you can do
SightLift capabilities	Skills your team promoted and published here, so they run as managed tools. SightLift serves them, so everything about them is measured — exact use counts, real people counts, realized labor dollars.	Manage them on the Capabilities tab; open a row for its detail and example uses.
Skills outside SightLift	Connectors and skills your team brought themselves that were never published here. We only observe these, so counts carry a `~` and dollars carry a `≈` with a basis you can hover.	These are the publishable ones — the list is ranked as a recommendation of what to add next.
Built-in tools in use	The tooling that ships with your team's AI assistant — file editing, search, the browser, and so on. Your team didn't build these and can't publish them.	Nothing — and that's why the list is collapsed and carries no action.

Why built-ins are shown at all. They're a large share of what your team runs, so leaving them out would make the totals look wrong. But they are in use, not a problem to fix: as the tab puts it, they "come with your team's AI tools rather than being something your team built, so there is nothing to publish. Shown for visibility." No dollar estimate is shown against them either — a saving implies a decision worth making, and there isn't one here.

Published capabilities — the measured list

The published table is the part of your toolbox SightLift runs, so it's the part we can count exactly. Four columns:

Capability — with the lane it sits on from your capability board, or In rollout when it's published but has no measured uses yet.
Usage — a small trend line: uses per week over the recent weeks we read.
People — distinct people using it.
Labor saved/mo — the realized labor value, or the word measuring when there isn't a figure yet. We'd rather say "measuring" than show you a number we can't stand behind.

Above the table sits a compact view of your capability board — the same six lanes, same names, same order as the Capabilities tab, with a one-line note under each (what your team added in the last 30 days, what ships next, improvements shipped, what's been consolidated into a standard, and any sensitive-work reviews underway).

Opening a capability

Clicking a row opens its detail, which adds the things a summary can't carry:

Served suggestions taken up — of the suggestions that have had time to be acted on, the share your team actually took up, with the basis stated. Serves too recent to have had their chance aren't counted against it.
When it didn't land — kept as two separate counts on purpose, never averaged into one "reject rate". A dry-run error is the serve failing before anyone used it; a reported failure is someone using it and telling us it went wrong. The second is engagement, not avoidance.
Went another way — how often the team did, by hand, work a published capability already does. The most direct read on whether a published skill is being picked up.
Used by — departments, with counts. Never a list of names (see Privacy).
See example uses — single real examples, so you can check the work rather than take the number on faith.

Skills outside SightLift — what to publish next

This list is a recommendation, and it reads like one: "We detected N skills outside SightLift getting ~X uses/month across at least Y people. We recommend adding these to SightLift so the people already relying on them get verification, usage tracking and your policy checks — starting with…"

Grouped by connector, not by tool

Each row is a connector or server — the product your team connected — not each individual tool function inside it. A browser connector with eleven tools is one row, because those eleven are used together to do one job; listing them separately would suggest eleven decisions where there is one. "Who uses this skill" is answered at that same grain, as departments.

Why these numbers are approximate

We see this work happening but we don't run it, so the tab marks the difference rather than hiding it: counts read as ~, dollars read as ≈, and every estimate names its basis on hover. Where a skill has too little use to estimate honestly, the row says "too little use to estimate" instead of showing a figure. A skill earns exact numbers by being published.

Why publishing pays — and why the score follows

Publishing a skill your team already uses changes what happens around it. In the order that matters:

It gets verified. The work is proven against your team's real results before it's trusted, instead of being taken on trust.
It gets tracked. Use, adoption, failures and value become measured numbers instead of observed estimates.
Your policy checks apply wherever it runs. Until then it's observed only — brought by the team, outside those checks.
More people get it. A published standard is served to everyone doing that work, not just the person who set it up.
The labor value becomes real and measured — hours saved you can point at, priced at your own rate.

The score is the receipt, not the reason. Your AI-Use Score has a Reuse dimension that counts how much work runs on shared, verified tools. Publishing raises it because that's literally what Reuse measures — the points follow the benefit, they don't cause it. If a publish wouldn't help your team, the points aren't a reason to do it.

Consolidating duplicative tools

On the Departments view, Sprawl targets shows groups of skills doing the same work — usually the same product connected twice, or two teams that solved one problem separately. Consolidating them onto one published standard brings that work under verification and your checks. Each target names the connectors involved, how many people are outside the standard, and whether a published capability already covers it (covered) or not (no standard yet). Where one is already covered, the card links straight to that capability on your board.

Read the dollar carefully: it's value at stake, not a saving. The figure on a sprawl target is the labor value running through that work today. Consolidating three tools onto one standard standardizes that work — it does not recover it as cash. We label it "value at stake" for exactly that reason, and it should never be read as money you're about to get back.

Where SightLift has already turned a target into a play, the card links to it on your Action plan.

Departments

The Departments view answers "how is this landing across the org?" It has three parts:

Team scores — one AI-Use Score per team over the last three quarters, with the movement since last quarter. It's the same per-department number the score ribbon shows, never re-derived here. A team's card opens its workspace.
People by department — a grid of who uses each skill, as department head-counts.
A team's toolbox — per-department workspaces: what share of the team is on a published capability, what's published there, what outside skills they lean on, and what publishing the next one would get them.

Adoption is the only department-level measure

This is the one thing worth knowing before reading the grid. People counts exist per department; uses and dollars do not. We can tell which people are in which team, so a head-count per department is a real measurement. We can't attribute an individual use or an individual dollar to a department, so those figures stay company-wide — and every column that shows one says so, with a · tenant label and a tooltip repeating it. We'd rather label the grain than show you a company number dressed up as a team number.

When departments don't appear

Two different things can hold the Departments view back, and the tab tells you which one — because the fix is different:

"Add your org chart to see this by team" — or, if you've started, "N of M active people have no Department set."

We don't know enough people's departments to group by team at all — the same coverage rule the AI-Use Score uses to decide whether to group by team. What to do: set people's departments under Settings → Org & roles, and this fills in automatically.

"Your org chart covers the team, but no department has 3 or more people using AI yet."

This one is not a setup problem — your org chart is fine. Your teams are simply smaller than the reporting floor, and a breakdown below it would identify individuals rather than describe a team. What to do: nothing. Department workspaces open up automatically as teams grow past that, and everything measured is already on Overview, which reports at team level.

The same floor applies inside the view: a department is named on a skill only once at least three people there use it. Everyone below that rolls into a single unnamed "under privacy minimum" count, so the totals stay right without naming a small group.

Sensitive work and your policy checks

Publishing is also how work comes under governance. A published capability runs with your policy checks applied wherever it goes; a skill outside SightLift is observed only.

Separately, SightLift categorizes sensitive work into five kinds — Legal · Finance · Personnel · Security · Strategy — and checks whether the people handling that work are cleared for it. Clearances are set per person under Settings → Org & roles, and a person can hold several. There's also an explicit Not Sensitive answer, which is deliberately different from leaving the question blank: "Not Sensitive" is an answer (this person handles no sensitive work), while blank means we don't know yet and won't guess either way.

Any reviews in flight show on the capability board's attention lane as sensitive-work reviews underway. For how clearances feed the Governance dimension of your score, see How your AI-Use Score works.

Where the dollars come from

Every dollar on this tab is labor — time your team gets back, priced. The arithmetic is the same everywhere in SightLift, and it's deliberately boring:

time saved per use × uses = hours, then hours × your loaded hourly rate = dollars.

The rate is one number an admin sets under Settings → Monthly AI budget — a blended, fully-loaded figure (salary plus overhead). It's the single assumption behind every labor dollar here, which is why every figure that depends on it shows the hours behind it when you hover: "≈ N hrs/mo × $R/hr — your loaded hourly rate, set in Settings."

Two honesty rules we hold to. First, measured beats estimated, and the tab says which: published dollars are realized labor from counted uses; outside dollars carry ≈ and an estimate basis. Second, this is money your team could redirect — not money that appears in a bank account.

Why people and uses cover different spans

Deliberate, and worth knowing when two numbers on the page seem not to line up. Uses and dollars are the last 30 days, so a monthly figure is the window itself rather than something scaled up from a shorter one. People is a longer window, because a head-count needs enough span for a department to clear the privacy minimum and for a trend to have a shape at all. Every figure states its own span where it appears — hover a column heading, or open a row and read the labels under each number.

Privacy

The Toolbox answers questions about work, not about people. That's a structural choice, not a setting:

"Who uses this skill" is answered as departments — always. There is no person roster on this tab, and no view that produces one.
Counts are floored at three. A department is named only when at least three people are behind the number; smaller groups collapse into one unnamed count. The floor is the same everywhere on the tab — grid cells, chips, list meta.
No individual scores. Team scores exist at team and company level only.
Receipts are examples, not rankings. "See example uses" opens single real conversations so you can check the work. It is never a leaderboard of who used what most.

For exactly what each telemetry level exposes and how to enable it safely, see Data access & privacy.

Common questions

Why is a skill I know we use missing? Most likely it hasn't reached the reporting floor yet, or its telemetry isn't connected. The tab shows a quiet note when it's only reading some of your team's tools, so the numbers are never mistaken for the whole picture.

Do I publish from this tab? No — the Toolbox is the readout. Publishing, verifying and retiring happen on the Capabilities tab, and the plays SightLift builds from what it finds here land on your Action plan.

Is a long outside-skills list bad? No. It's a list of things your team found useful enough to go get — that's initiative, and it's the raw material for what to standardize next. The list is ranked so the top of it is where publishing pays most.

Why doesn't the labor saved match my finance numbers? Because it isn't a cash figure. It's hours × a rate you set, which measures capacity you can redirect. Change the rate in Settings and every figure here re-prices with it.

Questions about a number on your own Toolbox? Contact your SightLift account team.