How this fits together

You’re looking at a bid sheet. Each line item — 8” Gate Valve, MJ, Filter Fabric Barrier, Tapping Sleeve — needs a price. The way you get to that price is what this system is built to make better.

What the estimator sees today

   Houston bid                  Chicago bid
   ───────────                  ───────────
   Filter Fabric Barrier        Perimeter Erosion Barrier
   8" Gate Valve, MJ            8" Gate Valve, FL
   Hydrant Assembly             Fire Hydrant
        │                            │
        │   Look up                  │   Look up
        │   Houston history          │   Chicago history
        ▼                            ▼
    Sparse comps                 Sparse comps
        │                            │
        └─────────────┬──────────────┘
                      ▼
          Bid each one with partial data

The agencies use different names for what’s often the same part. Pricing histories don’t pool across jurisdictions because matching is by name, not by what the part actually is. You have less data than you should, and you can feel it on the call.

What the ML engine changes

   Houston: Filter Fabric Barrier
   Chicago: Perimeter Erosion Barrier
        │              │
        ▼              ▼
   ┌─────────────────────────────────────────────┐
   │              ML ENGINE (LINC)               │
   │                                             │
   │  Both recognized as canonical: silt_fence   │
   │  Combined price history:                    │
   │     P50: $4.20 / LF                         │
   │     P10 – P90: $3.10 – $6.50                │
   │  Confidence: high                           │
   │  Evidence: 247 historical observations      │
   │            across IL, TX, OH                │
   └──────────────────────┬──────────────────────┘
                          ▼
              Pricing surfaces inside BidEdge,
              with the evidence behind it

This is supervised machine learning in the literal sense. A classifier — a model trained on labeled examples — predicts what canonical part each new line item is. The labels come from an experienced estimator who has confirmed which oddly-named items point to the same thing. The model generalizes from those labels and applies the pattern to items it has never seen.

The terms aren’t optional jargon. Estimators who carry them will read the engine’s output with sharper judgment than estimators who don’t:

• Training data — the labeled examples the model learns from
• Inference — when the model is asked, in real time, “what is this line item?”
• Confidence — the model’s own quantified assessment of how sure it is about a given prediction
• Evaluation set — held-out, never-trained-on examples used to measure how often the model is right

Why the Joiner exists

The engine isn’t magic. It is exactly as good as its training data. That training data comes from the Joiner — a labeling tool where an experienced estimator confirms cross-jurisdictional equivalences, one pair at a time:

   "Filter Fabric Barrier"  ≡  "Silt Fence"          [YES]
   "Tapping Saddle Assy"    ≡  "Air Release Valve"   [NO]
   "Hydrant Assembly"       ≡  "Fire Hydrant"        [YES]

Each YES becomes a labeled example. A few hundred of those, at three seconds per call, become the dictionary the classifier trains on. Skip the labeling and the engine has nothing to learn from. Sloppy labels and the engine learns sloppy patterns.

The reason we need an experienced estimator and not an algorithm-or-chatbot is that cross-jurisdictional fluency lives only in the head of someone who has bid across enough markets to recognize the same part wearing different costumes. That kind of knowledge can’t be scraped from the internet — it has to be labeled by someone who already has it.

Where Jeff fits right now

Jeff Young is doing the labeling. v1 of the Joiner is read-only docs — this site. v2 will be the actual labeling app where his clicks land in the system.

If you are Jeff:

• → Joiner Role — what you’re doing and why
• → Joiner Manual — the rules for deciding YES / NO / SKIP

What you’ll see in BidEdge when the engine ships

For every line item on a new bid sheet, the engine will give you:

• Predicted canonical identity — what kind of part it thinks this is
• Confidence — high / medium / low, on calibrated thresholds
• Comparable prices — historical observations grouped under the same canonical part, across jurisdictions
• Evidence — exactly which historical bids contributed to the comparable

You aren’t handed a number and told to trust it. You’re handed a prediction with provenance, and you override anything that smells wrong. Every override is a signal the engine learns from on the next training run.

This is the separator. Other bid-history tools dump rows at you. This one understands what each row is, tells you why it grouped them, shows you the evidence, and gets sharper as estimators correct it. The understanding comes from the Joiner. The Joiner comes from Jeff. The chain is short and visible.

Where to go next

• Joiner Role — Jeff’s role explained
• Joiner Manual — the operational rules
• The Joiner app — coming with v2