MATRICE

Domain · Engineering

AI for engineering teams.

From the first brief to a checked board, every decision stays traceable to the need behind it, and every check runs on the files your engineers already use.

Engineering is a practice of its own at Matrice. Each discipline gets agents that work on its native files and checks, with engineers making every decision.

See how it worksAll domains

Fig. 01 · The Intercom, our own product, woven from its own model

  • 9needs
  • 15requirements
  • 80parts
  • 0DRC violations
  • PassERC and simulation
An animation of the Intercom, a desktop device Matrice Technologies is designing with the same engineering workflow it sets up for clients, woven from its own model. A knot of light, the problem, lets out one thread, which fans into the product's 9 needs; they split into its requirements, which are strung across like a loom's warp. A shuttle weaves across them, and the cloth compacts into the 70 mm circuit board; the threads of the requirements the board meets are pulled taut onto their parts, the microphone's onto its copper, and the 80 parts settle. Then the board is checked: the rule checks pass over it, the button is pressed and power runs along the copper to the microphone and the red on-air light, the simulation's trace draws, and the light runs back up the thread to the need it keeps and the problem it came from. The ring of 12 lights comes on.
One linked record// 01 / 03

Traceability

Keep intent and execution aligned.

Most engineering teams keep the brief, the requirements, the hazard analysis, the schematic and the test plan in separate files. Change one, and nothing tells you which of the others it just made wrong.

An animation in three parts. First, the Intercom's files lie apart, as separate documents: the brief, a requirements document, a hazard analysis with 3 rated hazards, the schematic, the board layout, an enclosure drawing (an illustration), the firmware's pin map, a test plan and a simulation report. The microphone's supply, /MIC_3V3, is changed in the schematic, and nothing else changes: the requirements, the board layout, the pin map and the simulation report all still say what they said before. Then the same files move into one project record and are linked through the product's model: the brief's "Listen when nobody pressed the button" to need N4 and hazard H1, both to safety goal SG1, SG1 to requirement HW1, and HW1 to the board. Last, the same change is made again. The links from the board to SG1, HW1 and PR5, and the electrical rules check, the design rules check and HW1's simulation that examined it, turn suspect. The checks run again: the electrical rules check passes (run bc836ff5), the design rules check finds 0 violations (run 9ab9276e), and in simulation (run 4f901b54) the microphone's supply falls below 1.62 V 0.26 ms after the button is released, within the 50 ms limit. The path from the brief to the evidence is current again.

We link your documents and design files through one model of the product: its needs, hazards and requirements, and the parts of the design that meet them. The checks your engineers already trust run on every change. A change shows what it affects, and a release waits until the evidence matches the design again. It all stays in your own repositories and native file formats, with nothing new for your team to adopt.

Every role, one model// 02 / 03

The team

An engineering team around one model.

We set up AI agents across systems, safety, electronics, mechanical design, firmware, testing, sourcing and manufacturing. Every role works from the same requirements, design and evidence, so the work stays connected from the first brief to the factory.

The life of a physical product as one loop, with the Intercom's work at each stage. The problem: systems, and a person decides. Needs, hazards, requirements: systems and safety, and a person accepts the risks. Schematic: electronics. Parts and BOM: electronics and sourcing. Footprints: electronics. Layout: electronics and mechanical. Review: systems and safety, and a person approves. Release: systems. Suppliers: sourcing. Manufacturing: manufacturing. Bring-up: electronics, firmware and test. Validation: test and safety. Iteration: electronics and systems. Release for manufacturing: manufacturing and systems. Firmware runs alongside from the needs and requirements to bring-up: architecture, drivers and application, build and flash, tests. The enclosure runs alongside the board's design and joins it at the review. In the middle is the Intercom's one model, which every role reads and writes: 9 needs, 3 hazards, 15 requirements, 8 blocks. The artefacts are the Intercom's own: the brief's first sentence; need N4, hazard H1 rated S1 E4 C3 and safety goal SG1; the schematic around the button; the parts the pin map names; the footprints; the 70 mm, 4-layer board; the checks (electrical rules 0 open, 1 excluded, with its reason; design rules 0 violations); the files at commit 9cb6430; the cost target, under 25 eur to build at 1,000 units; the pin map; and HW1's simulation, where the microphone's supply falls below its threshold 0.26 ms after the button is let go, within 50 ms. The enclosure and the manufacturing panel are drawings. An iteration sends the design back round the loop; the release for manufacturing leaves it, toward the factory.

Your engineers choose where to contribute and what to delegate: bring expertise to a design decision, review the work as it develops, or focus on what the product needs to achieve. The places where a person decides are marked on the loop. Once it has played, hover or tap a stage or a role to see what it reads and writes.

03 / 03 · Audit trail

Turn the lights on whenever you want.

The agents carry out the engineering work around the clock, filing every decision, change and test result in the project record as they go.

Turn the lights on to see it. Trace a component back to its requirement, see why a design decision was made, what was tested, what passed and what still needs verification. The record is built so your engineers, your reviewers and certification bodies can audit the work.

Intercom Evidence for SG1

Drawn from the project record at commit 9cb6430

NeedN4

Know that nothing hears me unless I hold the button, whatever software the box or my computer runs

Stated by the user

HazardH1

The box hears and sends on what the user or someone nearby says while nobody holds the button

S1 E4 C3

Safety goalSG1

Nothing the box's microphone picks up reaches the computer while nobody holds the button; within 50 ms of the button's release the box sends nothing more

Refines N4, mitigates H1. Refined into HW1 and FW1.

RequirementHW1

The microphone is powered through the button's contact, so with the button released it has no power, whatever the firmware does

Refines SG1. Met by the board.

Designboard

The /MIC_3V3 net, from the button contact SW1 to the microphone MK1 and the on-air light D13.

SW1button contactMK1microphoneD13on-air light

Evidence

Electrical rules check, schematic

  • ea481a834d3a70e1 warning at U6 pin 17, not passed
  • intercom#8a31d4a4Exclude the one explained ERC warning: U6's exposed pad on GND
  • bc836ff59cb6430Passed, 0 open, 1 excluded

Design rules check, board layout

  • 9ab9276e9cb6430Passed, 0 violations, 0 unconnected

Simulation of HW1

  • 4f901b54f2839390.26 ms after the button's release, the microphone's supply is below 1.62 V. Limit 50 ms.
50 ms1.62 Vrelease

Files at 9cb6430, SHA-256

  • brief8ac337a76ec7
  • modelb016345edba6
  • schematica6b32ad44180
  • board layoutbce259cf6036
  • pin mapac4fddc99794

Disciplines

One practice, discipline by discipline

  • ElectronicsLive

    Schematics, PCB layout, the bill of materials and the life cycle of every component.

    • ERC and DRC on native KiCad files
    • End-of-life parts
    • Change orders with evidence
    See how it works
  • Mechanical and CADPage in preparation

    Parts, assemblies and the drawings and documents that go with them.

    • CAD models and drawings
    • Design reviews
    • Engineering documentation
    See what's coming
  • SoftwarePage in preparation

    Code, reviews and tests, inside the repositories and tools your developers already use.

    • Code review and tests
    • Bug triage from tickets
    • Documentation kept in sync
    See what's coming
  • Your disciplineTalk to us

    Working in another engineering field? We start every practice from a real team's files and checks.

    • Your file formats
    • Your checks
    • Your review process
    Tell us what you work on

In every discipline

The same three rules

  1. Native files

    Agents open the files your engineers already use. No export step, no copy of the design to keep in sync.

  2. The same checks

    They run the checks your team already trusts, and every result is recorded next to the change.

  3. Engineers decide

    Agents prepare and verify. Design decisions and sign-off stay with your engineers.

Contact

Start with an engineering audit.

We look at your design flow, files and checks, then decide with your engineers what to automate first.

Start a conversationmatricetechnologies.com