# Classify a negative test against its expected result

Illustrative planning brief; no automatic product import.

Synthetic planning case: An external acceptance contract rejects a request with a missing required identifier. Test A receives that expected rejection; test B accepts another identifier-missing request.

## Decision

A passes this negative-test expectation and B fails it. Do not label every rejection a product failure or every accepted request a pass.

## Owned work

- Confirm the missing-input contract
  - Owner role: Behavior owner
  - Acceptance evidence: The identifier is actually required in this external example.
- Compare expected and observed outcomes
  - Owner role: Reviewer
  - Acceptance evidence: A matches rejection; B violates the same declared boundary.
- Assign the unexpected acceptance
  - Owner role: Delivery owner
  - Acceptance evidence: B’s failing fixture receives an owned investigation without changing the expected result after the fact.

## Workflow

1. Confirm the missing-input contract. Check: The identifier is actually required in this external example.
2. Compare expected and observed outcomes. Check: A matches rejection; B violates the same declared boundary.
3. Assign the unexpected acceptance. Check: B’s failing fixture receives an owned investigation without changing the expected result after the fact.

## Judgment

The example supplies no native API or permission claim. Error text, recoverability and other valid/invalid conditions need separate evidence.


## Filled manual planning note

A passes this negative-test expectation and B fails it. Do not label every rejection a product failure or every accepted request a pass. Verdict compares observation with the declared expectation. The outcome sign alone—accepted or rejected—does not define test success. The example supplies no native API or permission claim. Error text, recoverability and other valid/invalid conditions need separate evidence.


## Workflow questions

### Can a rejection still be wrong?

Yes if it rejects a valid input or has another unaccepted behavior; the contract must be explicit.

### Does A prove every invalid input is handled?

No. It is one fixture under one boundary.

## Product connection

Use the owned checks and downloaded brief to discuss this planning decision alongside your TeamBoostAI tasks. Confirm available fields, roles and account features separately. The example is manual; it does not calculate live analytics, create work or run an experiment in the product.

Confirm account availability before adopting this manual outline.

## Original worked case

Synthetic records, manual planning only. No account import or live analytics.

### Inspect the invented case records

Test | Declared expected behavior | Observed toy behavior | Verdict
--- | --- | --- | ---
A | Reject missing identifier | Rejected | Pass
B | Reject missing identifier | Accepted | Fail

### Reasoning

Verdict compares observation with the declared expectation. The outcome sign alone—accepted or rejected—does not define test success.

### Bounded result

A passes this negative-test expectation and B fails it. Do not label every rejection a product failure or every accepted request a pass.

### Distinct decision

The artifact classifies negative-test success against a stated contract rather than an intuitive positive/negative label.

### Limits

The example supplies no native API or permission claim. Error text, recoverability and other valid/invalid conditions need separate evidence.

### Definitions and method context

- Original worked-case definitions — Definitions, policy choices, records and calculations are authored for this worksheet. No external standard, statistical validation or live product measurement is claimed.