Keep the lessons.
Change the next decision.

A better test does not create adoption.

I published detailed rules and built checks around them. That did not establish who would make those rules part of a real decision, who would pay for the evidence, or how I would reach them. For Truvli, I want buyer conversations to settle those questions before I commit to a full product.

Code can answer only some questions.

PRIVI's published rubric separated checks readable from code from checks that need a running system or evidence of how it is operated. A description of a permission cannot show that the permission held during an actual action. I carry that distinction into the design of the next test.

Every checker needs a way to be proved wrong.

In AisleLens, a change that looked good on captured pages failed deliberately difficult cases. Another review found errors that an earlier method could not see. I will keep examples designed to break the rules, retain the source evidence, and measure the new checker's errors instead of inheriting confidence from an old project.

An unproven idea should stay unproven.

PRIVI did not demonstrate its original idea of predicting future failures from past ones. No prediction was scored against an outcome. I will not turn that missing evidence into a success story. The next claim has to earn its own support.

Three tests for what comes next

1. Does someone need an independent check?

   Find out whether a buyer needs evidence beyond the agent vendor's own results. Independence has to matter to a real decision.

2. Is there an authoritative source to compare against?

   Use the deploying organization's approved facts and effective dates. A plausible answer generated by another model is not the source of truth.

3. Who is responsible when the answer is wrong?

   Talk with the person who has to resolve the consequences. Establish whether the problem has an owner, a budget and a reason to act.

Truvli is my proposed way to investigate those questions. Its market and its checker still need validation.

What I can carry forward

The reusable starting points are the evidence-engine code, deliberately difficult test cases, error-measurement methods, reports that can be revisited, and the distinction between code inspection and live checks. Applying them to a new domain still requires implementation and fresh evidence.