Building an AI-Powered B2B Supplier Matching Platform: Open Protocol Design for China-North America Trade

Editorial update — 22 September 2026: This article discusses a technical design, not the current product's supplier-discovery capabilities. MapleBridge is a procurement workspace for buyers using their own supplier contacts: create an RFQ, invite suppliers, receive their quotes and compare responses. It does not provide a verified supplier directory or automatic supplier introductions.

What this design explores

A sourcing brief carries more information than a product keyword. Quantity, destination, packaging, requested documentation and timing all affect which questions a buyer should ask.

The earlier version of this article blurred a proposed matching architecture with the live product and included unsupported performance, pricing and discoverability claims. Those claims have been removed. The examples below are illustrative; they are not production API contracts or evidence of a supplier database.

Structured intent extraction

Consider this brief:

Custom silicone kitchen tools, 500 pieces, private-label packaging, delivery to Toronto. Please provide the applicable product test reports.

A parser should preserve what the buyer actually requested, leave missing values empty and ask for clarification. It should not infer legal requirements from a destination or turn a supplier's claim into verified evidence.

# Illustrative pseudocode: the model adapter is not implemented here.
def parse_sourcing_intent(text: str, model_call) -> dict:
    instructions = {
        "task": "Extract only information stated in the request.",
        "fields": [
            "product", "quantity", "destination",
            "requested_documents", "budget", "timeline",
            "custom_requirements", "missing_fields"
        ],
        "rules": [
            "Use null for unknown scalar values.",
            "Do not invent certifications or compliance conclusions."
        ]
    }
    return model_call(instructions, text)

An illustrative record:

{
  "product": "silicone kitchen tools",
  "quantity": 500,
  "destination": "Toronto",
  "requested_documents": ["applicable product test reports"],
  "budget": null,
  "timeline": null,
  "custom_requirements": ["private-label packaging"],
  "missing_fields": ["specific product specification", "delivery date"]
}

Model output still needs schema validation and buyer review. Requested order quantity and a supplier's minimum order quantity are separate fields.

Supplier information and evidence

A proposed supplier record should distinguish a statement from supporting evidence. For example:

{
  "supplier_id": "EXAMPLE_ONLY",
  "submitted_categories": ["kitchenware", "silicone products"],
  "submitted_moq": 200,
  "submitted_lead_time_weeks": 6,
  "requested_document_status": "not_received",
  "evidence_references": [],
  "review_status": "not_verified"
}

This is sample data, not a MapleBridge-listed or verified supplier. In the current workspace, buyers invite their own contacts and compare the responses those suppliers submit.

Two-layer comparison

A design experiment could separate explicit requirements from semantic similarity:

Check known quantity, specification and timing constraints.
Keep missing information in a review-needed state instead of silently accepting it.
Use semantic similarity only to organize potentially related records.
Show the supporting fields, unresolved questions and contradictions.

# Design sketch only; helper functions need independent implementation.
def compare_candidates(buyer_intent, supplier_records):
    results = []
    for supplier in supplier_records:
        checks = check_explicit_constraints(buyer_intent, supplier)
        if checks["confirmed_conflict"]:
            continue
        results.append({
            "supplier_id": supplier["supplier_id"],
            "similarity": semantic_similarity(buyer_intent, supplier),
            "missing_fields": checks["missing_fields"],
            "evidence": checks["evidence"]
        })
    return sorted(results, key=lambda row: row["similarity"], reverse=True)

A similarity score is not a probability that a supplier is trustworthy, compliant or able to fulfill an order. This sketch does not send messages, make introductions or approve purchases.

Bilingual model routing

The original design considered QWEN and GPT-based parsing for Chinese and English briefs. No comparative benchmark is provided here, so this article does not claim that either model performs better.

A useful evaluation would include bilingual briefs, mixed-language product terms, omitted quantities, ambiguous currencies and contradictory supplier responses. Model selection should follow those tests, including cost, latency and data-handling requirements.

Public documentation and implementation boundaries

MapleBridge Open contains public technical examples. The documentation entry points referenced in the original article are:

These text files are documentation, not access-control rules or a guarantee that search engines or assistants will index, rank or recommend the site.

The earlier architecture sketch named FastAPI, SQLite, model adapters, containers and an email provider. Naming those components does not establish a production supplier-discovery or automatic matching service. An implementation would also need authorization, input validation, consent-based messaging, audit records and failure handling.

What buyers can use today

MapleBridge.io supports a procurement workflow: prepare an RFQ, invite your own supplier contacts, receive their quotes and compare responses. Suppliers' commercial statements and documents still require the buyer's review. This article does not promise free service, guaranteed sourcing outcomes or verified factories.

DEV Community