45% of design standards are effectively invisible in design reviews.

Mechanical teams are shipping more complex systems than ever, but the way requirements, design intent, and standards are handled hasn’t kept up.

In a survey of 250 engineering leaders at large manufacturing companies, 45% said their design standards and guidelines are not fully documented, kept up to date, and consistently referenced in design reviews. At the same time, 95% said adherence to standards is important or critically important for safety, regulatory compliance, and customer trust.

So the gap is clear:

• Everyone agrees design standards and requirements matter.

• Almost half of them are effectively unusable at the moment decisions are made.

We’ve seen this first-hand across aerospace, medical devices, and industrial hardware:
CAD models change every day, requirements shift weekly, but the “why” behind decisions lags behind in email threads, SharePoint folders, and a few people’s heads.

That is the problem Tandem is built to solve.

The core problem: design intent never lives where the work happens

Most teams have the same stack:

• Requirements in Word/Excel or a dedicated tool

• CAD and PDM/PLM for geometry and versions

• Shared drives, SharePoint, or Confluence for documents

• Slack/Teams/Outlook for discussions and decisions

These systems don’t share one model of “what we decided and why.”

Patterns you see everywhere:

• Requirements are written once, maybe traced into a matrix, then drift out of sync with the real design.

• The feature tree shows what changed, but almost never why a feature exists or which requirement it satisfies.

• Manufacturing, quality, and customer feedback show up in chat, email, and PDFs that never get tied back to specific parts, assemblies, or requirements.

Research in systems and requirements engineering backs this up:

• Many practitioners don’t apply formal standards consistently, even when they consider them important.

• Non-functional requirements (reliability, maintainability, usability) are widely viewed as critical but often go undocumented in practice.

The result:

• Design reviews that rely on tribal knowledge and memory

• Impact analysis that lives in spreadsheets and war rooms

• Engineers who spend months re-deriving reasoning that already happened once

This is not just a tooling problem. It’s a knowledge problem.

Our view: hardware needs a real knowledge layer

Software teams have Git, code review history, issue trackers, and CI logs that capture a lot of intent by default.

Hardware has:

• Files in PDM

• Specs in Word/Excel

• A feature tree in CAD

• Slide decks summarizing “what we decided” for each review

There’s no shared, structured layer:

At Tandem, we call that missing piece the knowledge layer for mechanical design.

A real knowledge layer should:

1. Self-document as you work
   Documentation should be a byproduct of normal work, not a separate task.

2. Connect requirements, models, and conversations
   Requirements, CAD features, tests, risks, and discussions should be first-class nodes in the same graph.

3. Make intent queryable inside existing tools
   You should be able to pull up the “why” directly from CAD, from your requirements view, and from your collaboration tools.

Here’s how we’re building that.

How Tandem’s knowledge layer works

1. Tandem Watch – your design session becomes structured history

Tandem Watch observes CAD sessions and turns raw design actions into structured events:

• Feature creations, edits, suppressions, rollbacks

• Configuration changes and variants

• Mate and constraint updates

• Assembly restructuring and refactors

Each event is enriched with context:

• The part / assembly and specific features involved

• Linked requirement, change request, or issue (when available)

• The conversation or meeting that triggered the change

This stream of events becomes the backbone of your design history.

This is self-documenting workflow in practice:
you don’t go off to “write documentation” - Tandem captures and structures the context created as you work.

2. Requirements Workspace – requirements as a graph, not a static doc

Most requirements live in documents and occasionally in a requirements tool. They’re rarely modeled in a way that matches how engineers think.

In Tandem, requirements are objects in a graph:

• User needs

• System requirements

• Subsystem / component requirements

• Risk and hazard records

• Verification and validation activities

Relationships are modeled explicitly:

• Derives from – user need → system requirement → subsystem requirement

• Allocated to – system / subsystem requirement → specific parts, assemblies, or features

• Verified by – requirement → test case, analysis, or inspection

• Validated by – user need → system-level validation activity

• Mitigated by – risk → risk control requirement → implementation

Because Tandem Watch knows which features and configurations were touched for which reasons, this graph connects directly to real CAD history – not just to filenames or drawing numbers.

So when a requirement changes, you can immediately see:

• The features and assemblies most likely impacted

• The tests and reports that may now be invalid

• The risk controls that need to be revisited

Impact analysis stops being a manual spreadsheet exercise and becomes a live view grounded in how the design actually evolved.

3. Integration layer – stitching together CAD, PDM/PLM, files, and conversations

Design intent is scattered:

• CAD and PDM/PLM

• Document repositories and QMS systems

• Slack, Teams, email, and meeting notes

• Supplier feedback and manufacturing logs

Tandem’s integration layer links these into the same knowledge graph.

For example:

• A comment on a drawing PDF is tied to the exact CAD configuration and the requirement it references.

• A “field issue” thread in Teams is linked to the affected assemblies and the risk record.

• A supplier email about a tolerance stack-up is attached to the relevant design standard and feature set.

Nobody has to switch tools.
Tandem plugs into the systems you already use and connects the knowledge they contain.

Closing

Tandem’s focus is simple:

Make every design decision self-documenting, connected to requirements, and accessible from the tools engineers already use.

That knowledge layer is what lets hardware teams move faster and stay confident in the intent behind every part, assembly, and requirement.