An answer is only useful
if its evidence fits.

What I was trying to solve

Before an AI shopping assistant recommends a product, what can the product page actually prove? I built AisleLens to turn written buying standards into repeatable checks, with quoted evidence and saved reports a reader could inspect. Coffee was the first domain.

The useful output was a reason someone could examine: which requirement was met, which source supported it, and what still needed information the public page could not provide.

Three lessons that changed how I build

1. A correct fact can still support the wrong answer.

   One change let the engine find barcodes inside product variants. It recovered answers in captured store pages, but the written rule asked for evidence at the product level. A barcode for one variant did not necessarily answer that question. I reverted the widening.

   What I apply now: match evidence to the exact item and conditions in the claim. In a future policy-answer test, that means a fee for one account type cannot prove the fee for another.

2. Test the awkward cases before calling a change better.

   A replay over 338 captured records lost no rows. On the same code change, 78 deliberately chosen cases found 11 regressions. In two cases the pass status stayed the same while the quoted evidence changed. Comparing pass counts alone would have missed the problem.

   What I apply now: keep representative examples and deliberately difficult cases. Compare the answer and its supporting evidence. Include a case that could show the change is wrong.

3. The checker needs its own check.

   An earlier review missed rows that treated a store's internal ID as a useful manufacturer identifier. Those rows showed no quote to question. Going back to the captured source exposed 18 false positives in the sample.

   What I apply now: preserve the underlying value and source. Check results through a second method, and publish corrections when that reveals a blind spot. A confidence number is only as useful as the method that could detect its errors.

Why I am retiring it

The engineering produced useful lessons, but I had not established a dependable way to reach buyers or make the standard part of their decisions. I built ahead of those conversations. More checks would not, by themselves, solve adoption.

Next time I will start with the person responsible when an answer is wrong: what decision do they need to make, what evidence would change it, and would they pay for that evidence? A working engine is one part of a business. It cannot answer those questions for me.

What survives AisleLens

I am keeping the rule-based evidence engine, the difficult test cases, the practice of measuring checker errors, and reports that can be revisited. The code and methods give me a starting point for testing AI answers against an organization's approved facts.

That reuse still needs to be built and tested outside commerce. A successful product-page check is not evidence that a future banking or insurance answer checker works.