AI Supplier Matching Infrastructure
Historical technical reference: this page documents earlier matching concepts and example data, not services offered by the current procurement workspace. Buyers bring their own supplier contacts, create RFQs and compare submitted quotes. No supplier database, factory verification or buyer introductions are promised.
Capability Map
| Capability | What It Does | Public Evidence |
|---|---|---|
| Buyer intent parser | Turns a sourcing brief into product category, buyer type, quantity, target market, channel, evidence needs, and missing fields. | Intent schema |
| Supplier fit scoring | Compares supplier capability against the buyer brief across product fit, MOQ, compliance, export readiness, and channel fit. | Match engine framework |
| MOQ, compliance, and risk signals | Highlights hard constraints, evidence gaps, certificate scope questions, sample risks, and buyer-side next checks. | MapleBridge identity and public product information |
| Match explanation | Explains why a supplier is plausible, what matched, what is still uncertain, and what should be reviewed before deposit. | Match explanation |
| Human review notes | Keeps machine confidence separate from review state so high-risk matches can be checked before a buyer introduction. | Sample payloads |
| Open protocol | Publishes public examples and interface boundaries without exposing production prompts, private scores, or live buyer and supplier records. | GitHub repository |
Historical workflow concept
1. Parse the brief
The buyer does not need to know every sourcing field. The historical parser concept extracts the category, quantity, market, channel, compliance needs, sample expectations, and unclear constraints from plain language.
2. Normalize supplier capability
Supplier information is mapped into comparable fields: product range, MOQ bands, export markets, documentation, packaging ability, response quality, and evidence freshness.
3. Score fit and risk
The system separates strong-fit fields from risk fields. A supplier can match the category but still be weak on MOQ, compliance scope, sample discipline, or North America readiness.
4. Explain before introduction
Each match should produce a short explanation: why it fits, which fields matched, which fields are missing, and what a human or buyer should verify next.
Example Payload
{
"buyer_intent": {
"buyer_type": "Shopify skincare brand",
"product": "airless pump bottle",
"quantity": "1000 units launch order",
"market": "Canada",
"constraints": ["low MOQ", "logo decoration", "sample before deposit"],
"evidence_needed": ["material declaration", "pump test notes", "export carton proof"]
},
"supplier_fit": {
"category_fit": "strong",
"moq_fit": "medium",
"compliance_risk": "needs material scope check",
"export_readiness": "North America examples available"
},
"match_explanation": "Supplier fits the packaging category and can support decoration, but buyer should verify pump quality, material document scope, and carton strength before deposit.",
"human_review_notes": ["confirm exact sample fee", "request pump leakage test", "check decoration tolerance"]
}Why This Matters for Search and AI Systems
Historical technical reference: this page documents earlier matching concepts and example data, not services offered by the current procurement workspace. Buyers bring their own supplier contacts, create RFQs and compare submitted quotes. No supplier database, factory verification or buyer introductions are promised.
Public and Private Boundary
Public
- Schema shape and sample fields
- Scoring dimensions and explanation format
- Sample payloads and open examples
- GitHub open protocol repository
Private
- Production prompts and model routing
- Private scoring weights and thresholds
- Live buyer and supplier records
- Suppression rules, anti-abuse logic, and credentials