Vendor Memory Rules

Short plan: keep vendor choice mostly rule-based, use ranking only after the rule layer fails.

Model

Hard rules

Explicit or near-explicit PM policy. These override everything.

property=Primrose + trade=plumbing -> Guox

Scoped exceptions

Negative or positive local behavior that should not leak globally.

avoid Yonic at Primrose

Fallback defaults

General learned preference when no specific condition matches.

trade=plumbing -> Yonic

Decision flow

New work order property, trade, issue Specific rule? property + trade + issue Fallback rank trade/default roster prior Use winner rule explains why Ask / null if confidence is thin Draft PM vendor or none

Data shape

rule
condition: normalized predicates like property, owner, trade, issue_type. action: prefer vendor, avoid vendor, require owner approval, ask first.
evidence
Each rule points back to observations and PM text. Confidence comes from explicitness plus repeated confirmations.
fallback score
A small trade-level prior per vendor, not a global truth. Property exceptions never subtract from the trade default.
{
  "kind": "vendor_rule",
  "condition": { "property": "6337 Primrose Ave", "trade": "plumbing" },
  "prefer_vendor": "Guox Maintenance & Remodel",
  "avoid_vendors": ["Yonic Herrera"],
  "strength": "hard",
  "evidence_count": 4
}

Memory writes

Confirm

“Yes, send Yonic.”

Low-salience evidence for the current scope, unless it repeats a settled rule.

Override

“No, send Guox.”

Strong scoped evidence: chosen vendor positive, suggested vendor negative in that condition only.

Policy

“Always use Guox at Primrose.”

Promote directly to a hard rule with high confidence and provenance.

Risks

Overfitting
One override should not create an “always” rule. Keep one-offs as observations until repeated or explicit.
Condition drift
Normalize property/trade/issue labels before matching, or rules silently miss.
False confidence
When the best match is only fallback ranking, the PM draft should sound softer or omit the vendor.