CARBON — Engineering ConfidenceUser Guide
CHAPTER 36 / 60 Pro

/carbon-confidence-plan

Build a risk-based validation plan for an AI feature, model change, prompt change, agent workflow, RAG system, or AI-generated code change before implementation or release.

Jay · Your AI test managerProof & release confidence

When to use it

An AI change needs a risk-led validation design before execution.

Before you start

Prioritize costly wrong answers and unsafe actions, then define populations, controls, expected behavior and decision gates. Keep proposed cases distinct from results.

Try this in your coding agent.

/carbon-confidence-plan Plan validation for the new support chatbot, prioritizing harmful wrong answers.

Replace sample paths with your project. Slash names are shorthand; your host may use a plugin prefix or a skill picker. Invocation help →

ILLUSTRATIVE WALKTHROUGH

Support-chatbot validation plan

An expanded teaching example, not a recorded or live execution. The report stays visible while the replay explains how to read it.

  1. 01Intent
  2. 02Rank harm
  3. 03Design checks
  4. 04Plan

Coding-agent conversation

Intent

I’m reviewing support-chatbot validation plan. I’ll keep the scope and permissions explicit.

Rank harm

A wrong refund answer matters more than a stylistic difference. Prioritize by consequence.

Design checks

Include boundary cases, unsupported requests and explicit escalation expectations.

Plan

High-harm wrong answers take priority over stylistic differences. A plan is not an executed evaluation.

CARBON

Example report

Illustration
Answer vs supporting source
Answer vs supporting source — TestBucks teaching screen

TestBucks course screen with illustrative analysis. The screenshot supplies context; the demo does not establish a newly observed bug.

  1. Question / intent
  2. Reference evidence
  3. Scoring & uncertainty

Illustrated outcome

High-harm wrong answers take priority over stylistic differences.

Evidence to inspect

Rank refund-policy errors, unsafe escalation, ambiguity and unsupported requests.

Still untested / not established

A plan is not an executed evaluation.

Ready. Read the full example or play its steps.

What a useful result contains

A bounded claim

For support-chatbot validation plan, state the target, revision, environment and actual work performed. Keep planned, executed, blocked and untested work separate.

An inspectable trail

Rank refund-policy errors, unsafe escalation, ambiguity and unsupported requests. In a real run, retain the source, trace, screenshot or fixture behind the conclusion.

The qualification

A plan is not an executed evaluation.

The next decision

Decide whether the evidence calls for a focused check, a reviewed fix or more context. Do not convert a plausible example into a verified finding.

Adapt the example to your project

  1. Replace support-chatbot validation plan with a real feature, path or decision in your project.
  2. State the expected rule and its source. Include safe fixtures, constraints and a budget where appropriate.
  3. Ask for exact evidence and remaining gaps. Approve consequential actions separately.
/jay Review the /carbon-confidence-plan result. Separate observed evidence, assumptions and untested scope, then recommend the next useful check.

Where to go next

/carbon-eval →/carbon-eval-design-review →

Content checked against the local command definition: skills/carbon-confidence-plan/SKILL.md. Examples adapted from the homepage’s TestBucks walkthroughs. Availability is edition- and host-dependent.