How it works

Requirements to results, step by step

Requirements → PRD validation → queued Octave analysis → reports and results. Here is what happens and what you see at every step.

Workflow: requirements, draft PRD, review and validation, queued Octave analysis, resultsRequirementsplain language01Draft PRDAI or rule-based02Review & validateMADETOOL schema03Queued analysisGNU Octave 8.404Resultsreport · CSV · MAT05

Step 1

Describe your requirements

You create a project, pick a supported configuration and write your requirements in plain language.

What you see

A text box, the two supported configurations and a list of what MADETOOL needs (payload, mission, speeds, altitudes, limits, site).

Step 2

Get a draft PRD

The website turns your text into a draft Product Requirements Document in MADETOOL's format. With an AI provider configured this uses AI; otherwise a rule-based extractor finds explicitly stated values. Either way, every extracted value must quote your text, and anything not stated stays TBD.

What you see

A structured, editable table per PRD section with value, unit, reference and attributes; badges showing where each value came from; a list of open questions and unsupported requests.

Step 3

Review and validate

You confirm or correct extracted values and fill the TBD items. Validation follows MADETOOL's own rules (mt_prd_validate) and the capability declarations of each solver module.

What you see

Errors, warnings and notes with the PRD key they refer to; the generated PRD text; a Design button that stays disabled until nothing blocks the run.

Step 4

Click Design - queued analysis

A run is queued for your plan. A separate worker process starts GNU Octave 8.4 on MADETOOL's main.m with the run's own PRD, working folder and output folder. Runs have a time limit and can be cancelled.

What you see

Queued, running, completed or failed status with elapsed time and recent solver output. If the solver is not installed or the worker is offline, the site says so instead of queueing.

Step 5

Read the results

The run page shows the solver status (OK, WARN, INCOMPLETE or FAIL), the stage table, validation and capability messages, the sizing outcome, the compliance summary, the DoD group and key design data.

What you see

The report text, the compliance table and download links for exactly the files the run produced - text report, CSV files and the MAT file - with the PRD checksum and timestamps.

Inside the solver

The stages of main.m

Read, validate and capability check stop the run on input errors. The sizing loop iterates geometry, aerodynamics, drag, propulsion, mission energy, energy storage, loads, structures, mass and stability until MTOW converges.

MADETOOL pipeline stages: read, validate, capabilities, registry, mission, design init, sizing loop, performance, optional trade study, verification, reportread1validate2capabilities3registry4mission5design init6sizing loop7performance8trade (opt.)9verification10report11iterate

Isolation and safety

  • The website never accepts .m files, shell commands or code. The PRD is plain text that MADETOOL parses with regular expressions only.
  • Each run has its own PRD, working and output folders inside the website’s data folder; the MADETOOL project is only read.
  • The solver process gets a minimal environment without any website secrets.

Plans and limits

  • Concurrent runs, queued runs and monthly solver time are limited per plan and checked on the server.
  • A run that cannot start is reported as failed with the reason - never shown as a success.
Plans

Engineering disclaimer. MADETOOL produces conceptual/preliminary design estimates. Results are not validated, certified, or flight-ready and do not replace detailed engineering analysis, testing, or certification. Read the full disclaimer.

How it works | MADETOOL by ALATES