# QA Results: Signal Revocation Controls

## Test Execution Summary

| Suite | Tests | Result |
|---|---|---|
| `cargo test --lib` | 1355 | PASS |
| `tests/m10_revocation.rs` | 10 | PASS |
| `tests/m10_community_policy.rs` | 10 | PASS |
| `tests/m9_leave_revocation.rs` | 7 | PASS |

**Total: 1355 lib + 27 integration tests, all passing. Zero failures.**

## Static Analysis

- `cargo clippy -- -D warnings`: clean (fixed two `assigning_clones` and `const_fn` warnings in `schema/validation/builders/mod.rs`)
- `cargo fmt --check`: clean

## QA Plan Coverage

| Scenario | Test | Result |
|---|---|---|
| QA-1: SignalType revocation suppresses sort score | R1 | PASS |
| QA-2: TimeRange revocation suppresses in-window signals | R2 | PASS |
| QA-3: Cancel revocation restores ranking | R3 | PASS |
| QA-4: Non-revoked signal types unaffected | R4 | PASS |
| QA-5: List includes active + cancelled | R5 | PASS |
| QA-6: User isolation — revocation scoped to one user | R6 | PASS |
| QA-7: Multiple overlapping revocations (union) | R7 | PASS |
| QA-8: Durability across DB reopen | R8 | PASS |
| QA-9: Cancellation durability | R9 | PASS |
| QA-10: Anonymous query bypass | R10 | PASS |

## Regression Check

No regressions in M9 or M10 community policy suites. The revocation wiring in `ProfileExecutor` and `RetrieveExecutor` is opt-in (both `revocation_index` and `for_user_revocation` must be set) — existing code paths that don't wire revocations are unaffected.

## Performance

- Fast path (no user revocations): single DashMap miss in `RevocationIndex::is_suppressed`, effectively O(1).
- Slow path (R active revocations): O(R) linear scan per signal per entity. At R=5 and typical candidate set sizes, this is within the latency budget with no measurable impact on existing benchmarks.

## Verdict

**PASSED.** Feature is complete, correct, and regression-free.