One ID per claim

Description and use

The "one ID per claim" method eliminated proposal count errors caused by menu items and provided reliable data verification.

Problem

Counting proposals by grepping status words led to inconsistent counts because menu items were counted as proposals.

Outcome

The new method prevented counting menu items as proposals, identified a false rejected proposal, and caught other data inconsistencies, providing clear diagnoses when counts diverged.

Workflow

• 1. Identify the proposal card container on the dashboard.
• 2. Extract the unique identifier (e.g., Sent on: DATE line) from each card.
• 3. Read the status inside the card, ignoring the filter menu.
• 4. Count the number of cards to determine open bids.
• 5. Perform a second derivation of the count and diff the results for positive control.
• 6. Diff counts against historical runs using the stable identifiers to detect true changes.
• 7. Flag any discrepancies for investigation.

Evidence

The reader we built greps the page's raw text for status words. Aguardando appears 12 times in cards — and once more in the filter menu, where the platform lists every status you could select.

Source

Find the container first. On this dashboard, a proposal is a card, and every card contains a Sent on: DATE line. Count cards, not keywords.

Source

Positive control before you trust a number. Before publishing any count, re-derive it a second way and diff.

Source