Lifesight calibration

Lifesight Calibration — Learn the Workspace Once

The Lifesight skills are universal — the same files ship to every customer. Nothing about a specific account is baked into them. This skill is how a universal skill set adapts to one account: it inspects the live workspace once and writes a small lifesight-workspace-profile that the router, core, rendering, and every persona spoke then read. Skills stay universal; the profile is the only per-customer artifact.

Follow lifesight-core operating rules throughout (one heavy call per turn, clean errors, no leaks).

When to run

• No lifesight-workspace-profile exists yet for the active workspace.
• The user explicitly asks to set up / calibrate / recalibrate.
• The active workspace just changed (the profile is per-workspace).
• Channels or models in a response don't match the profile (drift — refresh it).

If a current profile already exists and matches the active workspace, don't re-run — just use it.

What to inspect (cheap calls only)

All of these are light tools — no flood risk. Run them in this order:

1. Confirm the workspace. list_workspaces → note the active workspace name/id.
2. Discover models. list_models → capture every model (name, KPI) and which is the default/recommended. If zero models, stop and tell the user to set a default scenario in the platform UI — calibration can't complete without one.
3. Learn the channels + spend scale in one call. get_current_budget(default model) returns the per-channel current spend. This gives you (a) the real raw channel columns for this account and (b) the rough total spend scale. This is the cheapest way to learn the channel set — do NOT run a heavy optimization just to discover channels.

That's it for inspection. Don't pull historical row data or run optimizations during calibration — you only need the structure, not the analysis.

Build the channel map

For every raw channel column returned, derive a clean display name using the universal rule in lifesight-rendering (drop the metric affix, Title-Case, expand known abbreviations, preserve funnel qualifiers). Record both the raw token and the display name so other skills never have to guess.

Write the profile

Write lifesight-workspace-profile.md (in the user's project for Claude Code; see Persistence below for other surfaces). Use this format:

# Lifesight Workspace Profile
workspace: <name> (<id>)
calibrated: <date>
default_model: <model name> — <KPI>
models:
  - <model name> — <KPI> [default]
  - <model name> — <KPI>

## Channel map (raw → display)
<raw_column> = <Display Name>
<raw_column> = <Display Name>
...

## Scale
approx_total_spend: <rough magnitude, e.g. ~$2.1M / quarter>   # for formatting + sanity checks
currency: <USD/…>

## Guardrails  (customer-defined — confirm with the user; leave blank if unset)
iroas_floor: <e.g. 1.0>            # don't recommend scaling channels below this
max_channel_change: <e.g. ±50%>    # cap per-channel reallocation
locked_channels: <none / list>     # never recommend changing these
default_objective: <e.g. fixed-budget reallocation, not uncapped max-revenue>

## Persona default
primary_user: <CMO / Growth / CFO / Analyst — optional, shapes default framing>

Keep it short — it's a config, not a report. Confirm the guardrails with the user rather than inventing them; an empty guardrails block is fine and means "ask before applying constraints."

Persistence by surface

• Claude Code / filesystem present → write the file as above; it persists.
• Claude.ai desktop (MCP only, no filesystem) → you can't write a file. Instead, present the profile to the user and offer to save it to their project memory / custom instructions, or simply re-derive it at the start of each session (the inspection above is cheap). Never block on persistence — runtime re-derivation is always an acceptable fallback.

Hand back

Once written, summarize in one or two lines and route on:

"Calibrated to <workspace>: <N> channels, default model <model> (<KPI>), ~<scale> total spend. Guardrails are unset — want to set an iROAS floor or per-channel caps before we optimize?"

Then continue to whatever the user actually came to do (via the router).

What calibration never does

• It never runs a heavy optimization just to learn the workspace — get_current_budget is enough.
• It never invents guardrails or numbers — it reads real data and asks for the rest.
• It never writes account-specific values into the universal skill files — only into the profile artifact.