# Audit project membership in a work report

Illustrative planning brief; no automatic product import.

Synthetic case: A worksheet labelled project P contains accepted rows A/P, B/P, C/Q and D/P with unknown acceptance evidence.

## Decision

Under the P-plus-evidenced-acceptance rule, retain A and B, exclude C by scope and keep D as an evidence exception.

## Owned work

- Record the inclusion rule
  - Owner role: Report owner
  - Acceptance evidence: The project and accepted-event boundaries are both stated.
- Check every row’s membership
  - Owner role: Reviewer
  - Acceptance evidence: C is outside P; D lacks acceptance evidence under this policy.
- Explain exclusions
  - Owner role: Coordinator
  - Acceptance evidence: Four rows reconcile to two included, one scope exclusion and one evidence exception.

## Workflow

1. Write all scope predicates before inspecting the total.
2. Check stable identity, membership and required event evidence.
3. Retain exclusions and exceptions instead of erasing them from the audit trail.

## Judgment

Unknown acceptance is not rejection. Do not paste real cross-project data into the public worksheet or imply it verifies organization permissions.


## Filled review note

Scope note: two included accepted records for P, one Q scope exclusion and one P acceptance exception.


## Workflow questions

### Does matching project P prove inclusion?

Not alone; this rule also needs acceptance evidence.

### Can this validate an actual product filter?

No. It is a manual example; verify the real query, permissions and underlying records separately.

## Product connection

Bring this manual reporting policy and its owned checks into your TeamBoostAI work discussion. Native report/export fields and historical reconstruction depend on your account and implementation; this worksheet does not import or change product records.

Confirm account availability before adopting this manual outline.

## Decision workshop

Synthetic examples only. Manual worksheet; no automatic import or product writes.

### Synthetic reporting records

ID | Project | Acceptance state | Treatment
--- | --- | --- | ---
A | P | Accepted evidence | Include
B | P | Accepted evidence | Include
C | Q | Accepted evidence | Out of scope
D | P | Unknown acceptance | Exception

### Version changes

Boundary | Draft | Revised
--- | --- | ---
Scope | Project label accepted without inspection | Membership checked row by row
Evidence | Unknown acceptance counted as complete | Unknown kept as an exception

### Draft or earlier version (review its limits)

Draft: four deliveries for project P.

### Revised example

Scope note: two included accepted records for P, one Q scope exclusion and one P acceptance exception.

### Decision situations

- Membership and acceptance predicates are known: Apply the stated predicates and keep excluded reasons.
- Only one predicate has been checked: Finish the other check before publishing the total.
- The report scope is unspecified: Ask for the intended project/event boundary.

### Complete message drafts (review before use)

#### Scoped note

The worksheet includes two accepted P records. One Q record is outside scope; one P record has unresolved acceptance evidence. Please review the exceptions before publishing.

#### Scope clarification

Which project and acceptance-event rule should this report use? I will retain exceptions until those boundaries are confirmed.

### Method references

- The Kanban Guide, May 2025: https://kanbanguides.org/the-kanban-guide/2025.5/ — Clock and work-item definitions; examples and local rules are our own.