SightLift

How capabilities work

SightLift turns the work your team already repeats with AI into proven, reusable capabilities — then serves them back into your tools and keeps checking they still work. Here's the whole loop, in plain terms.

← Data sources setup

You don't build or configure any of this. SightLift watches how work gets done, proposes capabilities, and asks you to approve the ones worth keeping. This page explains what you'll see in the Capabilities tab and the decisions it asks of you.

What a capability is

A capability is one repeatable piece of work, packaged so your team can reuse it instead of redoing it. SightLift only proposes one when it sees the same work happening several times, across more than one person — a real team pattern, not one person's habit. There are two kinds:

Kind	What it is	Runs on
Automation	Deterministic work — the same input reliably produces the same result (pull a list, reconcile a file, format an export). No judgment in between.	Plain code — no AI at run time. This is where the biggest cost savings come from.
Skill	Judgment work — drafting, summarizing, deciding. The steps are consistent but the thinking isn't mechanical.	A guided AI recipe. SightLift picks the right-sized model for each step (see below).

SightLift recommends which kind fits, but the recommendation isn't final — an automation has to prove it can reproduce your real results before it's trusted, and if it can't, it becomes a skill instead (more below).

The lifecycle — and the decision at each stage

Every capability moves left to right across the board, getting more trustworthy at each step. The columns are these stages (In review and Trial are shown together under Testing); hover any column header in the app for the same summary. A column only appears when something is sitting in it, so you won't see all of them at once.

Stage	What's happening	Your decision
Detected	SightLift spotted repeated work and proposed a capability. Nothing's committed.	Promote it, or leave it.
Testing	Being validated, not yet trusted — either checked against your team's real past results (to decide automation vs. skill), or, when there's nothing to test backward against, serving in a safe dry-run while it collects results people confirm.	Mostly none — SightLift flags you when it's ready; for a dry-run trial, review the results it collects until enough are confirmed.
Verified	It passed — proven (automation) or quality-checked (skill) — and is signed off.	Approve it to serve, or hold.
Live	Served into your tools and being measured — usage, success, savings.	Keep it, improve it, or retire it.
Needs attention	A live capability has drifted from fresh results — the work has changed underneath it.	Re-verify on new evidence, or retire.
Retired	Unpublished and no longer served — retiring it removes the tool from your team's assistants. Nothing is deleted: it stays on the board with its proof intact.	Leave it as a record, or promote a replacement.

What happens when you promote

Promoting isn't instant, and the tab won't pretend it is. When you press Promote:

SightLift gathers your team's real past examples of this work.
It runs the candidate against each one, twice, in a locked-down sandbox (no data leaves; nothing runs against anything live).
It checks whether every result matches what your team actually accepted.

You don't wait on a spinner — it runs in the background and the card shows plain progress. Then one of two things happens:

Every example matched → it's a proven automation. The proof opens for your sign-off, and once approved it goes Live and runs as plain code with no AI at run time.

Some steps needed judgment (a couple of examples didn't reproduce exactly) → SightLift offers it as a guided skill instead, showing you what differed. Nothing is wasted: the same evidence becomes a skill candidate, and you decide whether to serve it. We call this failing forward — a "no" to automation is really a "this needs judgment."

How you know it's proven

The proof is the point — it's what lets you trust a capability without reading its internals. SightLift is honest about how strongly something is proven, in plain words:

You'll see	Means
Verified on real work	Reproduced your team's real past results exactly. The strongest proof — automations only.
Confirmed in live use	Earned its proof from live results people confirmed (used when there was nothing to test backward). Honest notch below the above.
Quality-checked	A graded estimate for skills. An AI following judgment can't be certified by reproduction, so skills are graded, never called "proven" — and labeled that way wherever they're served.

Every proof also stores a de-identified record of the examples it passed, so it stays valid even if the original conversations are later deleted. The person who approved it and the date are always attached.

The right model for the right step (skills)

A skill isn't a single prompt — SightLift breaks it into steps and sets a model tier for each: a small, fast model for the mechanical steps, the strong model only for the real judgment. You never pick a model; SightLift tunes it, and only keeps a cheaper model for a step if the quality check still passes.

SightLift sets the tiers; your tools run them, on your account. We don't run the model for you — the plan is built into the skill and your assistant executes it, so the savings land on your own usage. (Automations, remember, use no model at run time at all.)

Once it's live

A served capability isn't "done" — it's watched. The Live view leads with how it's actually being used, not the original proof:

In the wild — how often it's used, how often people keep the result, and the realized savings against the original estimate. Where savings read as dollars, that's the estimated time saved priced at your loaded hourly rate — one number an admin sets in Settings (a default applies until then); hover any figure to see the hours and rate behind it.
Every use, and why — success, failure, and neutral (ran fine, but no one confirmed they used it). Neutral is shown, never counted as success, so the numbers stay honest.
Improvement history — a dated log where each change names the evidence behind it ("renamed after it was offered 11× and used once"; "re-proven after fresh exports used a different date format"). This is the trust story over time.

If a capability starts failing or drifts from fresh results, SightLift flags it to re-verify — or you can unpublish it in one click. Turning it off is instant; bringing it back requires proving it again.

When one came out wrong: starting over

Unpublishing and retiring both keep the capability — its proof, its history, its record. Sometimes that isn't what you want: the recipe reads wrong, or what looked like one job turns out to be two, or it was built before we improved how they're written. Re-promoting won't help, because promoting the same work again updates the capability you already have rather than building a new one.

For that there's Start over, at the bottom of any capability's panel and available to admins:

What goes: the capability itself, its version history, its record of who did what, and its verification result. None of it comes back, and if it's live your team's tools lose it immediately.
What stays: the work behind it. SightLift keeps detecting the same repeated work, and the documents already written for it are kept — so the capability returns to Detected and you promote a fresh one, built the way we build them today.
Not for a capability someone added by hand. Nothing re-detects a capability a person wrote, so starting over on one means writing it again. The confirmation says so.

It's deliberately the quietest control on the panel and asks you to confirm, naming what you lose. Reach for unpublish first — that's the reversible one.

How you're told when something needs you

You're never left refreshing. The board is the source of truth — a card that needs you flips to a Ready state and the Capabilities tab shows a count. If you're in the app you'll get a toast; if you've stepped away, it reaches you in your weekly digest or a short email. Notices go to the person who promoted the capability, not the whole team, and only for things that actually need a decision.

Privacy & what SightLift can see

Capabilities are only as complete as what you connect — SightLift shows a quiet note on the tab if it's only reading some of your team's tools, so the numbers are never mistaken for the whole picture. Everything beyond basic measurement is off by default and you control it.

Team-level, not surveillance. The board and adoption numbers are about the work, not individuals; person-level detail stays behind an access wall.
Your data stays yours. Content is scoped to your organization, never shared across tenants, and never used to train models.
Erasure-safe. Delete a conversation and its retained content goes too; only the de-identified proof remains, so nothing personal outlives your erasure.

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

Common questions

Do I have to build or maintain these? No. SightLift proposes them from work your team already does; you approve the ones worth keeping and it maintains the proof over time.

What if the AI gets something wrong? Automations only go live after reproducing your real results exactly, and anything live is watched — failures are surfaced, and one click unpublishes it. Skills are labeled as graded estimates, never presented as certain.

Does this replace my team? It removes the repeated parts so your team spends time on the work that actually needs them. A capability captures a pattern; it doesn't own the outcome.

Where do I start? Connect a source (setup guide) and add the SightLift tool in your assistant. Detected capabilities show up on their own — you just decide which to promote.

Questions about a specific capability or your rollout? Contact your SightLift account team.