request_physical_solution
Submit a physical-world requirement (a part, product, device, or capability that must exist in the physical world). a2a2p resolves it and returns a RESOLUTION REPORT: a recommended path (best existing commercial solution vs. custom fabrication), pricing, tradeoffs, a delivery plan with contingencies and expedite options, and a business case when business context is provided. Response is asynchronous: you receive a request_id immediately with an instant spec_review. Poll check_request_status; as soon as an automated draft exists it is returned with an a2a2p.resolution-report-delivery receipt that distinguishes machine_draft from operator_published. If the finite attempt budget is exhausted, status returns generation_failed; if the bounded automatic retry window expires first, it returns generation_expired. Either terminal state permits only a new caller-confirmed request from caller-held input. Operator review and publication are not guaranteed or subject to a service-level promise. No state is professional engineering certification or a supplier quote.
ENTRY MODES — arrive with what you have: • fully_specified: provide 'specification' (part_type, material, process, dimensions, tolerance_class, design_files). Go straight to resolution report. • intent_only: provide 'intent' (purpose, environment, functional_requirements, quantity, timeline, priority). a2a2p recommends 2-3 specification options with tradeoffs. • partial: provide what you know in either layer; a2a2p fills the gaps.
Layer 1 (intent) describes the PROBLEM. Layer 2 (specification) describes the SOLUTION. At minimum, provide 'requirement' (legacy) or 'intent.purpose' (structured) — one line describing what you need. Use 'rejected_alternatives' to record options already ruled out.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | Layer 1 — the problem. What the physical matter needs to DO. Use this for intent-driven requests where the agent describes purpose and a2a2p recommends solutions. | |
| contact | No | Optional email or callback endpoint for quote delivery. | |
| deadline | No | Required delivery date or timeframe. Maps to intent.timeline. | |
| quantity | No | Number of units needed. Maps to intent.quantity. | |
| budget_usd | No | Approximate budget in USD. Maps to intent.budget_envelope. | |
| constraints | No | Hard constraints: tolerances, certifications, materials to avoid, size/weight limits. Maps to intent.functional_requirements. | |
| requirement | No | Plain-language description of the physical need. Maps to intent.purpose. Include function, dimensions, materials, load/performance requirements, environment, and interfaces where known. | |
| callback_url | No | Optional HTTPS URL. When the quote is ready, a2a2p POSTs it as JSON to this URL. | |
| specification | No | Layer 2 — the solution. What the physical matter IS. Populate what is known. Precise specifications produce faster, tighter quotes. Controlled vocabularies are preferred but open values are accepted. | |
| business_context | No | Optional business requirements (expected volumes, cost targets, ROI constraints). If provided, the quote includes a business case. | |
| rejected_alternatives | No | Options already considered and ruled out. Prevents re-suggesting and builds the learning corpus. |