Skip to content

From project files to a quote request

Start with the files your engineering team already uses. This recipe ends with a saved request for review. The sample project is synthetic and stays separate from production supplier data.

Starting from SOLIDWORKS, KiCad, Fusion or a shared team folder? Prepare engineering files explains exports, revisions, quantity bases and source references before this workflow.

A useful folder might contain:

enclosure/
bom.csv
requirements.md
drawing-revision-a.pdf
test-requirements.md

Use a local manifest to record what you are working from:

Terminal window
maglev context preview ./enclosure --json > enclosure-manifest.json

The manifest does not interpret CAD or upload anything. Your existing agent reads allowed files with its own tools. A part number, quantity and material should point back to a file/revision or a person’s answer.

Collect what affects this job: part and revision, process, material, finish, quantity, critical dimensions/tolerances, build region, target date and acceptance criteria. Record unknowns explicitly.

For a BOM (bill of materials), distinguish custom parts from purchased components. Keep manufacturer part numbers, quantities and approved alternatives where known. A folder with several assemblies is not automatically a single quote request.

Ask the founder only for missing decisions. “May the manufacturer substitute the alloy?” matters more than asking them to repeat the file’s quantity.

3. Separate hard constraints from preferences

Section titled “3. Separate hard constraints from preferences”

“Made in the US” may be a requirement. “Prefer the fastest option” is a ranking preference. “Quality before price” needs specific acceptance criteria and evidence, not an unexplained score.

Current discovery input can represent the first two:

{"query":"CNC aluminum enclosures","process":"cnc","material":"aluminum","country":"US","quantity":100,"optimize":"speed"}

Save this as discovery.json, then:

Terminal window
maglev discover --input discovery.json --json

Keep richer quality requirements in your brief. They are not currently a supported discovery parameter. An unknown field sent through the CLI produces a clear error.

Choose a returned capability ID:

Terminal window
maglev inspect sample-cnc-us --json

Check required files, material fit, minimum order quantity (MOQ), pricing basis and evidence. A supplier-reported lead time is not a delivery commitment. A listed certification is not evidence that your exact product is certified.

request.json:

{
"capabilityId": "sample-cnc-us",
"input": {
"quantity": 100,
"specification": "Synthetic enclosure, revision A. Aluminum 6061, US build required. Prioritize dimensional quality. Drawings and acceptance criteria need review. No material substitutions without approval."
}
}
Terminal window
maglev quotes request --input request.json \
--idempotency-key enclosure-revision-a-001 --json

Keep the returned run ID with your brief and manifest. The API stores the text specification, not the local files or manifest unless their information is included in that text.

The request is saved for review. No supplier was contacted. A real RFQ (request for quotation) still needs the agreed file set, authorized recipients and a dispatch workflow. Continue with projects and actions for draft preparation and the explicit delivery approval workflow, or discuss coordination with Maglev services.

When a drawing or requirement changes, record a new revision and make the change explicit. Do not reuse a request’s idempotency key for a different specification.