10xAnd
Scoping review

Develop 10x

A submission-ready Class II DHF in 6 weeks.

Design controls documented alongside your engineers instead of reconstructed after them — to your SOPs, with named human reviewers on every document.

Send me the one-pager Request a scoping review
10X-SVC-DEVELOP REV B
What
DHF buildout sprint
Price
Fixed by scope
When
6 weeks from kickoff

AI-drafted · evidence-cited · human-reviewed

Why this holds up

01

Concept through 510(k), not one slice of it

The alliance has run the full design-control lifecycle — design inputs through design transfer — on Class II programs, across device development, regulatory affairs, and design assurance.

02

Drafted to your SOPs, reviewed by named people

Documents are generated into your templates and your numbering scheme, so they enter your quality system as native artefacts. Every document carries a named human reviewer who signed it before delivery.

03

Traceability from day one

The trace matrix is the working document, not the deliverable written last. Inputs, outputs, verification, validation, and risk controls are linked as they are created, which is the only time linking them is cheap.

How it works

  1. DEV-01

    Kickoff

    We take your design inputs — however rough — your SOPs and templates, your risk file if one exists, and the intended-use statement. Half a day with your engineers.

  2. DEV-02

    Structure

    The DHF index and trace matrix are stood up first, so every subsequent document has a place and a link before it is written.

  3. DEV-03

    Build in weekly cycles

    Documents are drafted, reviewed by a named human, and returned to you weekly. You review as we go; nothing is saved for a single delivery at week six.

  4. DEV-04

    Handover

    The complete file, the trace matrix, the review record, and a gap list of anything that depends on test data you do not have yet.

What the work looks like

The design-control V-model with AI-assisted documentation legs The left leg descends from user needs through design inputs and design outputs to build. The right leg ascends from build through verification and validation to design transfer. Horizontal traces link each left-leg stage to the right-leg stage that tests it. The documentation work on both legs is AI-assisted with named human review; the engineering work in the middle stays with the client's team. User needs intended use Design inputs requirements Design outputs specs · drawings Build your engineers Verification protocols Validation plan · records Design transfer DHF complete trace trace trace AI-drafted, named human reviewer your team, not ours
FIG. 1 The V-model, with AI-assist badges on the documentation legs. The engineering legs are yours; we do not design your device.

The tool behind this line

FMEA Forge

Design preview

Drafts the risk file from a curated harm library rather than from free generation, and leaves severity blank wherever a human has to set it.

A rendered preview of the intended interface. Not running software.

A preview of FMEA Forge. A readiness ring shows 31 for a synthetic device risk file: 8 failure modes drafted, 3 severities withheld, 0 signed. The device decomposes into functions and components, with harms drawn from a versioned library rather than generated. Eight rows of failure modes are drafted, and three severity cells are deliberately left blank with the note that a model may not score patient harm. A red-flagged item shows severity tied to patient harm being set by a named person. The review gate blocks export until every row carries a named disposition, then turns green and the risk file exports with its review record attached, handing TestForge its input.

Watch it run 1:11

A rendered preview over a synthetic device with fictional harms and fictional reviewers.

No audio track · every line is captioned on screen · nothing is fetched until you press play

Transcript (14 lines)
  1. 0:00 Risk files are the gap we find most often.
  2. 0:04 Watch one drafted in hours, then signed line by line.
  3. 0:09 One number: how much of the risk file is finished?
  4. 0:14 This one just failed its risk section.
  5. 0:20 Harms come from a curated library. Nothing is invented.
  6. 0:26 Eight rows, each scored for occurrence and detection.
  7. 0:32 Three severity cells are left blank on purpose.
  8. 0:35 Severity tied to patient harm? The tool won't score it.
  9. 0:43 A person types that number. Their name goes on the row.
  10. 0:47 Nothing exports until every row has a reviewer's name.
  11. 0:51 Every row signed off. The light goes green.
  12. 0:55 Worksheets, a risk memo, and the file TestForge reads next.
  13. 1:00 Risk file drafting. Fixed scope, quoted in 24 hours.
  14. 1:05 Drafted by machine. Signed by a person.
An FMEA Forge draft worksheet with eight failure modes for a synthetic catheter — occlusion of fluid path, distal tip fracture, luer disconnect, coating delamination, marker band migration, hub crack under torque, lumen contamination and coating friction rise — each tied to a harm and a component. Five rows carry a numeric severity; three carry a HUMAN REVIEW chip instead. A line below reads: 3 of 8 severities are left blank on purpose, a model may not score patient harm.
The blank cells are the design. Occurrence and detection are drafted; any severity tied to patient harm is left for a person.
A red-flagged FMEA Forge row, distal tip fracture, opened for review. The model draft shows occurrence two and detection three with severity withheld, and cites the harm library entry it came from. A reviewer queue shows three of three severities set by a named human, each with a severity value, a fictional reviewer name and a date. A line reads: a red-flagged row is never cleared by a bulk action.
A withheld severity is filled in by a named person, and the name stays attached to the row.

TOOL-02 Synthetic device, fictional harms and reviewers. The blank severity cells are the point: the model drafts the row, and a person sets any severity tied to patient harm.

The offer

The pilot engagement

This is a new service line and we are pricing it to learn: a fixed price set at the scoping review — one Class II device, one intended use — with the scope written into the SOW so "fixed" means fixed.

Intake is limited. A six-week buildout is only six weeks if the named reviewers have the room to run it, so we take a small number concurrently. If your programme is bigger than one device and one intended use, we say so at the review rather than after.

Six weeks from kickoff to handover. The sprint documents design controls; it does not perform your verification testing. That is a separate line, and the two are designed to hand off cleanly.

What you receive

  • A Class II design history file in your templates: design plan, inputs, outputs, reviews, verification and validation plans, and design transfer records.
  • A live trace matrix linking inputs to outputs, verification, validation, and risk controls.
  • A risk management file structured to ISO 14971, populated with your hazards and controls.
  • A gap list naming every element that is blocked on test data or supplier information, so nothing is quietly marked complete.
  • The human-review record (below).

What the human-review record contains

  • The named reviewer and date for every document delivered.
  • Every AI-drafted section that was materially rewritten on review.
  • Source references for each design input we did not receive directly from you.
  • Decisions we escalated to you rather than resolving ourselves, and what you decided.
Get the one-pager Request a scoping review
10X-SVC-DEVELOP REV B
What
DHF buildout sprint
Price
Fixed by scope
When
6 weeks from kickoff

AI-drafted · evidence-cited · human-reviewed

Limited intake

Get the DHF buildout one-pager

What we need at kickoff, the six-week cadence, and where your engineers are in the loop.

This reaches us as an email and we reply to it — we are not adding you to a mailing list, because we do not run one yet. See the privacy policy.

Questions we get

What do we need to have ready at kickoff?

Design inputs in whatever form they exist — a requirements spreadsheet, a marketing requirements document, or engineers who can answer questions for half a day. Your SOPs and document templates. An intended-use statement. Your risk file if you have one. If your inputs are not yet a document, drafting them is the first week of the sprint, not a blocker.

What does "submission-ready" promise, and what does it not?

It promises a file whose design-control documentation is complete, internally consistent, traceable, and formatted to your quality system, so it can be assembled into a submission without reconstruction. It does not promise clearance, and no one can. It also does not manufacture test data: sections that depend on verification results you have not generated yet are delivered with the data field left open and flagged on the gap list.

How does verification testing fit in?

The sprint produces the verification plan and the protocol structure; executing the testing is a separate engagement. If you want the two joined, the V&V 10x line runs the readiness scan against the plan this sprint produces.

Will the documents fit our SOPs and numbering?

Yes — that is the point of taking your templates at kickoff. Documents are generated into your formats with your numbering scheme and approval blocks, so they enter your eQMS as native artefacts rather than as PDFs somebody has to retype.

Who actually reviews the AI-drafted documents?

A named engineer or RA/QA reviewer, identified per document in the review record, who signs before the document reaches you. AI drafts and maintains consistency across the file; humans make the judgement calls and own the signature.

What if our device turns out not to be Class II?

We say so at kickoff, before pricing. Classification is part of the first conversation — a fixed price on the wrong pathway is worth nothing to either of us.

Other ways we 10x device programs