threadlight-consumption-iq

Files (118)

• SKILL.md
• consumption-formulas.md · references/
• cost-actuals-manifest-schema.md · references/
• cost-estimate-manifest-schema.md · references/
• cost-manifest-schema.md · references/
• cost-manifest.schema.json · references/
• cost-reconciliation-manifest-schema.md · references/
• cost-query-aoai-account.json · references/fixtures/sample-cost-actuals/
• cost-query-costusd-alias.json · references/fixtures/sample-cost-actuals/
• cost-query-multi-service.json · references/fixtures/sample-cost-actuals/
• cost-query-page-1.json · references/fixtures/sample-cost-actuals/
• cost-query-page-2.json · references/fixtures/sample-cost-actuals/
• live-shape.json · references/fixtures/sample-cost-actuals/
• cost-manifest.json · references/fixtures/sample-pilot-consumption/expected/
• cost-projection.md · references/fixtures/sample-pilot-consumption/expected/
• SPEC.md · references/fixtures/sample-pilot-consumption/specs/
• manifest.json · references/fixtures/sample-pilot-consumption/specs/
• cost-estimate-manifest.json · references/fixtures/sample-presales-rollout/expected/
• cost-estimate.md · references/fixtures/sample-presales-rollout/expected/
• estimate-onepager.html · references/fixtures/sample-presales-rollout/expected/
• rollout.json · references/fixtures/sample-presales-rollout/
• cost-estimate-manifest.json · references/fixtures/sample-presales-topology-rollout/expected/
• cost-estimate.md · references/fixtures/sample-presales-topology-rollout/expected/
• estimate-onepager.html · references/fixtures/sample-presales-topology-rollout/expected/
• rollout.json · references/fixtures/sample-presales-topology-rollout/
• hardening-delta-catalog.json · references/
• live-actuals-probe.md · references/
• load-profile-schema.md · references/
• model-catalog.json · references/
• onepager-template.html · references/
• meters.json · references/pricing-fixtures/
• microsoft-apimanagement-service.json · references/pricing-fixtures/
• microsoft-app-containerapps.json · references/pricing-fixtures/
• microsoft-cognitiveservices-accounts-deployments.json · references/pricing-fixtures/
• microsoft-documentdb-databaseaccounts.json · references/pricing-fixtures/
• microsoft-machinelearningservices-workspaces.json · references/pricing-fixtures/
• microsoft-search-searchservices.json · references/pricing-fixtures/
• microsoft-storage-storageaccounts.json · references/pricing-fixtures/
• rollout-profile-schema.md · references/
• actuals_sources.py · scripts/
• consumption_iq.py · scripts/
• cost_actuals.py · scripts/
• cost_api.py · scripts/
• discount.py · scripts/
• discover.py · scripts/
• emitter.py · scripts/
• estimate.py · scripts/
• hardening.py · scripts/
• load_profile_wizard.py · scripts/
• meter_demand.py · scripts/
• model_catalog.py · scripts/
• onepager.py · scripts/
• pricing_client.py · scripts/
• __init__.py · scripts/projectors/
• _fallback.py · scripts/projectors/
• _meter_base.py · scripts/projectors/
• aca.py · scripts/projectors/
• ai_search.py · scripts/projectors/
• aoai.py · scripts/projectors/
• apim.py · scripts/projectors/
• …and 58 more

SKILL.md (first lines)

# Threadlight Consumption IQ — post-deploy cost projection + SKU diff

> The single skill in the chain that asks "**what should this pilot actually
> cost to run at the customer's real production load, and which SKUs should
> we swap to before they sign off?**" and answers with a structured,
> evidence-backed artefact instead of a guess.
>
> Naming: the `-iq` suffix matches the target Field Outcomes
> view's `ai-foundry-account-iq` / `azure-account-iq` family under
> **Build & Deliver → Drive Consumption**.

## Current evidence contract

This skill owns the cost evidence lifecycle for a pilot:

1. **Forecast** — `docs/cost-projection.md` + `specs/cost-manifest.json`
   project declared load against public pricing.
2. **Read-only actuals collection** — `specs/cost-actuals-manifest.json`
   (`threadlight-cost-actuals/v1`) captures Cost Management / Monitor / Log
   Analytics evidence for a settled window.
3. **Scope-bound reconciliation manifest** —
   `specs/cost-reconciliation-manifest.json`
   (`threadlight-cost-reconciliation/v1`) proves the actuals still match the
   exact forecast, SPEC § 14 policy, and collection scope/window they were
   reconciled against.
4. **Human reconciliation report** — `docs/cost-reconciliation.md` explains the
   variance, coverage, maturity, and unit-economics result.

Production-ready consumes verified artifacts and does not query or recompute.
`threadlight-production-ready`'s cost/readiness findings are downstream
consumers of what this skill publishes:

- `COST-102` = **mature/fresh/scope-bound reconciliation**.
- `COST-103` = **PAYG/PTU recommendation at observed token volume**.
- `KPI-003` = **measured cost per successful interaction joined with eval and
  telemetry evidence**.

## Why this skill exists

The `threadlight-*` chain ships a working agent in one session (design →
local-test → deploy → safe-check). `threadlight-production-ready`'s
pillar 10 (cost) then asks *static* questions: is a Budget declared? is
an anomaly alert wired? is `docs/cost-projection.md` present? Those are
yes/no checks. They do not answer **what the pilot will actually cost**
when the customer turns on production traffic.

Meanwhile `paygo-ptu-cost-analyzer` (in `awesome-gbb`) only covers AOAI
PAYG-vs-PTU break-even. Every other deployed resource — ACA, Cosmos,
Storage, APIM, AI Search, Foundry hosted-agent — gets eyeballed.

Without this skill the cost conversation at architecture review goes:

> **Customer FinOps:** "What's this going to cost per month at our actual
> load?"
> **SE:** "Uh, roughly… a few thousand?"

That's how pilots become lab graveyards.

This skill produces the answer in one command.

## What this skill does NOT replace

| Concern | Use instead |
|---|---|
| AOAI-only PAYG-vs-PTU break-even on a notebook (no deployed pilot) | `paygo-ptu-cost-analyzer` (awesome-gbb) |
| Static cost-pillar checks (Budget declared? anomaly alert? projection present?) | `threadlight-production-ready` pillar 10 |
| Live budget presence / anomaly posture on the target subscription or RG | `threadlight-production-ready` `COST-101` + cost-pillar budget/anomaly checks |
| Assessing the verified reconciliation bundle in a readiness report | `threadlight-production-ready` `COST-102`, `COST-103`, `KPI-003` *(artifact consumers only; no query/recompute)* |
| Bicep mutation from recommendations | `threadlight-deploy` on the next run (this skill is advisory) |
| Real-time anomaly detection | Azure-native budget/anomaly automation; this skill stays evidence-only |
| Demand forecasting / usage time-series | out of scope; threadlight-deploy/references/observability owns the trace side |

## When to invoke

| You start with… | Phase | What's produced |
|---|---|---|
| Green `threadlight-safe-check --phase post-deploy` and an upcoming customer architecture review | `run --all` | `docs/cost-projection.md` + `specs/cost-manifest.json` (+ back-filled SPEC § 12 `load_profile{}` if wizard ran) |
| Pre-deploy spec review and you want to sanity-check the SKU choices in `infra/main.bicep` before you push | `run --all --pre-deploy` | same artefacts, marked `pre_deploy: true` in manifest (no `azd env` walk; Bicep-only) |
| Re-run with `load_profile{}` already populated and recent deploy | `run --all` (wizard auto-skips) | refreshed artefacts |
| You want to check just one resource (e.g. "did we pick the right APIM tier?") | `project --only Microsoft.ApiManagement/service` | partial artefacts, scoped manifest |

> **Rule of thumb.** Run this **after** `safe-check` and **before**
> `production-ready`. `threadlight-auto` will wire it in automatically.

## The chain (where this fits)

```
threadlight-design → threadlight-demo-data-factory → threadlight-local-test →
threadlight-deploy → threadlight-safe-check →
threadlight-consumption-iq      ← THIS SKILL
microsoft-foundry + threadlight-deploy/references/observability →
threadlight-production-ready
```

## Inputs (contracts)

| Input | Source | Required |
|---|---|---|
| `specs/manifest.json → deployment_manifest{}` | `threadlight-design` | yes — **or** derived from the export's `infra/` + `azure.yaml` in Kratos-export mode |
| `infra/main.bicep` + modules | repo | yes |
| `azd env get-values` | live azd env | yes (skip with `--pre-deploy` to read Bicep only) |
| `specs/SPEC.md § 11c` (tech-stack selectors) | `threadlight-design` | yes — not present in a Kratos export; resources come from `infra/` instead |
| `specs/SPEC.md § 12 → load_profile{}` (NEW sub-block) | this skill's wizard OR hand-authored | yes (skill writes it back if absent; in Kratos-export mode it writes to `use-cases/<x>/load-profile.yml` since there's no SPEC) |
| Recent Application Insights / `threadlight-deploy/references/observability` traces | live monitor | optional (fidelity boost post-launch) |

### Kratos-export mode (discover from `infra/`, not from a SPEC)

For a **Kratos-exported project** (`src/hosted-agent/` + `use-cases/<x>/`,
trimmed `infra/` — see [`docs/KRATOS-BRIDGE.md`](../../docs/KRATOS-BRIDGE.md))
there is no `specs/SPEC.md` and no `specs/manifest.json`. Adapt the `discover`
phase:

- **Walk the export's `infra/` (`az bicep build` → ARM JSON) + `azd env
  get-values`** to enumerate deployed resources, instead of reading a
  `deployment_manifest{}`. This is the same ARM-walker path the skill already
  uses — just sourced from the export's own Bicep.
- **Tolerate Kratos resource naming.** The trimmed Kratos infra names Cosmos /
  Foundry / ACA resources differently than a `threadlight-design` deployment.
  Match resources by **ARM type** (e.g. `Microsoft.DocumentDB/databaseAccounts`,

From aiappsgbb/threadlight-skills, MIT.

More from aiappsgbb/threadlight-skills