# Compare two valid action orders before a race review

Illustrative planning brief; no automatic product import.

Synthetic planning case: A toy batch contains independent obligations A and B, both initially unaccepted. Accepting either sets only its own flag. Two permitted serial orders are accept A then B, or accept B then A.

## Decision

Both permitted orders should end with flags A=accepted and B=accepted and a unique accepted-obligation count of two. Their journal order may differ without violating that declared invariant.

## Owned work

- Verify independence in the declared model
  - Owner role: Model owner
  - Acceptance evidence: Accept A changes only A; accept B changes only B.
- Exercise both legal orders
  - Owner role: Rehearsal owner
  - Acceptance evidence: Intermediate and final flag vectors are retained for both traces.
- Review the invariant separately from history
  - Owner role: Reviewer
  - Acceptance evidence: Unique count and final flags match, while different valid journal orders are preserved.

## Workflow

1. Verify independence in the declared model. Check: Accept A changes only A; accept B changes only B.
2. Exercise both legal orders. Check: Intermediate and final flag vectors are retained for both traces.
3. Review the invariant separately from history. Check: Unique count and final flags match, while different valid journal orders are preserved.

## Judgment

No concurrent implementation, event timing or native task-state behavior is verified by the toy traces.


## Filled manual planning note

Both permitted orders should end with flags A=accepted and B=accepted and a unique accepted-obligation count of two. Their journal order may differ without violating that declared invariant. The two traces are the two permutations of the independent actions. Each action changes one different flag; both end at (1,1). Comparing journal text alone would confuse allowed order variation with a failed final invariant. No concurrent implementation, event timing or native task-state behavior is verified by the toy traces.


## Before / after

Before: Journal order treated as the correctness target.

After: Each allowed trace checked against its declared final flags and unique obligation count.


## Workflow questions

### Does this test actual simultaneous races?

No. These are two serial order traces, not an implementation-level concurrency test.

### Would a shared guard change the result?

It might. The independence assumption would need a different model and new expected traces.

## 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

Trace | Intermediate flags A/B | Final flags A/B | Expected unique count
--- | --- | --- | ---
Accept A; accept B | 1/0 | 1/1 | 2
Accept B; accept A | 0/1 | 1/1 | 2

### Reasoning

The two traces are the two permutations of the independent actions. Each action changes one different flag; both end at (1,1). Comparing journal text alone would confuse allowed order variation with a failed final invariant.

### Bounded result

Both permitted orders should end with flags A=accepted and B=accepted and a unique accepted-obligation count of two. Their journal order may differ without violating that declared invariant.

### Distinct decision

The artifact compares allowed event orders by an explicit invariant instead of demanding identical histories.

### Limits

No concurrent implementation, event timing or native task-state behavior is verified by the toy traces.

### Definitions and method context

- NIST: state-based and event-sequence testing context — https://csrc.nist.gov/Projects/automated-combinatorial-testing-for-software — General context for state-based and event-sequence testing. All graphs, guards, fixtures and recovery contracts here are original toy definitions; the source does not certify their completeness or product behavior.