Circular Redundancy Safeguards
Dedup logic blocks "remove A because B / remove B because A" rationales from ever reaching the execution timeline.
Part of the StackSwap Intelligence Ecosystem โ software adoption intelligence for the AI era.
What Are the Circular Redundancy Safeguards?
When two overlapping tools (e.g. Demandbase + 6sense, ZoomInfo + Clearbit) are both marked REMOVE, the naive rationale text cites each as the justification for the other's removal โ producing circular logic that evaporates the moment the plan executes. The safeguards live in two places: components/stackscan/StackscanRecommendedImplementationCard.tsx (the execution-timeline action-line builder) and lib/stackscan-llm-recommendations.ts (the enhanced fallback generator). Both build a set of tools the plan is removing and refuse to cite any of those tools as the "redundant with X" anchor, falling back to the generic "redundant vs your modeled stack" framing.
How It Fits the StackSwap Intelligence Ecosystem
The safeguards are a single-pass dedup on top of the existing rationale generators โ no prompt engineering, no LLM retry, no extra latency. The fuzz harness's I6 + I7 invariants (rationale cannot cite a tool that is also being removed) are the contract the safeguards enforce; 2,500 synthetic scans pass cleanly. The pattern generalizes to REPLACE rationales too: a REPLACE row citing another REPLACE row's target gets the same treatment so the user never sees a swap anchored to a tool that is about to leave the stack.
Why This Matters for Report Credibility
A single circular rationale in the execution timeline undermines every other claim on the report. Readers catch it immediately ("wait, we're removing both?") and the trust loss propagates to savings numbers, AI readiness scores, and the CFO-ready export. The safeguards close a failure mode that manual QA repeatedly caught but could never prevent. Ship-time enforcement via the fuzz harness means the regression can't recur silently.