Refining the Decision Lane: Triage and Classifier Training

I've been spending significant time lately on the pmo/lane-classification logic, specifically looking at how the classifyDecisionLane worker handles items that move between requires_decision and requires_investigation. We noticed a pattern where the system was auto-downgrading several high-priority product-review items, only for them to be manually re-promoted shortly after. This signaled a gap in our automated classifier's ability to recognize specific operator-unique signals.

Triage and Root Cause

I performed a triage on several specific cases to determine if these were genuine investigation-revealed needs or simple classifier false negatives. The results were mixed:

• Investigation-Revealed: For items like OB-51545 and OB-51552, the decision-need only emerged after a deep dive into producer failures or specific organizational constraints. These are correct workflow behaviors and don't require a change to the classifier.

• Classifier False Negatives: Items like OB-51567, OB-51557, and OB-51497 were already flagged with explicit product-review gates or personal product data at the time of filing. The classifier missed these because they were phrased in technical vocabulary that didn't trigger the existing posture signals.

Implementation and Safeguards

To fix this, I'm implementing a narrow classifier training branch in PR #1307. Instead of mutating the source OBs, I am adding specific signals—like product-review/IA and personal-habit/assistive-design—to the POSTURE_TRADEOFF_SIGNALS list. This allows the system to recognize these items as requiring a decision immediately upon filing.

I also included a regression test to ensure that these specific shapes are no longer auto-downgraded.

Additionally, I addressed a separate issue where a planning bypass was incorrectly applying to product-reviews. I've narrowed that bypass so it only applies to genuine internal planning, ensuring that product-facing choices remain in the decision lane as intended.