Direct RFQ Standard. A Practical Framework for Structured, Qualifiable and Agent-Ready B2B Commerce
The Direct RFQ Standard is an independent framework for organising B2B company, product, capability, commercial and request-for-quotation data.
It is designed for business environments in which information must be used not only by human buyers and sales teams, but also by:
- search engines;
- answer engines;
- AI assistants;
- procurement systems;
- buyer agents;
- supplier agents;
- sourcing platforms;
- agent-to-agent workflows.
The standard helps transform fragmented business information into a consistent structure that can support:
- supplier discovery;
- product identification;
- technical understanding;
- commercial comparison;
- supplier qualification;
- product qualification;
- request-for-quotation preparation;
- quotation response;
- controlled business actions;
- data governance.
A conventional product page often explains what a company sells.
The Direct RFQ Standard goes further.
It defines the information required to determine:
- what the offer represents;
- who provides it;
- whether it is suitable;
- how it can be compared;
- which evidence supports it;
- what information remains missing;
- what the buyer or agent can do next;
- under which rules the information and actions may be used.
Primary CTA: Review the Direct RFQ Standard
Secondary CTA: Request a Direct RFQ Readiness Assessment
What Is the Direct RFQ Standard?
The Direct RFQ Standard is a structured method for describing four fundamental elements of B2B commerce:
- the business providing an offer;
- the product or capability being offered;
- the commercial and operational conditions;
- the purchasing requirement expressed through an RFQ.
It provides a shared information architecture for supply-side and demand-side data.
On the supply side, it can describe:
- companies;
- manufacturers;
- distributors;
- products;
- variants;
- services;
- production capabilities;
- fulfilment capabilities;
- documents;
- commercial conditions;
- agent-accessible actions.
On the demand side, it can describe:
- purchasing requirements;
- technical specifications;
- quantities;
- delivery expectations;
- documentation requirements;
- response deadlines;
- supplier qualification conditions;
- quotation response fields.
The objective is to create a more direct connection between a buyer’s requirement and a supplier’s ability to respond.
Why a Direct RFQ Standard Is Needed
B2B purchasing information is often incomplete, inconsistent and difficult to compare.
A buyer may submit an enquiry such as:
Please send an offer for a packaging machine.
The supplier still needs to determine:
- what product must be packed;
- what packaging material is used;
- what dimensions apply;
- what production speed is required;
- whether the machine will be integrated into a line;
- what utilities are available;
- where the machine will be installed;
- whether commissioning and training are required;
- when delivery is expected.
The supplier may describe its offer equally imprecisely:
High-quality automatic machine with fast delivery and comprehensive service.
This statement does not explain:
- the exact model;
- supported dimensions;
- performance;
- standard configuration;
- optional equipment;
- current lead time;
- delivery scope;
- installation conditions;
- warranty;
- price validity.
The result is a slow and inefficient process based on repeated clarification.
The Direct RFQ Standard creates a structured exchange in which:
- the supplier publishes clearer information;
- the buyer submits a more complete requirement;
- the parties use compatible technical and commercial fields;
- AI systems can identify missing data;
- offers can be compared on a more consistent basis.
An Independent Working Standard
The Direct RFQ Standard is an independent framework developed by Direct RFQ.
It is not an:
- ISO standard;
- IEC standard;
- CEN standard;
- government standard;
- legal certification;
- mandatory procurement regulation.
The word “standard” describes a documented, repeatable and versioned method of structuring B2B information and RFQ workflows.
The framework should be published transparently with:
- a version number;
- publication date;
- scope;
- field definitions;
- implementation rules;
- conformance levels;
- changelog;
- status information.
The standard may reference or work alongside established technologies and classifications, but it should not imply endorsement by their governing organisations.
What the Standard Covers
The Direct RFQ Standard can be applied to several types of business information.
Company Data
Information describing the supplier or buyer as a legal and commercial entity.
Product Data
Information describing a specific product, model, variant or configuration.
Capability Data
Information describing what a company can manufacture, process, integrate, deliver or service.
Commercial Data
Information describing pricing, availability, order conditions, delivery, warranty and service.
Qualification Data
Information required to determine whether a supplier, product or capability fits a specific requirement.
Evidence Data
Documents and sources supporting technical, commercial or business claims.
RFQ Data
A structured representation of the buyer’s requirement.
Action Data
Information defining which business actions are available and what inputs they require.
Governance Data
Information defining ownership, validity, permissions, approval and limitations.
The Seven Layers of the Direct RFQ Standard
The standard is organised into seven connected information layers.
Each layer answers a different business question.
1. Identity Layer
What Is Being Described?
The Identity Layer establishes the precise identity of the company, product, capability, agent or RFQ.
Its purpose is to eliminate ambiguity.
Depending on the object, the Identity Layer may contain:
- canonical name;
- legal name;
- trading name;
- manufacturer;
- brand;
- model;
- product code;
- SKU;
- MPN;
- GTIN;
- internal identifier;
- card identifier;
- RFQ identifier;
- capability identifier;
- category;
- subcategory;
- version;
- status;
- language;
- target market;
- canonical URL.
Company Identity Fields
A company identity may include:
- legal company name;
- legal form;
- registration number;
- tax identifier;
- registered address;
- operational addresses;
- trading brands;
- parent or group entity;
- year established;
- business role.
Product Identity Fields
A product identity may include:
- product name;
- manufacturer;
- brand;
- model;
- version;
- variant;
- product code;
- category;
- lifecycle status;
- replacement product.
RFQ Identity Fields
An RFQ identity may include:
- RFQ title;
- RFQ number;
- buyer;
- publication date;
- response deadline;
- request status;
- confidentiality level;
- version.
Why Identity Matters
AI systems and procurement platforms must distinguish between:
- a company and its brand;
- a manufacturer and its distributor;
- a product family and a specific model;
- a standard configuration and a customised version;
- an active product and an archived model;
- a general enquiry and a formal RFQ.
The Identity Layer provides the stable foundation for all subsequent information.
2. Descriptive Layer
What Is It and What Does It Do?
The Descriptive Layer explains the meaning, purpose and business context of the object.
It may include:
- concise summary;
- detailed description;
- intended use;
- primary applications;
- industries served;
- typical users;
- operating context;
- product benefits;
- service scope;
- supported processes;
- related products;
- related capabilities.
Description Principles
Descriptions should be:
- specific;
- factual;
- understandable;
- consistent;
- commercially useful;
- free from unnecessary ambiguity.
Statements such as “innovative”, “high quality” or “market-leading” should not replace measurable information.
Where a commercial claim is important, it should be supported by:
- a parameter;
- a test;
- a source;
- a case study;
- a defined comparison;
- an identifiable responsible organisation.
Human and Machine Readability
The description should be written for human readers first.
The same meaning should then be reflected consistently in:
- structured HTML;
- schema markup;
- JSON-LD;
- product feeds;
- public JSON files;
- APIs;
- agent resources.
The machine-readable layer should not contradict or materially extend the public human-readable page without an appropriate access and verification model.
3. Qualification Layer
Is the Offer Suitable?
The Qualification Layer defines the conditions under which a product, supplier or capability is relevant.
It may include:
- technical parameters;
- dimensions;
- units;
- performance;
- capacity;
- operating conditions;
- compatibility;
- prerequisites;
- limitations;
- exclusions;
- required buyer inputs;
- configuration logic;
- validation rules;
- test requirements;
- samples;
- drawings;
- technical files.
Product Qualification
A product qualification structure may ask:
- What is the intended application?
- What dimensions apply?
- Which material will be processed?
- What performance is required?
- What operating environment applies?
- Which utilities are available?
- Which optional features are needed?
- Is integration required?
- Which documents must be supplied?
Supplier Qualification
A supplier qualification structure may include:
- geographic coverage;
- production capacity;
- certifications;
- supported materials;
- minimum order size;
- service availability;
- quality procedures;
- industry experience;
- required approvals.
Capability Qualification
A capability qualification structure may include:
- accepted inputs;
- supported processes;
- equipment;
- dimensional ranges;
- tolerances;
- minimum batch;
- maximum volume;
- tooling;
- lead-time determinants;
- quality acceptance criteria.
Why Qualification Matters
A product may be technically impressive but unsuitable for the buyer’s use case.
A supplier may offer the correct process but lack the required capacity, certification or delivery coverage.
The Qualification Layer enables an AI system or procurement team to identify:
- a likely match;
- a likely mismatch;
- missing information;
- a need for human technical review;
- a suitable alternative.
4. Commercial Layer
Under Which Conditions Can the Offer Be Purchased?
The Commercial Layer describes the conditions surrounding the offer.
It may include:
- price;
- price range;
- pricing method;
- currency;
- tax basis;
- price validity;
- minimum order quantity;
- order increment;
- stock status;
- production status;
- lead time;
- dispatch time;
- delivery time;
- delivery territory;
- transport cost;
- Incoterms;
- payment terms;
- reservation terms;
- installation;
- commissioning;
- training;
- warranty;
- service;
- spare parts;
- recurring charges.
Fixed and Non-Fixed Pricing
Not every B2B product can have a public fixed price.
Where a fixed price is unavailable, the standard recommends publishing:
- the pricing method;
- the main price variables;
- the information required for calculation;
- the standard scope;
- common exclusions;
- available budget range, where appropriate;
- expected quotation time;
- quotation validity.
Time-Sensitive Data
Fields such as:
- price;
- availability;
- stock;
- lead time;
- delivery cost;
- promotional conditions;
should include a validity date or confirmation status.
Example statuses may include:
- current;
- indicative;
- subject to confirmation;
- valid until a stated date;
- available from stock;
- made to order;
- temporarily unavailable;
- archived.
Why Commercial Structure Matters
Without clear commercial fields, an AI agent may incorrectly assume that:
- an old price is still valid;
- delivery is included;
- optional equipment is standard;
- stock is available;
- installation is included;
- an indicative price is binding.
The Commercial Layer reduces these risks.
5. Evidence Layer
What Supports the Information?
The Evidence Layer connects claims with identifiable sources.
Evidence may include:
- technical datasheets;
- manuals;
- declarations;
- certificates;
- test reports;
- drawings;
- safety data;
- quality documents;
- compliance documents;
- warranty conditions;
- manufacturer authorisations;
- trademarks;
- case studies;
- public registers;
- source URLs.
Each document should be associated with relevant metadata such as:
- document title;
- document type;
- issuing organisation;
- product or company covered;
- issue date;
- revision;
- validity period;
- language;
- geographic scope;
- verification status.
Evidence Categories
The standard should distinguish between:
Supplier Statement
A statement made by the seller or service provider.
Manufacturer Statement
A statement made by the product manufacturer.
Third-Party Certificate
A document issued by an independent certification or testing body.
Test Result
A result associated with a defined method, sample and scope.
Public Record
Information from an official or verifiable external register.
Commercial Claim
A marketing or sales claim that may require additional evidence.
Why Evidence Matters
Trust should not depend only on presentation quality.
An AI system should be able to determine:
- who made the claim;
- whether it applies to the correct product;
- whether the document is current;
- whether the evidence is independent;
- whether confirmation is still required.
6. Action Layer
What Can the Buyer, Supplier or Agent Do Next?
The Action Layer turns information into an operational process.
Possible actions include:
- request a quotation;
- submit a Direct RFQ;
- request technical information;
- request documentation;
- check availability;
- request a sample;
- book a consultation;
- arrange a test;
- schedule a demonstration;
- request installation assessment;
- reserve stock;
- initiate an order;
- connect to an agent endpoint.
Each action should define:
- action name;
- action purpose;
- required inputs;
- optional inputs;
- accepted attachment types;
- authentication requirements;
- response format;
- expected response time;
- responsible department;
- human approval requirement;
- geographic scope;
- transaction limit;
- escalation path.
Example: Request a Quotation
Required inputs may include:
- product identifier;
- quantity;
- application;
- delivery country;
- delivery postcode;
- required date.
Optional inputs may include:
- technical drawings;
- photographs;
- current product specifications;
- target budget;
- installation requirements.
Example: Request a Product Test
Required inputs may include:
- product being processed;
- sample dimensions;
- sample quantity;
- expected outcome;
- proposed test date;
- responsible contact.
Why Action Structure Matters
A generic contact form does not explain:
- what information is required;
- how the request will be handled;
- whether technical review is needed;
- what the expected response will contain.
The Action Layer creates a predictable and reusable process.
7. Governance Layer
Who Controls the Data and Actions?
The Governance Layer defines responsibility, validity, permissions and limitations.
It may include:
- data owner;
- card owner;
- publisher;
- responsible company;
- responsible department;
- verification status;
- publication date;
- last update;
- review date;
- validity period;
- market scope;
- language scope;
- confidentiality;
- permissions;
- authentication;
- approval requirements;
- transaction limits;
- escalation;
- changelog;
- archive status.
Data Governance Questions
Every implementation should answer:
- Who owns the data?
- Who may change it?
- Who approves publication?
- How often is it reviewed?
- Which fields are time-sensitive?
- What happens when information expires?
- How are corrections recorded?
- How are archived products marked?
- Which information is public?
- Which information requires authentication?
Action Governance Questions
For executable workflows, the organisation should also define:
- Which actions may an agent perform?
- Which actions require human approval?
- What financial limits apply?
- Can the agent confirm availability?
- Can it reserve stock?
- Can it submit an order?
- Can it accept commercial conditions?
- How are actions logged?
- What happens when confidence is low?
- Who handles exceptions?
Why Governance Matters
Machine-readable information can be copied, cached and reused.
Without validity and ownership information, outdated data may continue to influence purchasing decisions.
Governance is therefore a core part of the standard, not an optional administrative layer.
Direct RFQ Standard Objects
The standard can be implemented through several connected information objects.
A2A Business Card
The A2A Business Card describes the company.
It may include:
- legal identity;
- commercial identity;
- company roles;
- markets;
- industries;
- locations;
- brands;
- capabilities;
- certifications;
- trust signals;
- contact routes;
- governance information.
It answers:
Who is the supplier or buyer?
A2A Product Card
The A2A Product Card describes a specific product, model or commercial configuration.
It may include:
- identity;
- specifications;
- applications;
- limitations;
- variants;
- pricing;
- availability;
- delivery;
- service;
- evidence;
- qualification questions;
- RFQ actions.
It answers:
What can be purchased?
A2A Capability Card
The A2A Capability Card describes what a company can perform.
It may include:
- process;
- technology;
- equipment;
- capacity;
- materials;
- tolerances;
- minimum project size;
- required inputs;
- quality control;
- lead time;
- limitations.
It answers:
What can the supplier deliver or perform?
Direct RFQ Card
The Direct RFQ Card describes a specific purchasing requirement.
It may include:
- buyer;
- RFQ identifier;
- request title;
- technical requirement;
- quantity;
- delivery;
- documentation;
- response deadline;
- commercial expectations;
- evaluation criteria;
- response fields.
It answers:
What does the buyer need?
A2A Agent Card
The A2A Agent Card describes a functioning agent and the conditions under which it can interact with other systems.
The official protocol layer may include:
- agent identity;
- endpoint;
- supported interfaces;
- skills;
- security requirements;
- authentication.
The business layer may additionally include:
- legal operator;
- permitted actions;
- commercial scope;
- transaction limits;
- human approval;
- escalation;
- audit rules.
It answers:
What can the agent do, and under which authority?
Direct RFQ Card Structure
A Direct RFQ Card should express a purchasing need clearly enough for a supplier or system to evaluate and respond.
A complete card may contain the following sections.
RFQ Identification
- RFQ title;
- RFQ identifier;
- version;
- status;
- publication date;
- response deadline;
- buyer reference number;
- confidentiality level.
Buyer Information
- legal buyer identity;
- purchasing entity;
- contact;
- location;
- industry;
- project context;
- preferred communication channel.
Requirement Definition
- product, service or capability requested;
- intended application;
- technical specifications;
- dimensions;
- materials;
- performance requirements;
- operating conditions;
- mandatory requirements;
- preferred requirements;
- acceptable alternatives;
- exclusions.
Quantity and Demand
- requested quantity;
- unit;
- expected order frequency;
- annual demand;
- trial quantity;
- forecast;
- permitted quantity tolerance.
Delivery
- delivery location;
- required delivery date;
- delivery window;
- Incoterms;
- packaging requirements;
- unloading requirements;
- installation location;
- site restrictions.
Commercial Expectations
- preferred currency;
- payment expectations;
- target price, where appropriate;
- quotation validity;
- required price breakdown;
- recurring charges;
- tooling cost;
- transport cost;
- installation cost.
Documentation
- datasheets;
- certificates;
- declarations;
- test reports;
- drawings;
- safety information;
- quality documents;
- traceability;
- country-of-origin information.
Services
- installation;
- commissioning;
- training;
- maintenance;
- warranty;
- spare parts;
- technical support;
- service-level requirements.
Supplier Qualification
- geographic coverage;
- certifications;
- experience;
- capacity;
- reference projects;
- required declarations;
- insurance;
- onboarding conditions.
Response Structure
The supplier may be required to provide:
- supplier identity;
- proposed product or capability;
- technical compliance statement;
- exceptions;
- price;
- currency;
- price validity;
- availability;
- lead time;
- delivery conditions;
- warranty;
- documentation;
- responsible contact.
Evaluation Criteria
The buyer may specify:
- technical compliance;
- total cost;
- delivery time;
- service;
- warranty;
- documentation;
- supplier capacity;
- sustainability criteria;
- risk;
- previous performance.
Mandatory, Conditional and Optional Fields
Not every field should be mandatory in every implementation.
The Direct RFQ Standard distinguishes between three field types.
Mandatory Fields
Fields required for the object to be identified and used.
Examples:
- product name;
- supplier identity;
- RFQ title;
- quantity;
- unit;
- response deadline.
Conditional Fields
Fields required only when a specific condition applies.
Examples:
- electrical supply for a powered machine;
- temperature range for cold-storage use;
- SDS for a chemical product;
- installation requirements for fixed equipment;
- tooling data for custom production.
Optional Fields
Fields that improve context but are not required for the basic process.
Examples:
- preferred brand;
- target budget;
- reference application;
- preferred payment terms;
- optional service requirements.
This structure helps avoid two extremes:
- RFQs that are too incomplete;
- forms that request unnecessary information for every use case.
Field Quality Requirements
A field is useful only when its meaning is clear.
Each field definition should specify, where relevant:
- field name;
- field description;
- data type;
- unit;
- accepted values;
- format;
- mandatory status;
- conditional rule;
- example value;
- source;
- owner;
- validity;
- privacy level.
Example Field Definition
Field name: Required delivery date
Purpose: Defines the latest acceptable arrival date.
Data type: Date
Format: YYYY-MM-DD
Mandatory: Yes
Example: 2026-10-15
Owner: Buyer
Validation: Must be later than RFQ publication date.
Example Technical Field
Field name: Product width
Purpose: Defines the maximum width of the product being processed.
Data type: Decimal number
Unit: millimetres
Mandatory: Conditional
Required when: Machine selection depends on product dimensions.
Example: 500 mm.
Units and Values
Technical comparisons are unreliable when units are inconsistent.
The standard recommends:
- always displaying the unit;
- using recognised units;
- defining whether values are minimum, maximum, nominal or tolerance;
- avoiding mixed units in the same field;
- providing conversions where commercially useful;
- distinguishing mass from net product content;
- distinguishing production speed from maximum mechanical speed.
Examples:
500 mm, not only500;17 μm nominal thickness;30 rolls per pallet;12.80 PLN net per kg;lead time: approximately 8 weeks from confirmed order.
Qualifiers such as “approximately”, “nominal”, “up to” and “subject to confirmation” should be explicit.
Data Status and Verification
Every card or data object should display a status.
Recommended statuses include:
- Draft;
- Published;
- Verified;
- Company Confirmed;
- Commercially Current;
- Indicative;
- Subject to Confirmation;
- Update Required;
- Archived;
- Demonstration;
- Public Information Only.
Verified
The responsible organisation has reviewed and approved the information.
Commercially Current
Time-sensitive commercial fields have been confirmed as current.
Indicative
The data can support preliminary evaluation but requires confirmation.
Demonstration
The card exists only to illustrate the structure and is not an active commercial offer.
Archived
The object is retained for reference but should not be treated as currently available.
A status should never be implied only through visual design.
It should be stated explicitly in the content and machine-readable representation.
Versioning the Direct RFQ Standard
The standard itself should be versioned.
An example naming structure may be:
- Direct RFQ Standard 0.1 — Working Draft;
- Direct RFQ Standard 0.5 — Public Draft;
- Direct RFQ Standard 1.0 — First Stable Release;
- Direct RFQ Standard 1.1 — Minor Extension;
- Direct RFQ Standard 2.0 — Major Revision.
Major Version
A major version may introduce changes that affect compatibility or require structural migration.
Minor Version
A minor version may add fields, examples or optional capabilities without invalidating previous implementations.
Patch or Editorial Revision
An editorial revision may correct definitions, examples or documentation without changing the underlying data model.
Changelog
Every release should document:
- release date;
- status;
- new fields;
- changed definitions;
- deprecated fields;
- migration notes;
- compatibility impact.
Versioning Individual Cards
Each A2A Card or Direct RFQ Card should also have its own version history.
Recommended fields include:
- card ID;
- card version;
- publication date;
- last update;
- previous version;
- change summary;
- responsible editor;
- verification status.
Typical changes may include:
- price update;
- stock update;
- new technical parameter;
- revised document;
- changed warranty;
- updated delivery condition;
- discontinued model;
- corrected company information.
An update to one commercial field should not erase the historical context of the entire card.
Direct RFQ Conformance Levels
The Direct RFQ Standard can be implemented progressively.
A company does not need to deploy every field, feed and agent workflow at the beginning.
Direct RFQ Basic
The object has a clear identity and a complete human-readable description.
Minimum Characteristics
- stable web page;
- identifiable company;
- identifiable product, capability or RFQ;
- clear summary;
- contact path;
- publication or update date.
Suitable For
Companies beginning to organise their B2B information.
Direct RFQ Structured
The object uses repeatable sections and consistent fields.
Minimum Characteristics
- structured identity;
- technical attributes;
- units;
- category;
- commercial fields;
- evidence links;
- consistent page architecture.
Suitable For
Companies building repeatable company, product or capability pages.
Direct RFQ Comparable
The information supports meaningful comparison.
Minimum Characteristics
- standard attributes;
- consistent units;
- pricing scope;
- MOQ;
- lead time;
- availability;
- delivery;
- warranty;
- limitations.
Suitable For
Product catalogues, sourcing systems and supplier comparisons.
Direct RFQ Qualifiable
The object contains enough information to assess suitability.
Minimum Characteristics
- intended use;
- technical limitations;
- required buyer inputs;
- qualification questions;
- mandatory conditions;
- exclusions;
- human review triggers.
Suitable For
Complex industrial products, capabilities and services.
Direct RFQ Ready
The object includes a structured request or response workflow.
Minimum Characteristics
- defined action;
- mandatory RFQ fields;
- required attachments;
- enquiry routing;
- response expectations;
- responsible contact.
Suitable For
Companies seeking better-quality enquiries and faster quotation preparation.
Direct RFQ Executable
The object supports a digitally initiated business action.
Minimum Characteristics
- structured form, feed, API or workflow;
- field validation;
- action ownership;
- response format;
- status handling;
- escalation.
Suitable For
Digital sales processes, procurement platforms and workflow automation.
Direct RFQ A2A Enabled
The object can participate in a controlled agent-to-agent process.
Minimum Characteristics
- machine-readable resources;
- stable identifiers;
- explicit actions;
- permissions;
- authentication where required;
- human approval rules;
- logging;
- escalation;
- governance.
Suitable For
Agentic commerce pilots and advanced procurement or supplier-agent integrations.
Direct RFQ Standard and FUCTEG
The standard uses the FUCTEG framework to evaluate the readiness of each implementation.
Findable
Can the relevant company, product, capability, document, RFQ or action be located?
The standard supports findability through:
- stable URLs;
- clear naming;
- identifiers;
- category structure;
- internal linking;
- indexable content;
- accessible documents.
Understandable
Can the information be interpreted correctly?
The standard supports understanding through:
- precise definitions;
- consistent terminology;
- explicit units;
- clear relationships;
- applications;
- limitations;
- business role classification.
Comparable
Can relevant alternatives be evaluated using consistent criteria?
The standard supports comparison through:
- standard attribute sets;
- units;
- commercial fields;
- configuration descriptions;
- delivery and service information;
- total-cost factors.
Trustworthy
Can important claims be verified?
The standard supports trust through:
- legal identity;
- sources;
- evidence;
- document metadata;
- responsible publishers;
- validity dates;
- version history.
Executable
Can the buyer or agent perform a useful next action?
The standard supports execution through:
- action definitions;
- RFQ fields;
- validation;
- response formats;
- routing;
- agent resources.
Governable
Can data and actions be controlled?
The standard supports governance through:
- ownership;
- permissions;
- validity;
- authentication;
- human approval;
- transaction limits;
- logging;
- escalation;
- archival rules.
Human-Readable First
The Direct RFQ Standard follows a human-readable-first principle.
The main information should be understandable on a normal web page without requiring:
- access to an API;
- specialist software;
- knowledge of a data format;
- an AI agent.
The visible page should clearly present:
- identity;
- description;
- qualification;
- commercial information;
- evidence;
- actions;
- governance.
Machine-readable formats should enhance this information, not replace it.
This approach improves:
- accessibility;
- transparency;
- trust;
- search visibility;
- internal review;
- commercial usability.
Machine-Readable Implementations
The same verified information can be represented in several technical forms.
These may include:
- semantic HTML;
- schema.org markup;
- JSON-LD;
- public JSON files;
- product feeds;
- capability feeds;
- RFQ feeds;
- APIs;
- authenticated resources;
- agent endpoints.
Example Public Structure
A company may publish:
/cards/business/example-company/
/cards/business/example-company/index.json
/cards/product/example-product/
/cards/product/example-product/index.json
/cards/capability/example-capability/
/cards/capability/example-capability/index.json
/rfq/example-rfq-2026-001/
/rfq/example-rfq-2026-001/index.json
Recommended Common Fields
Each object may contain:
- object ID;
- object type;
- name;
- version;
- status;
- language;
- market;
- owner;
- publisher;
- publication date;
- last update;
- validity;
- canonical HTML URL;
- machine-readable URL;
- related objects;
- available actions.
Consistency Rule
The machine-readable version should remain consistent with the visible human-readable page.
Where information is available only to authenticated users, the access condition should be explicit.
Direct RFQ and Schema.org
The Direct RFQ Standard can work alongside existing Schema.org types.
Depending on the page, useful types may include:
Organization;Product;Offer;AggregateOffer;Service;Demand;Article;TechArticle;WebPage;BreadcrumbList.
Schema markup can help identify familiar entities and relationships.
However, Schema.org does not automatically provide all fields required for complex B2B qualification, commercial governance or Direct RFQ workflows.
The Direct RFQ Standard therefore acts as a broader business information architecture.
It can use existing structured-data vocabularies where appropriate while maintaining additional field definitions for:
- technical qualification;
- capability matching;
- commercial validity;
- evidence;
- RFQ response;
- permissions;
- governance.
Direct RFQ and Existing Business Systems
The Direct RFQ Standard does not replace existing business systems.
It can use and organise information from:
- ERP;
- CRM;
- PIM;
- PLM;
- DAM;
- e-commerce platforms;
- product databases;
- spreadsheets;
- document repositories;
- procurement systems;
- supplier portals.
ERP
May provide:
- product codes;
- stock;
- prices;
- order status;
- customer-specific conditions.
PIM
May provide:
- product names;
- descriptions;
- technical attributes;
- categories;
- media.
CRM
May provide:
- contacts;
- account ownership;
- opportunity status;
- sales routing;
- follow-up.
PLM
May provide:
- product versions;
- engineering data;
- lifecycle information;
- technical documentation.
DAM or Document Repository
May provide:
- datasheets;
- certificates;
- manuals;
- drawings;
- images.
The Direct RFQ layer determines which verified data should be presented externally and how it should support discovery, qualification and business actions.
Industry Profiles
The standard provides a common architecture but should be adapted to each industry.
An industry profile defines the fields and qualification logic required for a specific market.
Manufacturing Profile
May include:
- manufacturing process;
- materials;
- machine list;
- dimensional range;
- tolerances;
- batch size;
- annual capacity;
- required drawings;
- tooling;
- quality control;
- certification;
- lead time.
Industrial Machinery Profile
May include:
- model;
- function;
- product dimensions;
- performance;
- utilities;
- operating environment;
- safety;
- integration;
- installation;
- commissioning;
- service;
- spare parts.
Packaging Profile
May include:
- packaging format;
- product dimensions;
- throughput;
- film, tape or strap parameters;
- load characteristics;
- machine compatibility;
- line integration;
- consumables;
- test requirements;
- service coverage.
Chemicals and Ingredients Profile
May include:
- chemical or trade name;
- CAS number;
- EC number;
- grade;
- purity;
- concentration;
- physical form;
- application;
- packaging;
- MOQ;
- SDS;
- TDS;
- CoA;
- storage;
- transport;
- regulatory status.
Contract Manufacturing Profile
May include:
- process;
- material;
- dimensional limits;
- tolerances;
- capacity;
- minimum volume;
- prototyping;
- tooling;
- validation;
- customer-supplied files;
- quality procedures;
- lead time.
Industrial Services Profile
May include:
- service scope;
- supported equipment;
- location coverage;
- response time;
- technician qualifications;
- spare parts;
- exclusions;
- service levels;
- emergency procedures.
Distribution Profile
May include:
- represented brands;
- territory;
- authorisation;
- stock;
- lead time;
- delivery coverage;
- minimum order;
- warranty responsibility;
- service responsibility;
- alternative products.
Direct RFQ Implementation Process
1. Define the Use Case
The implementation should begin with a practical business objective.
Examples include:
- improving product pages;
- receiving more complete RFQs;
- creating a public supplier profile;
- publishing production capabilities;
- preparing one product for buyer agents;
- standardising quotation data;
- launching an agentic commerce pilot.
2. Select the Objects
The company identifies which objects should be created.
These may include:
- A2A Business Card;
- A2A Product Card;
- A2A Capability Card;
- Direct RFQ Card;
- A2A Agent Card.
3. Collect Source Data
Relevant sources may include:
- website pages;
- product catalogues;
- technical datasheets;
- manuals;
- declarations;
- certificates;
- price lists;
- ERP exports;
- PIM data;
- service information;
- sales procedures.
4. Map the Data
Existing information is assigned to the seven layers:
- Identity;
- Description;
- Qualification;
- Commercial;
- Evidence;
- Action;
- Governance.
5. Identify Data Gaps
Typical gaps include:
- missing identifiers;
- inconsistent naming;
- missing units;
- unclear variants;
- absent limitations;
- no MOQ;
- outdated prices;
- undefined delivery scope;
- missing documents;
- no qualification questions;
- no update owner.
6. Define Required Fields
The implementation team determines:
- mandatory fields;
- conditional fields;
- optional fields;
- accepted values;
- units;
- validation rules;
- ownership;
- confidentiality.
7. Develop Human-Readable Pages
Complete pages are prepared for buyers, engineers, sales teams, procurement teams and AI systems.
The content should be:
- clear;
- factual;
- structured;
- internally consistent;
- commercially approved.
8. Design RFQ and Action Workflows
The company defines:
- available actions;
- required inputs;
- responsible teams;
- response formats;
- expected response times;
- human approval;
- escalation.
9. Prepare Structured Data
Depending on the project, this may include:
- schema markup;
- JSON-LD;
- public JSON;
- feeds;
- APIs;
- agent resources.
10. Verify and Publish
Before publication, the implementation should be reviewed for:
- technical accuracy;
- commercial accuracy;
- legal entity correctness;
- current prices;
- valid documentation;
- correct ownership;
- data scope;
- security;
- permissions.
11. Maintain and Version
The company establishes:
- update schedules;
- responsible owners;
- validity dates;
- review dates;
- changelog;
- archival procedures;
- agent access controls.
Direct RFQ Readiness Assessment
A Direct RFQ Readiness Assessment evaluates the current quality of a company’s B2B information and workflows.
The assessment may cover:
- company identity;
- product identification;
- capability information;
- technical attributes;
- comparison fields;
- commercial conditions;
- documents and evidence;
- qualification logic;
- RFQ forms;
- actions;
- machine-readable data;
- governance.
The result may include:
- FUCTEG scorecard;
- gap analysis;
- risk list;
- priority improvements;
- recommended card types;
- field map;
- content roadmap;
- technical roadmap;
- governance recommendations.
Typical Deliverables
A Direct RFQ Standard implementation may include:
- standard adoption plan;
- entity map;
- card architecture;
- field dictionary;
- required-field matrix;
- conditional logic;
- unit definitions;
- product-page template;
- capability-page template;
- Business Card template;
- Product Card template;
- Capability Card template;
- Direct RFQ Card template;
- quotation response template;
- evidence register;
- action map;
- governance model;
- versioning rules;
- status definitions;
- schema recommendations;
- JSON structure recommendations;
- implementation roadmap.
Example Pilot Project
A practical pilot can focus on one flagship product.
Pilot Scope
The company prepares:
- one A2A Business Card;
- one A2A Product Card;
- one Direct RFQ Card;
- one structured quotation response;
- one update and governance process.
Pilot Steps
- Confirm the legal supplier identity.
- Define the product and model.
- Collect technical data.
- Define applications and limitations.
- Add pricing and availability rules.
- Link supporting documents.
- Define qualification questions.
- Create the Direct RFQ fields.
- Define the responsible sales workflow.
- Publish the human-readable card.
- Add the machine-readable layer.
- review the results and expand the model.
Pilot Success Measures
The company can evaluate:
- enquiry completeness;
- number of clarification questions;
- qualification accuracy;
- response time;
- quotation preparation time;
- data errors;
- document accessibility;
- sales-team adoption;
- buyer feedback.
Benefits of the Direct RFQ Standard
Better Information Quality
The standard creates a consistent structure for product, company, capability and RFQ information.
Better Discoverability
Clear entities, identifiers, categories and relationships make information easier to locate.
Better Understanding
Defined fields, units and terminology reduce ambiguity.
Better Comparison
Consistent attributes and commercial fields support meaningful supplier and product comparisons.
Better Qualification
Applications, limitations and required buyer inputs improve technical matching.
Better RFQs
Buyers know which information must be supplied to receive a reliable quotation.
Better Supplier Responses
Suppliers can answer using a defined and comparable structure.
Better Sales Efficiency
Sales teams spend less time collecting basic data and correcting incomplete enquiries.
Better Data Reuse
The same verified information can support:
- websites;
- catalogues;
- product feeds;
- procurement platforms;
- AI assistants;
- sales systems;
- partner portals;
- agent workflows.
Better Governance
Ownership, validity, versions and permissions reduce the use of outdated or unauthorised data.
Better Agentic Commerce Readiness
Structured data and actions create a foundation for controlled AI-assisted buying and selling.
What the Direct RFQ Standard Does Not Guarantee
The standard improves information quality, consistency and operational readiness.
It does not guarantee:
- a specific Google ranking;
- citation by an AI system;
- selection by a buyer agent;
- supplier approval;
- technical compatibility;
- transaction completion;
- legal or regulatory compliance;
- compatibility with every procurement platform;
- automatic sales growth.
The framework cannot replace:
- engineering review;
- commercial approval;
- contractual review;
- legal assessment;
- security controls;
- current product data;
- real inventory;
- reliable service;
- human responsibility.
A structured record of incorrect information remains incorrect.
The quality of the implementation depends on the quality, ownership and maintenance of the underlying data.
Frequently Asked Questions
What is the Direct RFQ Standard?
The Direct RFQ Standard is an independent framework for structuring B2B company, product, capability, commercial and request-for-quotation data.
Is it an official international standard?
No.
It is not an ISO, IEC, CEN or government standard.
It is a practical, versioned framework developed by Direct RFQ.
Why is it called a standard?
It provides documented field definitions, repeatable structures, implementation principles, conformance levels and versioning rules.
Who can use the standard?
It can be used by:
- manufacturers;
- distributors;
- wholesalers;
- contract manufacturers;
- industrial service providers;
- procurement teams;
- sourcing platforms;
- AI developers;
- buyer-agent developers;
- supplier-agent developers.
Does the standard apply only to RFQs?
No.
It also structures:
- company data;
- product data;
- capability data;
- commercial information;
- evidence;
- actions;
- governance.
RFQ data is one part of the broader framework.
What is the difference between the Direct RFQ Standard and an A2A Card?
The Direct RFQ Standard defines the overall methodology, layers, fields and implementation rules.
An A2A Card is a structured object created using that methodology.
What is the difference between a Direct RFQ Card and an A2A Product Card?
An A2A Product Card describes what a supplier offers.
A Direct RFQ Card describes what a buyer needs.
What is the difference between the standard and A2O?
The Direct RFQ Standard defines how information and workflows should be structured.
A2O is the optimization process used to improve a company’s readiness for AI-agent discovery, qualification and action.
Does implementation require an AI agent?
No.
A company can implement the standard through human-readable web pages and structured forms.
Agents can be added later.
Does it require an API?
No.
A complete structured HTML implementation can be the first stage.
JSON, feeds, APIs and agent endpoints can be introduced later.
Can the standard be used with an existing PIM or ERP?
Yes.
It can use information from PIM, ERP, CRM, PLM, DAM and procurement systems.
It does not replace them.
Must every field be public?
No.
Fields can be classified as:
- public;
- restricted;
- confidential;
- available after qualification;
- available through authentication.
Does every product need a public price?
No.
Where exact pricing cannot be published, the page should explain the pricing method and required quotation inputs.
Can the standard be adapted to a specific industry?
Yes.
Industry profiles can define specialised attributes, documents and qualification rules.
How should changing prices and stock be handled?
Time-sensitive fields should contain:
- a validity date;
- last-confirmed date;
- status;
- owner;
- confirmation rule.
How often should the data be reviewed?
The review frequency depends on the field.
Prices and stock may require frequent review. Core technical specifications and company identity may change less often.
What is a conformance level?
A conformance level indicates how completely an implementation follows the framework.
The levels range from basic publication to governed A2A-enabled workflows.
Is Direct RFQ Ready the same as transaction-ready?
No.
Direct RFQ Ready means that the buyer or agent can prepare and submit a complete structured request.
Transactional readiness requires additional permissions, security, approval and system integration.
Can the framework support multiple languages?
Yes.
Each language version should retain:
- the same identifiers;
- the same units;
- equivalent field meanings;
- the same version;
- the same commercial scope;
- consistent status information.
Can the framework support private RFQs?
Yes.
A Direct RFQ Card can be public, restricted, invitation-only or confidential.
Access rules should be defined in the Governance Layer.
Can the framework be used by procurement platforms?
Yes.
It can support standardised requirement fields, supplier response structures, qualification criteria and comparison data.
Does using the standard create legal compliance?
No.
Regulatory and contractual compliance must be assessed separately by qualified responsible parties.
Start with a Direct RFQ Standard Pilot
A company does not need to standardise its entire catalogue at once.
A practical implementation can begin with:
- one legal business entity;
- one flagship product;
- one critical capability;
- one recurring RFQ process.
This pilot can establish:
- naming rules;
- identifiers;
- technical fields;
- units;
- commercial fields;
- qualification logic;
- document relationships;
- action definitions;
- governance rules;
- versioning principles.
The model can then be tested, corrected and extended across:
- more products;
- more capabilities;
- more departments;
- additional languages;
- new markets;
- procurement systems;
- agent workflows.
Build a Reliable Information Layer for B2B Commerce
Structure Supply, Demand, Qualification and Action
The future of B2B commerce will depend not only on whether information exists online.
It will depend on whether people and AI systems can use that information reliably.
The Direct RFQ Standard provides a practical structure for connecting:
- companies;
- products;
- capabilities;
- technical requirements;
- commercial conditions;
- documents;
- RFQs;
- actions;
- governance.
Begin with a controlled implementation and develop a repeatable foundation for AI search, procurement systems and agentic commerce.
Primary CTA: Review the Direct RFQ Standard
Secondary CTA: Request a Direct RFQ Readiness Assessment
Additional CTA: Start a Direct RFQ Pilot