Scope the project and prepare agreements

Start with the decision you need to make. A founder who wants three quotes needs a smaller scope than a founder commissioning design, tooling and a production run. Keep that distinction in the brief and in each request.

Maglev can prepare strategy, engineering estimate, NDA and statement of work drafts. Your existing system remains the place for signed agreements, file-access grants, accepted budgets and engineering approvals. These actions do not create those approvals.

1. Confirm the brief from existing files

Read the permitted BOM, requirements and design notes with your existing agent. Use a short founder interview for the decisions those files do not answer. Preserve the design revision and the source of each fact.

Save the project brief with:

• The next outcome: quote, prototype, test, pilot build or repeat production.
• Hard constraints: critical quality, material, manufacturing location and permitted substitutions.
• Preferences: price, speed and other tradeoffs the founder allows.
• Known evidence and the questions that still block the next step.
• Who can authorize communications, file sharing, spending and release of a build.

Free-form intake records that context. It does not enforce a spending limit or grant a factory access to files. Carry relevant requirements into the action’s supported input fields as well.

2. Prepare the strategy discussion

Use strategy_brief with specific goals, constraints and founder questions. Review its agenda, proposed questions and decisionsThatLockCost. Remove questions already answered by the authoritative files; retain questions that require a decision.

The synthetic scoping examples continue the 100-enclosure project. Material is proposed, tolerances are unknown and no supplier contact is authorized.

maglev actions request PROJECT_ID \
  --input examples/project-scoping/strategy.json \
  --idempotency-key example-revision-a-strategy-001 --json

Use the returned action.id to retrieve the result later. Read action.status before action.output.result; a generated result is a draft. If a request is interrupted, recover the saved action before creating replacement work.

3. Define engineering work before estimating it

Use engineering_estimate to break the scope into work, deliverables, risks and one-time engineering cost lines. Supply the engineering work you actually need. Quoting one enclosure does not imply responsibility for its electronics, firmware or certification.

maglev actions request PROJECT_ID \
  --input examples/project-scoping/estimate.json \
  --idempotency-key example-revision-a-estimate-001 --json

Review the result against the request:

Result	Review
workBreakdown	Is each activity needed, with a concrete deliverable?
nreLines	Is a number supported by an applicable source, or should it remain unknown?
maglevFee	Keep Maglev’s service fee distinct from external engineering and factory charges
riskRegister	Does each risk describe what must be learned or resolved?
assumptions, openQuestions	Which decisions prevent a firm scope or estimate?

A prior project’s fee or a historical supplier price is not an offer for this project. Obtain a scoped response from the responsible engineering partner before treating its cost or schedule as agreed. The action does not request that quote automatically.

4. Handle confidentiality before sharing the file set

nda_draft prepares a document from Maglev’s templates and supplied party details. Its output includes documentEn, optional documentZh, blanks and clauseNotes. Read the full document and resolve the blanks with the appropriate reviewer before using it.

Check the defaults: the current action selects PRC governing law for a manufacturer and Delaware for a customer when governingLaw is omitted. Those are software defaults, not a determination for your parties or project. Use terms selected by the responsible reviewer and compare the generated document with that decision. See the NDA input schema.

Keep the agreement record in your existing contract or document system: exact parties, reviewed version, signature status, permitted recipients, file scope and any approval needed for further disclosure. An NDA draft stored in an action does not establish signature or permission to upload a complete CAD assembly. The current API has no dedicated agreement-signature or disclosure-log resource.

Once file sharing is authorized, identify the actual revision and recipient. A local path in an API request is a reference; it does not upload the file or prove the recipient has received it.

5. Turn the reviewed scope into a SOW draft

Use sow_draft with the scope, deliverables, proposed milestones and payment terms that are actually known. A statement of work (SOW) should make the next decision concrete: what is delivered, what evidence shows acceptance, who decides and what remains outside the scope.

maglev actions request PROJECT_ID \
  --input examples/project-scoping/sow.json \
  --idempotency-key example-revision-a-sow-001 --json

Read documentEn and each proposed gate’s exitEvidence. Check that the draft preserves exclusions, unresolved dates and unagreed payment terms. Review any generated commitments before acceptance; requesting the action does not authorize engineering work, payment or production.

The API does not automatically chain these actions. Carry the reviewed decisions from one step into the next request. A new answer or design revision needs an updated brief and a new action request with a new idempotency key; the earlier output remains a record of its original input.

6. Move to the next agreed step

For a quote, prepare the factory selection and RFQ using the authorized scope and file set. For a build, continue with a production-readiness review against its actual revision and acceptance evidence.

Keep the signed agreement, accepted commercial terms and engineering decisions beside the generated plans. The useful handoff is a reviewed package with clear next actions and owners.