Turn a product question into an evaluation contract

TL;DR: Write the decision, protected requirement and observable event before choosing a test or score. Give each evidence stream its own selection and measurement contract, and keep test authorization separate from the authority to release the feature.

Where you are. Module one, lesson one. You will create the review charter that the remaining lessons turn into an assessment packet.

Start with a decision someone can make

A fictional conference team wants to compare two configurations of its event-planning assistant. The assistant reads public event documents and private attendee notes, prepares a vendor brief and can queue publication. Invited suppliers may edit their own public event material. They do not gain permission to read private notes or choose new recipients for them.

The product owner asks: “Which configuration should we take forward, and what evidence would justify enabling vendor briefs?” Your first task is to turn that request into decisions with limits. Selecting a candidate for more validation is different from authorizing a release. A useful comparison can still reveal that neither candidate satisfies a mandatory requirement.

All records, configurations and results in this course are original synthetic exercises. Work on your own system only within explicit authorization. The course uses offline calculations and fixed evidence packets; it does not require running attacks or contacting a live model.

State the requirement at the actual boundary

For this exercise, private attendee notes must not become readable to a vendor account. That includes previews, saved brief revisions, shared conversation history and queued delivery. Staff may use permitted public event information to prepare a useful brief.

The vendor-exposure event is not identical to a model mentioning a private value, a generated publication call or a final refusal. You need to know where the value came from, which principal could read it and whether the service actually released it. An earlier unauthorized read may violate a separate requirement even when a later publication is denied.

Write requirements independently of the model’s instructions. If the product owner supplies a policy that conflicts with a binding obligation, record the conflict for the responsible owners. Do not let a test prompt or scoring rubric silently redefine what the feature may do.

Separate the questions before combining the evidence

The assessment will use several evidence streams. Their results belong in one packet, but their counts do not belong in one undifferentiated percentage.

A selected failure can be important without estimating its ordinary frequency. Conversely, a precisely calculated rate can be irrelevant if it counts proposals while the requirement concerns actual readers. The later lessons make you check both the calculation and the event behind it.

Make authorization executable

Name the test environment, accounts, data, permitted operations and controlled receivers. Keep the real identity and permission checks that the assessment needs to evaluate. An isolated fixture is useful only if its differences from the intended system are understood.

Set resource limits and a stop control outside the planning model. The operator needs a defined response to unexpected real data, an unapproved destination, lost observations or a scope mismatch. Stopping new work does not necessarily cancel an already accepted downstream operation; the fixture contract must say how pending effects are reconciled.

Define who may inspect the records and how long they may be retained. Use synthetic data by default. If an unexpected sensitive record appears, follow the approved handling process instead of copying it into a broadly shared report. Useful evidence has a purpose and an audience.

Keep a record that another reviewer can challenge

The charter below is the starting artifact for the course. It does not claim that either candidate passes. Later lessons add evidence and may change the recommendation without changing the original requirement.

For each later result, retain a link to the requirement and protocol version. Record what the observer could not see, which configuration was actually tested and whether case selection changed. A reviewer should be able to tell why a conclusion changed without reconstructing the assessment from chat messages.

The authority to accept a residual risk also needs a name and a scope. Some requirements allow an exception under a defined process; others do not. An assessment team cannot convert a mandatory failure into acceptance by lowering a threshold or obtaining an unrelated signature.

Do this before moving on

Draft a one-page charter for the fictional assistant. State the decision, vendor-exposure requirement, one allowed task, approved environment, stop conditions, evidence streams and decision owners. Add two explicit unknowns, such as whether saved previews share the final brief’s reader policy and whether the worker rechecks a changed permission.

Then change one condition: the product owner wants to compare a third configuration using a different case set and a larger attempt budget. Write what must be recorded and what comparison would no longer be direct.

A sound answer preserves the original matched comparison or labels the new study separately. It does not pool all runs and declare the lowest aggregate rate the winner. The new configuration may still provide useful discovery evidence, but the claim must follow its actual protocol.

Go deeper

• What AI red teaming is explains the assessment purposes that this charter keeps distinct.
• Scoping a red-team engagement develops the authority, exclusion and evidence terms used here.
• What counts as a finding tests the difference between a concerning proposal and a verified boundary failure.
• What security benchmarks measure shows why a named benchmark does not specify every experimental choice.
• The release gate explains how evidence, requirements and actual decision authority fit together.

Key takeaways

• Define the decision and observable requirement before selecting a metric.
• Keep discovery, comparison, observer review and sampling studies identifiable.
• Preserve relevant permission checks inside the approved test environment.
• Record limits and authority so later evidence can change a recommendation honestly.