Carry a design change through manufacturing
A drawing changes, the quantity doubles, or the founder changes a requirement. Your agent needs to identify which earlier work still applies before requesting the next step.
Maglev stores project context and action results. It does not currently provide a versioned CAD repository, automatic change-impact analysis or automatic withdrawal of old approvals. Keep a revision record in your existing engineering workspace and connect its records to the returned project and action IDs.
1. Record the change and its source
Section titled “1. Record the change and its source”Compare the new files with the revision used for earlier work. Record the part or assembly, revision, change, reason and decision owner. Keep unknowns explicit.
| Change | Earlier work to review |
|---|---|
| Material, geometry or tolerance | Feasibility, tooling, dimensions and acceptance tests |
| Finish or coating | Process, appearance criteria, fit and quote scope |
| Quantity or batch split | MOQ, setup/tooling allocation, material availability and lead-time basis |
| Component or approved alternative | BOM identity, interfaces, programming and applicable validation evidence |
| Build location or destination | Supplier/site fit, logistics assumptions and applicable compliance review |
This table prompts a review; it does not determine that a particular test or approval is required for every change.
For a local file fingerprint:
maglev context preview ./engineering/revision-b --json > revision-b-manifest.jsonSave the manifest outside the folder being scanned. It records file metadata and hashes; it neither interprets geometry nor uploads files. A different hash shows changed bytes, not whether the engineering impact is large or small.
2. Save the old project and action IDs
Section titled “2. Save the old project and action IDs”maglev projects get PROJECT_ID --json > revision-a-project.jsonmaglev actions get PREVIOUS_ACTION_ID --json > revision-a-action.jsonKeep the previous requirements, file manifest, action input/result, supplier reply and acceptance evidence together in your workspace. An API action stores its validated request input; it does not expose an immutable copy of every project field or local file used when it ran. Saving only the latest project is insufficient to reconstruct an older review.
3. Update the full intended intake
Section titled “3. Update the full intended intake”Read the current project before preparing a patch. intake is replaced as a whole, not merged field by field. Preserve its priorities, hard constraints, known facts and unresolved questions unless the change deliberately replaces them.
The synthetic revision B example changes the requested quantity from 100 to 200 and requests anodizing. Color and acceptance criteria remain undecided. It supplies no new CAD, released drawing or inspection result.
maglev projects update PROJECT_ID --input project-b.json --jsonUse the complete example only with its example project. For real work, construct the patch from your project’s current intake. Keep the compact intake within its 8,192-character limit and retain full engineering files in your existing workspace.
Read the project’s contextVersion and send it as expectedContextVersion in a patch. The server rejects a stale version and requires this guard for structured manufacturing-intent changes. Preserve the complete intended intake object. A project change blocks approval of a stale RFQ; its historical output is retained.
4. Request fresh work with a new key
Section titled “4. Request fresh work with a new key”Prepare a supported action input that names the new revision and changed requirements. The revision B readiness request repeats the quantity, finish uncertainty and retained constraints explicitly.
maglev actions request PROJECT_ID --input readiness-b.json \ --idempotency-key example-revision-b-readiness-001 --jsonUse a key unique to this new request. An old key with the same action kind/input returns the old action—even after the project’s intake has changed. An old key with different action input returns a conflict. Neither case recomputes the previous draft for revision B.
If the new response is interrupted, retrieve its saved action before starting replacement work. An identical replay may return a running or failed record; HTTP 200 does not mean a new review completed. See action states and recovery.
5. Compare the result with the new brief
Section titled “5. Compare the result with the new brief”Read the result at action.output.result once an output exists. Confirm that it preserves the new quantity, revision, constraints and unknowns. Record which old evidence remains applicable, which needs a new review, and who decides.
For RFQs, include the applicable revision and requirements in the action’s supported part fields and questions. Automatic factory selection does not enforce all requirements stored in intake; follow intent and factory selection.
An earlier quote, sample acceptance or test report is evidence for its original scope. Record an explicit applicability decision before using it for the revised scope. A new plan or generated draft is not that decision.
6. Review pending messages and commitments
Section titled “6. Review pending messages and commitments”maglev deliveries get DELIVERY_ID --jsonA project update does not rewrite an earlier delivery. Read its actual revision and status before approval. Withhold an outdated draft from dispatch and use the documented delivery workflow to resolve it.
If a message was already sent or queued for a person, reconcile what happened with the responsible operator. Rejecting a record is not proof that a sent message was recalled, a supplier stopped work or an accepted commitment was canceled.
Keep a compact change record with the old/new revision, project ID, action IDs, affected evidence, decision owner and unresolved items. The revision labels and links in intake are your team’s context; they do not create an API-enforced release gate.