mustflow 2.116.4 → 2.117.1

package/templates/default/locales/en/.mustflow/skills/llm-model-routing-integrity-review/SKILL.md

@@ -0,0 +1,183 @@
+---
+mustflow_doc: skill.llm-model-routing-integrity-review
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: llm-model-routing-integrity-review
+description: Apply this skill when an LLM system selects, cascades, escalates, falls back, or switches models by task, stage, confidence, verifier result, distribution shift, cost, latency, quality, safety, or context handoff and must optimize total cost per accepted outcome without hiding route-specific failures.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.llm-model-routing-integrity-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# LLM Model Routing Integrity Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Choose the least expensive model path that still satisfies measured outcome, latency, and safety
+requirements. Prevent a cheap per-call route from becoming expensive after retries and repairs, and
+prevent a strong-model default from becoming an unevaluated permanent tax.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A system adds or changes a model router, small-to-large cascade, escalation threshold, fallback,
+  provider or region route, stage-specific model, ensemble, speculative path, or confidence gate.
+- Planning, retrieval, coding, validation, summarization, classification, or tool-use stages may use
+  different models and context can be lost when the route changes.
+- Routing depends on cost, latency, accepted-outcome probability, external verifier results,
+  uncertainty, risk, task value, traffic volume, or distribution shift.
+- A claim says a smaller model is sufficient, a stronger model is worth the premium, or a routing
+  system pays for its own fixed evaluation and operating cost.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The main risk is prompt payload size, cacheability, token budgets, reasoning spend, or retry replay
+  rather than route correctness; use `llm-token-cost-control-review`.
+- The main risk is response speed, streaming, speculative cancellation, or time to first useful
+  output; use `llm-response-latency-review`.
+- The main risk is agent tool authority, approval, side effects, or autonomy; use
+  `agent-execution-control-review`.
+- The main risk is selling standard versus premium outcomes, charging for automatic escalation,
+  task-unit price, managed provider cost, or BYOK packaging; use
+  `llm-product-monetization-review`. Keep this skill for route correctness and total route cost.
+- The task chooses a provider or technology stack for strategic reasons rather than routing requests
+  among already supported models; use `technology-stack-selection`.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Outcome contract: accepted task result, deterministic and semantic validators, safety floor,
+  latency objective, abstain or escalation state, and value or loss of a wrong result.
+- Route ledger: task and stage types, candidate models and versions, route features, baseline route,
+  escalation and fallback rules, context handoff, retry owner, route version, and stable assignment.
+- Evidence ledger: per-route accepted-outcome rate, confidence interval or conservative bound,
+  false-accept and false-reject rates, route coverage, sample size, task mix, risk mix, and evaluator
+  independence.
+- Cost and latency ledger: model, router, verifier, retry, repair, handoff, supervision, and fixed
+  evaluation, adapter, monitoring, migration, and maintenance cost.
+- Distribution ledger: training and evaluation distribution, production feature distribution,
+  missing-feature behavior, out-of-distribution detector, drift monitor, and safe fallback.
+- Safety ledger: tasks that require a fixed strong route, deterministic path, human decision, or
+  hard refusal regardless of expected financial utility.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Establish a capable-model baseline and accepted-outcome evaluator before claiming a cheaper route
+  preserves quality.
+- Treat model self-confidence, verbal certainty, token probability, and router score as uncalibrated
+  until matched to external outcome evidence on the current task distribution.
+- Refresh provider model, price, latency, retention, and endpoint claims before embedding exact
+  values. Do not copy benchmark percentages or universal thresholds into reusable policy.
+- Keep command execution under `.mustflow/config/commands.toml`; this skill does not authorize live
+  model calls, traffic routing, billing access, or production rollout.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine route schemas, features, baseline and candidate policies, external verifiers,
+  escalation and abstain states, context handoff, OOD fallback, metrics, eval fixtures, shadow
+  comparisons, tests, docs, route metadata, and synchronized templates.
+- Move deterministic classification, validation, policy, arithmetic, schema checking, and database
+  postconditions out of model routing when code can decide them.
+- Do not weaken quality or safety validators to make a cheaper route appear successful.
+- Do not route high-impact decisions by average utility when a hard safety or authorization gate
+  fails.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Define the accepted outcome before selecting a model. Include final-state correctness, safety,
+   latency, abstention, and repair rules rather than counting a syntactically valid response.
+2. Establish the baseline with the most capable practical route and current evals. Only then replace
+   bounded task classes or stages with smaller models where accepted outcomes remain sufficient.
+3. Route deterministic work to code first. Do not pay a model or router to decide values that a
+   schema, compiler, test, database lookup, permission engine, or exact rule can determine.
+4. Choose route granularity from real context boundaries. Keep tightly coupled planning and
+   execution on one model when switching would lose hidden constraints or require replaying most of
+   the context. Split classification, retrieval-query generation, formatting, or verification when
+   their inputs and outputs are explicit and independently checkable.
+5. Measure route quality with external evidence. Calibrate router scores against tests, schema and
+   business validation, source agreement, database postconditions, human adjudication, or another
+   independent oracle. Preserve false-accept cost separately from ordinary failure.
+6. Optimize total cost per accepted outcome. Include router, verifier, failed cheap attempts,
+   escalation, retries, repair, context transfer, supervision, latency loss, and fixed operating
+   cost. A lower model price is not a saving when acceptance falls or repair rises.
+7. Apply hard constraints before utility. Authorization, privacy, irreversible effects, safety
+   invariants, and maximum tolerable loss can force a deterministic, strong-model, human, or refusal
+   route even when a cheaper path has positive expected value.
+8. Build cheap-first cascades only when the acceptance gate can reject bad cheap outputs with known
+   false-accept behavior. Without an external verifier, repeated sampling and self-critique do not
+   prove which candidate is correct.
+9. Escalate from observed evidence, not model preference. Use validator failure, missing required
+   facts, task complexity, risk class, OOD state, repeated error signature, or explicit uncertainty
+   features. Do not escalate privileges when escalating model capability.
+10. Handle distribution shift explicitly. Compare production features and outcomes with the route's
+    evaluation distribution. Send missing, novel, drifted, or low-support cases to the safe baseline
+    route, deterministic review, or human owner.
+11. Account for context handoff loss. Version the handoff schema, preserve verified facts and hard
+    constraints, avoid summary-on-summary drift, and measure whether route switches cause omissions
+    or contradictory plans.
+12. Keep route and retry ownership separate. A route change may be a recovery action, but it must
+    share the workflow's attempt budget and idempotency state rather than restarting the task as a
+    new operation.
+13. Compare candidates in shadow or replay before promotion. Pin model and route versions, use the
+    same representative task mix, preserve delayed outcomes, and route rollout details through
+    `agent-release-bundle-rollout-review` when the router is part of an agent bundle.
+14. Recalculate routing economics when traffic, task distribution, models, prices, verifier quality,
+    repair rate, or maintenance burden changes. Route broad investment decisions to
+    `automation-investment-case-review`.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Every route has an accepted-outcome contract, external evidence, safe fallback, and versioned
+  decision reason.
+- Cost comparisons include failed attempts, verification, escalation, repair, context handoff, and
+  fixed operating cost.
+- OOD and hard-safety cases cannot silently enter a cheap route.
+- Model self-confidence is not treated as outcome probability without calibration.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available: `changes_status`, `changes_diff_summary`,
+`lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, and `mustflow_check`.
+Do not infer raw provider, model, billing, traffic, eval, or rollout commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If no accepted-outcome evaluator exists, keep the baseline route and report the missing gate.
+- If route evidence is sparse or distribution support is missing, abstain from the cheaper route.
+- If false accepts can create high-impact harm, treat the route as unsafe until a hard gate or human
+  decision closes the boundary.
+- If route savings depend on stale price or benchmark data, mark the economic claim unverified.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Outcome contract and baseline route
+- Candidate route, features, version, and context boundary
+- External calibration, false-accept, OOD, and drift evidence
+- Total cost-per-accepted-outcome and latency findings
+- Hard safety, escalation, fallback, and abstain decisions
+- Command intents run and skipped checks
+- Remaining model-routing risk

package/templates/default/locales/en/.mustflow/skills/llm-product-monetization-review/SKILL.md

@@ -0,0 +1,311 @@
+---
+mustflow_doc: skill.llm-product-monetization-review
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: llm-product-monetization-review
+description: Apply this skill when an LLM product changes token-based versus task- or outcome-based pricing, bounded document/image/analysis units, standard versus precision service tiers, free versus paid queue priority, first-value queue exemptions, automatic credit restoration or retry rights for failed work, user-facing model disclosure or model pinning, cheap-default and premium-model packaging, internal model escalation, managed provider cost, BYOK or customer-supplied API keys, platform fees, included credits, margin, conversion, or retained contribution and must keep user-visible value understandable while internal provider cost, capacity, failure, transparency, and credential risk remain controlled.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.llm-product-monetization-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# LLM Product Monetization Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Sell an understandable unit of user value while metering tokens, tools, models, retries, storage,
+capacity, and provider cost internally. Package quality, queue priority, failure recovery, model
+transparency, and credential funding without manufacturing delay, charging for unusable work,
+exposing unstable vendor implementation as the product contract, surprising users after automatic
+escalation, or turning BYOK into insecure onboarding friction and a margin escape hatch.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A consumer, SMB, developer, or enterprise LLM product chooses token, character, page, document,
+  image, minute, run, analysis, report, accepted result, credit, seat, or hybrid billing units.
+- A task unit changes its page, byte, duration, source, OCR, search, tool, output, retry, quality,
+  latency, concurrency, or variable-cost boundary.
+- A product offers standard, fast, precise, premium, verified, or named-model tiers, or automatically
+  escalates from a cheaper model to a stronger model.
+- Free and paid users receive different queue priority, concurrency, start-time objectives, capacity
+  shares, first-value treatment, background completion, or paid fast-lane promises.
+- Provider errors, timeouts, empty or malformed output, quality-gate failures, subjective
+  dissatisfaction, automatic retries, credit restoration, bound retry rights, or abuse controls
+  change.
+- A product chooses outcome-mode labels, provider or model-family disclosure, exact model and
+  version receipts, fallback disclosure, model pinning, or internal provider replacement policy.
+- A product chooses managed provider credentials, BYOK, customer cloud accounts, a platform fee,
+  included usage, prepaid credits, or enterprise provider routing.
+- Conversion, cost per accepted result, gross margin, failed-work charging, heavy-tail cost, retained
+  use, or provider migration economics are created, changed, reviewed, or reported.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The main risk is prompt payload, token counting, caching, RAG packing, retry replay, output budget,
+  or internal cost telemetry; use `llm-token-cost-control-review`.
+- The main risk is whether a router, cascade, escalation, fallback, or context handoff preserves
+  accepted outcomes; use `llm-model-routing-integrity-review`.
+- The task only changes a model picker, progress, result, citation, or error interface without price
+  or credential economics; use `llm-service-ux-review`.
+- The task only changes scheduler fairness, queue durability, starvation, admission control, or
+  latency instrumentation without a free-versus-paid product policy; use
+  `queue-processing-integrity-review` and `llm-response-latency-review`.
+- The task only changes generic plan price, annual billing, trial, regional pricing, or non-LLM usage
+  pricing; use `pricing-model-integrity-review`.
+- The main risk is credit reserve, balance, capture, release, reversal, expiry, or spend order; use
+  `credit-monetization-integrity-review` and `credit-ledger-integrity-review`.
+- The main risk is secret storage, tenant isolation, key brokerage, credential access, exfiltration,
+  provider terms, residency, or incident response. Use the security, privacy, secret, and provider
+  owners; this skill supplies the product and economics contract.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Audience ledger: consumer, prosumer, developer, SMB, enterprise, procurement, technical ability,
+  expected cadence, willingness evidence, failure cost, and budget predictability.
+- Task-unit ledger: user job, accepted result, input and output bounds, pages, bytes, duration, media,
+  OCR, search, tools, sources, iterations, revisions, latency, concurrency, price, credits, and overage.
+- Internal-cost ledger: provider, model, input, cached, output, and reasoning tokens; tool calls;
+  images, audio, video, storage, search, OCR, egress, retry, verification, moderation, support,
+  payment, fraud, refund, and failed-work cost.
+- Quality-tier ledger: public tier, accepted-outcome contract, latency, evidence, verification,
+  included operations, route version, automatic escalation, fallback, user-selected upgrade, and
+  price authorization.
+- Credential ledger: managed or customer-funded account, provider, key owner, scope, storage,
+  encryption, access, rotation, deletion, logging, quota, residency, audit, failure, and support.
+- Economics ledger: eligible-user conversion, useful completion, paid use, cumulative revenue,
+  provider cost, tail cost, contribution, refund, chargeback, support, abuse, churn, and retention.
+- Experiment ledger: pre-price assignment, package parity, audience and task strata, exposure,
+  horizon, provider and model versions, guardrails, and promotion rule.
+- Queue-service ledger: first owned value, free and paid eligibility, real capacity state, weight or
+  reservation policy, concurrency, aging, starvation bound, enqueue and start time, estimated range,
+  background delivery, abandonment, cancellation, capacity cost, and service objective.
+- Failure-recovery ledger: attempt and quote identity, failure classifier, provider and product
+  evidence, deterministic quality gate, retry lineage, reservation, capture, release, reversal,
+  restored asset, bound retry right, expiry, abuse evidence, appeal, and support state.
+- Transparency ledger: public mode, accepted-outcome contract, provider, model family and version,
+  route and fallback version, execution receipt, customer pin, reproducibility need, procurement or
+  jurisdiction requirement, AI-origin marking, change notice, and retention policy.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Separate the customer-visible billing unit, internal resource meter, service-quality tier, and
+  credential-funding model. One does not prove the others.
+- Define an accepted user result and failure policy before pricing a task or capturing credit.
+- Define first owned value before imposing a materially slower free queue, and classify objective
+  system failure separately from subjective dissatisfaction before granting a reusable asset.
+- Assign experiments before price, model tier, or BYOK setup becomes visible and keep abandoners in
+  the intent-to-treat denominator.
+- Refresh current provider models, prices, meters, tool charges, tokenizers, key rules, retention,
+  regional availability, and platform terms before embedding exact claims.
+- Treat copied page limits, credit ratios, percentiles, margin targets, model names, price multiples,
+  and another product's BYOK policy as hypotheses, not defaults.
+- This skill does not authorize live price, provider, credential, credit, routing, experiment,
+  payment, or production changes.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine task units, scope limits, quotes, quality tiers, model-independent service contracts,
+  real-capacity queue classes, first-value exemptions, failure classifiers, automatic restoration,
+  bound retry rights, execution receipts, model disclosure and pinning, BYOK and managed-cost policy,
+  platform fees, contribution metrics, experiment events, fixtures, tests, docs, route metadata, and
+  synchronized templates.
+- Add explicit handoffs to token-cost, model-routing, credit-ledger, payment, security, privacy,
+  provider, accounting, tax, or legal owners.
+- Remove unbounded per-document pricing, post-hoc token bills, surprise escalation charges,
+  client-side key storage, hidden provider cost, fake unlimited use, or free BYOK that receives the
+  full product platform without covering its cost.
+- Do not change the promised price after internal retry or escalation unless the user explicitly
+  authorized a separately defined higher service tier before execution.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Split seven decisions: external billing unit, internal resource meter, public service tier,
+   managed versus customer-funded credentials, queue priority, failure recovery, and model
+   transparency. Do not present one bundle as the only possible design.
+2. Classify the buyer. End-user products need predictable job and result language; developer APIs can
+   expose resource meters where technical buyers control payload and value that transparency;
+   enterprise products may need both task budgets and provider-account control.
+3. Prefer a user-recognizable unit when the product owns an end-to-end job. Name the accepted result
+   and scope rather than selling an ambiguous document, image, analysis, or agent run with no bounds.
+4. Bound every task unit. Define input pages or bytes, media duration and resolution, OCR, search,
+   tools, sources, revisions, output length, latency, concurrency, timeout, and overflow behavior.
+   Split materially different jobs instead of hiding extreme cost in one average.
+5. Quote before execution. Show task tier, fixed or bounded credit spend, included work, maximum
+   scope, and failure treatment. Route reservation, useful-result capture, release, and reversal
+   through the credit skills.
+6. Treat paid priority as a capacity contract, not synthetic friction. When capacity is available,
+   start eligible free and paid work promptly; never add sleep solely to manufacture an upgrade.
+7. Protect first owned value. Let a new eligible user receive enough successful representative work
+   to judge the product before a materially slower free lane where cost, safety, and abuse permit.
+   Derive the allowance from result variance and marginal cost rather than copying a universal count.
+8. Design queue priority from observed load and abandonment. Define work class, weight or reserved
+   capacity, concurrency, aging, cancellation, starvation bound, and overload behavior. Preserve a
+   bounded free path rather than strict paid-first starvation.
+9. Show honest wait state. Measure enqueue-to-start separately from generation time, show a range or
+   queue state backed by current evidence, preserve work after the user leaves where appropriate, and
+   notify or place completed work in an owned result surface. Do not show fake exact countdowns.
+10. Derive queue objectives from task duration, user attention, first-value state, capacity cost,
+    abandonment curves, and paid value. Treat copied seconds, minutes, weights, or capacity shares as
+    experiment candidates, not service laws.
+11. Meter the complete internal cost. Include tokens, cache behavior, reasoning, tools, media,
+   retrieval, storage, retries, verification, moderation, support, payment, abuse, and refunds. A
+   token-only ledger can understate the cost of the task the customer bought.
+12. Price tail risk deliberately. Use the observed cost distribution and a declared service objective
+   rather than average cost alone; a percentile such as p95 can be a candidate, not a universal law.
+   Add scope splits, overage, or a higher tier when bounded honest pricing cannot cover the tail.
+13. Derive the floor from retained contribution, not a copied markup. Include full variable cost,
+   refunds, support, acquisition, provider volatility, and useful-result probability. Validate that
+   the customer values the bounded result above that floor.
+14. Classify failures before settlement. Treat provider errors, timeouts, empty output, corrupt media,
+    truncated required output, deterministic schema failure, duplicate execution, and declared
+    quality-gate failure as objective candidates when current evidence can reproduce the rule.
+15. For objective operator-owned failure, retry only when the same logical attempt can do so safely;
+    otherwise release or reverse the authorized charge automatically and idempotently. Do not make
+    users file a claim for a failure the system already proved.
+16. Keep subjective dissatisfaction separate. A same-lineage, nontransferable retry right can be a
+    candidate when intent fit is uncertain, but do not convert every dislike into general-purpose
+    credit. Bound reuse, model escalation, expiry, review, and appeal from observed abuse and cost.
+17. Evaluate restoration by incremental variable cost and retained contribution, not credit face
+    value alone. Include extra execution, support avoided, repurchase, refunds, disputes, abuse, and
+    user trust; never use a universal refund or complaint quota as the product contract.
+18. Route reserve, capture, release, reversal, retry identity, and reconciliation through the credit
+    skills. A browser timeout or client cancellation alone does not prove provider failure or permit
+    duplicate restoration.
+19. Keep public tiers model-independent by default. Describe speed, result quality, verification,
+   source coverage, revision policy, and latency. Do not promise a vendor model name unless that
+   identity is itself a required and maintainable contract.
+20. Make the standard tier good enough to represent the product. A deliberately poor cheap result is
+    an activation failure, not an upgrade funnel. Escalate internally when needed to meet the promised
+    standard accepted outcome.
+21. Do not surprise-charge automatic escalation. Router, verifier, retry, and stronger-model cost
+    used to satisfy the selected tier belongs to the operator. Charge more only for a user-selected,
+    prepriced tier with materially different scope or outcome.
+22. Route quality through `llm-model-routing-integrity-review`. Compare total cost per accepted
+    outcome, false accepts, retries, repairs, context handoff, OOD fallback, and fixed evaluation
+    cost; cheap per-call price alone is not product margin.
+23. Separate AI transparency from vendor merchandising. Tell users they are using AI and expose
+    material limitations, provenance, or generated-content marking required by the product and
+    current authority; that does not require turning an unstable model brand into the plan name.
+24. Keep an auditable execution receipt. Record provider, model family and version, route, fallback,
+    tools, and execution time internally, and expose the subset needed for user verification,
+    procurement, reproducibility, support, or jurisdiction rules without leaking secrets.
+25. Offer exact model pinning only when identity or reproducibility is a paid or regulated contract.
+    A pinned execution must not silently substitute another model; fail, ask, or use an explicitly
+    accepted fallback. Outcome-mode routes may change providers only while preserving their accepted
+    result and disclosure contract.
+26. Refresh transparency and marking duties by product role, geography, content type, publication
+    path, and date. Do not infer that a visible watermark alone satisfies machine-readable marking,
+    disclosure, accessibility, provenance, or legal obligations.
+27. Use an expensive-only baseline when the declared failure cost, safety floor, or narrow task value
+    justifies it. Do not generalize a high-stakes exception to ordinary extraction, transformation,
+    drafting, or classification.
+28. Compare managed and BYOK from the full activation path. Include external account creation,
+    billing setup, key creation, trust, storage, quota, provider support, first-value delay, conversion,
+    cost control, and retained platform revenue.
+29. Keep managed credentials as a strong candidate when immediate end-user activation and integrated
+    usage revenue matter. Bound abuse with task limits, concurrency, budgets, idempotency, cost alerts,
+    and explicit included usage rather than a secretly throttled unlimited promise.
+30. Offer BYOK where technical or enterprise buyers need provider ownership, negotiated pricing,
+    region, model, quota, or procurement control. Charge a platform fee for workflow, storage,
+    collaboration, retrieval, audit, support, and automation value that remains operator-owned.
+31. Treat customer keys as secrets, never ordinary preferences. Require server-side or approved
+    secure handling, least privilege, encryption, access audit, redaction, rotation, deletion,
+    tenant isolation, and bounded provider errors; route the implementation to security owners.
+32. Prevent credential-mode arbitrage and lock-in. Define which features, support, quotas, providers,
+    credits, and usage records differ between managed and BYOK modes, and let qualified customers
+    migrate without losing owned product data.
+33. Preserve external price meaning across provider and model changes. Version the task, quality,
+    cost, route, and credential contracts so internal optimization can improve margin without
+    silently reducing the result the user purchased.
+34. Evaluate from eligible assignment over meaningful repeat-use and billing horizons. Track first
+    value, queue wait and abandonment, useful completion, conversion, task mix, tail cost, gross
+    margin, contribution, provider failures, automatic reversals, retry-right use, abuse, support,
+    BYOK setup loss, churn, and retained use.
+35. Promote only a reversible policy that improves eligible-user contribution while preserving
+    understandable scope, nonmanufactured queueing, useful-result charging, fair failure recovery,
+    acceptable quality, credential security, current transparency duties, provider compliance, and
+    explicit latency, model-routing, credit, and security handoffs.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- External task or resource units and internal provider-cost meters are separate and reconstructable.
+- Each task unit has an accepted result, scope, quote, overflow, failure, and tail-cost policy.
+- Standard and premium tiers describe product outcomes rather than relying on unstable model names.
+- Automatic retry or model escalation cannot create an unapproved price increase.
+- Free and paid queue classes consume real capacity, preserve first value and a bounded free path,
+  expose honest wait state, and do not manufacture delay.
+- Objective operator-owned failure can release or reverse charges idempotently, while subjective
+  dissatisfaction uses a separately bounded recovery asset when offered.
+- AI-origin, outcome mode, execution receipt, exact model pinning, fallback, and provider replacement
+  have explicit transparency and reproducibility boundaries.
+- Managed and BYOK modes have explicit activation, credential, quota, platform-fee, support, revenue,
+  migration, and security boundaries.
+- Headline economics use eligible users and total cost per accepted result over retained use.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available: `changes_status`, `changes_diff_summary`,
+`lint`, `build`, `test_related`, `test`, `docs_validate_fast`, `test_release`, and `mustflow_check`.
+Do not infer live provider, model, key, billing, credit, analytics, experiment, deployment, or
+production commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If task scope or accepted result is undefined, do not publish a fixed task price.
+- If complete internal cost is unavailable, label margin as unverified and add bounded limits before
+  expanding managed usage.
+- If a cheaper route lacks accepted-outcome evidence, keep the capable baseline and route the gap to
+  the model-routing skill.
+- If a paid queue converts only by intentionally slowing idle free capacity, reject it as synthetic
+  friction. If the free lane can starve, add bounded capacity or aging before promotion.
+- If failure cannot be classified or the attempt cannot be reconciled, keep the reservation pending
+  under a bounded recovery policy; do not both retry and restore reusable value blindly.
+- If current product-role, content, or jurisdiction transparency duties are unresolved, preserve an
+  auditable execution receipt and route the launch decision to qualified authority.
+- If customer keys cannot be isolated, redacted, rotated, and deleted securely, do not offer hosted
+  BYOK; preserve managed mode or require an approved enterprise integration boundary.
+- If a pricing arm wins conversion but loses accepted results, retained contribution, support, or
+  security guardrails, reject or narrow it.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Audience, accepted result, task unit, limits, quote, overflow, and settlement policy
+- Internal token, tool, media, retry, verification, support, and tail-cost ledger
+- Standard and premium outcome contracts, automatic route, escalation, and price authorization
+- Queue eligibility, first-value treatment, capacity, fairness, wait evidence, abandonment, and paid
+  priority decision
+- Objective failure, subjective dissatisfaction, retry lineage, restoration asset, abuse, appeal,
+  reserve, capture, release, and reversal decision
+- AI-origin disclosure, execution receipt, model family and version, pinning, fallback, provider
+  replacement, reproducibility, and authority decision
+- Managed and BYOK activation, credential, quota, platform-fee, migration, and security decision
+- Eligible conversion, accepted results, margin, contribution, retention, and provider evidence
+- Files changed
+- Command intents run and skipped checks
+- Remaining LLM product monetization risk

package/templates/default/locales/en/.mustflow/skills/llm-token-cost-control-review/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.llm-token-cost-control-review
 locale: en
 canonical: true
-revision: 5
+revision: 7
 lifecycle: mustflow-owned
 authority: procedure
 name: llm-token-cost-control-review
@@ -47,6 +47,12 @@ Review LLM cost as a product and systems contract, not as prompt brevity. A cost
 - The main risk is unsupported factual output, fabricated citations, source coverage, answerability, abstain behavior, retrieval thresholds, or hallucination metrics; use `llm-hallucination-control-review`.
 - The main risk is time to first token, first useful output, streaming, LLM round trips, tool wait, prompt-cache latency, model routing speed, priority tier, realtime continuation, or user-perceived response speed; use `llm-response-latency-review`.
 - The main risk is autonomous agent execution control, tool-call approval, side-effect replay safety, durable resume behavior, handoffs, guardrails, loop budgets, retry classification, or trace outcome evaluation; use `agent-execution-control-review`.
+- The main risk is whether a model router, cascade, escalation, fallback, or stage switch preserves
+  accepted outcomes under quality, safety, latency, context-handoff, and distribution-shift risk;
+  use `llm-model-routing-integrity-review`. Keep this skill for token and request-cost mechanics.
+- The main risk is customer-visible token versus task pricing, bounded outcome units, standard versus
+  premium packaging, managed provider cost, BYOK, platform fees, or failed-work charging; use
+  `llm-product-monetization-review`. Keep this skill for internal resource and cost mechanics.
 - The main risk is cloud account, infrastructure, SaaS, quota, budget, tag, retention, or provider-account spend guardrails outside the model-call payload; use `cloud-cost-guardrail-review`.
 - The main risk is rate-limit fairness, throttling, quota counters, concurrency limits, 429 response behavior, or protected-resource definition; use `rate-limit-integrity-review`.
 - The task only edits user-visible copy and does not affect LLM payload, model choice, retry behavior, or cost telemetry.
@@ -69,6 +75,9 @@ Review LLM cost as a product and systems contract, not as prompt brevity. A cost
   prompt-packing rule, and current input-token measurement.
 - Output ledger: output schema size, repeated key length, patch versus full-output policy, `max_output_tokens`, reasoning budget, retry repair inputs, validator errors, and incomplete-response handling.
 - Routing ledger: deterministic prefilters, small-model router, expensive-model escalation rule, batch or flex eligibility, predicted-output eligibility, image or file preprocessing, and fallback behavior.
+- For route-quality decisions, include the accepted-outcome evaluator, false-accept behavior,
+  distribution support, context-switch loss, and fixed router or verifier cost through
+  `llm-model-routing-integrity-review` instead of treating token price as sufficient evidence.
 - Observability ledger: input tokens, cached tokens when exposed by the provider, output tokens, reasoning tokens when exposed or billable, retry count, validation failure count, cache hit rate, cost per successful task, model, endpoint, prompt version, tool version, schema version, and budget breach events.
 - Boundary ledger: token estimates and caps owned here; accepted-work reservation persistence owned by `command-pattern`; prepaid or money-equivalent reserve, capture, and release owned by `credit-ledger-integrity-review`; allow, block, downgrade, and obligation provenance owned by `policy-decision-integrity-review`.
 
@@ -134,6 +143,9 @@ Review LLM cost as a product and systems contract, not as prompt brevity. A cost
 17. Pack by references before raw text. Prefer stable document ids, chunk ids, section anchors, source maps, block refs, and token counts when choosing context. Expand only the needed source spans instead of replaying a whole corpus or full document list.
 18. Keep tool and schema payloads boring. Tool descriptions and JSON schemas should be long enough for correct routing and validation but not narrative prose. If permissions differ by user, keep schema stable and enforce permission at tool execution.
 19. Route before calling the expensive model. Use deterministic code, regexes, database lookups, small models, or cheap classifiers for tasks that do not need a large reasoning model; escalate only ambiguous, high-value, or failed cases.
+    Judge candidate models by total cost per accepted outcome, including verifier, escalation,
+    retry, repair, and handoff cost. Route calibration, OOD fallback, false-accept risk, and hard
+    safety constraints through `llm-model-routing-integrity-review`.
 20. Budget reasoning and output together. Set reasoning effort and output limits according to task value; leave enough room for visible output, and handle incomplete responses instead of silently retrying the full expensive request.
 21. Prefer patches over full regeneration when the product already owns most of the output. Use unified diff, JSON Patch, line-range replacement, IDs, labels, scores, or reason codes when downstream code can merge the result.
 22. Repair failures without full replay. For parse failures, enum mismatches, missing fields, or validator errors, retry with previous output, validator error, and schema summary when safe instead of resending the entire original context.
@@ -155,6 +167,8 @@ Review LLM cost as a product and systems contract, not as prompt brevity. A cost
 - Compression quality is evaluated against answer, citation, numeric, constraint, and refusal behavior rather than judged by shorter text alone.
 - Deterministic work is handled outside the model unless language judgment is required.
 - Metrics can explain cost per successful task, cache-prefix drift, retry cost, validation failures, and model routing decisions without leaking sensitive prompt or user data.
+- Cheaper-model claims are separated from route-integrity evidence and do not rely on per-call price
+  alone.
 - Final reports distinguish proven cost-control evidence from assumed provider behavior, anecdotal token savings, and latency-only optimizations.
 
 <!-- mustflow-section: verification -->