Safety trust

Safety Trust

Before starting

Confirm (ask or infer) before running:

• Context — building safety content from scratch / a deal is stalling at safety review / a safety incident occurred?
• Product type — cobot / autonomous robot / industrial machinery / consumer hardware / other? (determines which certifications apply)
• Certifications held — which certifications does the product currently hold? (CE, UL, ISO 10218, ISO/TS 15066, RoHS, OSHA compliance, other?)
• Safety data available — do you have published test data? (force limits, stopping times, payload specs, load capacity, third-party audit results)
• Incident status — has a safety incident occurred? (triggers incident communication protocol)
• Stakeholder blocking the deal — procurement / legal / EHS / insurance / executive? (determines content emphasis)

---

Contract

This skill guarantees:

• Safety content is always data-first, not certification-logo-first
• Every certification produces at least one piece of content (not just a logo on the website)
• Safety page meets the minimum content standard before product goes to market
• Incident communication follows the five-step protocol — no silence
• The output names which stakeholder the content is designed to move, and why

---

Role: Safety Communication Architect. Safety is the highest-leverage trust signal with the stakeholders who block hardware deals — procurement, legal, EHS, and insurance. Teams that treat safety as a legal department problem lose deals to teams that treat it as a marketing asset. A robot that passes technical evaluation but fails the safety review never deploys.

---

Inputs

Required before proceeding:

• Product name and product type
• Certifications currently held (or in progress)
• Available safety test data (published or internal)
• Context: new content build / deal stall / incident response

---

The core principle

THE TRANSPARENCY PARADOX

Publishing safety data is rare in hardware.
Companies that publish it are trusted more than companies that display certification logos.

Why:
  An EHS engineer can evaluate data. They cannot evaluate a logo.
  Procurement can see a certificate number and verify it. They cannot evaluate a claim.
  Insurance underwriters ask for test data, not marketing copy.

The companies that win safety reviews are the ones who answer questions
before they are asked — not the ones who have the most certifications.

This also applies to incidents:
  A company with a documented incident history that they handled transparently
  often scores HIGHER on procurement safety reviews than competitors with no
  documented incidents — because reviewers know incidents happen and they
  evaluate your PROCESS, not your luck.

---

Step 0 — Certification landscape by market

Know what is required for your launch market before designing content. This table is directional — verify current requirements with a legal or regulatory specialist.

REQUIRED CERTIFICATIONS BY MARKET

Market               | Robot / automation hardware        | AI-adjacent hardware
EU                   | CE marking (Machinery Directive /   | CE marking; AI Act compliance
                     | Machinery Regulation 2023);         | if AI component is in a
                     | collaborative robots require        | high-risk category
                     | ISO 10218-1/2 + ISO/TS 15066        |
US                   | No mandatory federal standard for   | FCC for radio emissions;
                     | industrial robots; OSHA defers to   | FDA for medical devices
                     | ANSI/RIA R15.06; UL listing for     |
                     | electrical safety                   |
China                | GB standards; CCC mark for          | MIIT regulations for
                     | electronic products                 | intelligent robots (evolving)
Japan                | PSE mark for electrical safety;     | (PSE applies)
                     | JIS standards                       |
Medical devices      | FDA 510(k) / PMA (US);              | High-risk AI Act category
(global)             | MDR (EU); varies by device class    | in EU if diagnostic
Automotive (global)  | IATF 16949 quality management;      | ISO 26262 functional safety
                     | OEM-specific audits                 | if component is in-vehicle

TIMING RULE:
  Get the certification required for your launch market first.
  Start the process 6–12 months before expected commercial launch.
  Certification timelines are long and non-negotiable — they cannot be
  compressed in the last 60 days before launch.

MULTI-MARKET NOTE:
  If you plan to launch in EU and US simultaneously, start both certification
  processes at the same time. CE and UL/ANSI certification requirements diverge
  enough that sequential processing will delay one market by 3–6 months.

---

Step 1 — Certification-to-content conversion

Every certification produces content. A certification that does not produce content is a cost, not an asset.

CERTIFICATION → CONTENT CONVERSION TABLE

From this certification          Make this content
CE testing completed             "How we designed for CE compliance: the specific
                                  changes we made to meet the Machinery Directive"
ISO 10218 risk assessment        "Our robot risk assessment framework: what we
                                  evaluated, what we changed, and how we validated"
ISO/TS 15066 (collaborative ops) "How we validated collaborative operation safety:
                                  speed and force limits in each operating mode"
OSHA audit or third-party review "Third-party safety audit results: published"
                                  (link to summary document, not just the logo)
Safety test data (force limits,  Data sheet + explainer: "What our safety numbers
stop times, load capacity)        mean in real operating conditions"
                                  Example: "Maximum contact force: 150N. In practice,
                                  this means: [relatable physical comparison]"
CE Declaration of Conformity     Published as a downloadable PDF with certificate
                                  number, issuing body, and expiry date visible

CONTENT FORMAT BY AUDIENCE:
  EHS engineer: numerical test data, standards references, test methodology
  Procurement: certificate numbers, issuing body, expiry dates, download links
  Legal / insurance: third-party audit reports, risk assessment summaries
  Operations manager: "what does this mean for day-to-day operation" explainer
  Executive: one-paragraph safety posture summary with key certifications named

---

Step 2 — Safety page minimum content standard

This standard must be met before product goes to market. No launch without a safety page.

SAFETY PAGE MINIMUM CONTENT CHECKLIST

  [ ] Which certifications the product holds
      Format: Certification name + Standard number + Issuing body + Certificate number + Expiry date
      NOT: a logo grid without details

  [ ] Safety standards the product was designed to meet
      Name the standards, not just "we are compliant"
      Example: "Designed to meet ISO 10218-1:2011 and ISO/TS 15066:2016"

  [ ] Key safety specifications (product-category specific)
      For collaborative robots: maximum contact force (N), stopping time (ms),
      payload limits (kg), operating speed limits
      For industrial machinery: guarding requirements, emergency stop specs,
      hazardous energy lockout provisions
      For consumer hardware: IP rating, operating temperature range, applicable
      electrical safety standards

  [ ] Contact for safety inquiries
      Named contact or dedicated email address
      NOT: "contact us" form that routes to a general inbox
      Response SLA stated: "Safety inquiries are acknowledged within 24 hours"

  [ ] Third-party certification body name
      NOT: "certified" — who certified it?
      Format: "Certified by [body name], certificate [number], valid through [date]"

  [ ] Download link for Declaration of Conformity or equivalent
      PDF, directly accessible without a form or login

ANTI-PATTERN: a safety page that exists only to display logos.
The logos tell a sophisticated buyer nothing they couldn't assume.
The data tells them something they can actually evaluate.

---

Step 3 — Deal stall: safety objection response

Use when a deal is stalling at procurement, legal, EHS, or insurance review.

SAFETY OBJECTION DIAGNOSIS

Objection type 1: "We need to see your certifications"
  Likely cause: standard procurement requirement; not a real blocker
  Response: send the safety page URL + Declaration of Conformity PDF + certificate numbers
  If they ask for more: they have a specific concern — ask what specific standard
  or scenario they need addressed

Objection type 2: "Our EHS team has questions about [specific scenario]"
  Likely cause: real technical concern; they've identified a specific use case
  Response:
  - Ask for the specific scenario in writing
  - Provide specific test data for that scenario (force limits, stopping behavior,
    detection range) — not general certification claims
  - If data doesn't exist for that exact scenario: acknowledge it, propose a
    controlled test at their site, give a timeline

Objection type 3: "We need a third-party safety assessment for our site"
  Likely cause: internal policy requirement; not product-specific
  Response:
  - Confirm which standard or assessment format they require
  - Offer to support the assessment with technical documentation and an
    application engineer on-site
  - If no third-party assessor: name two certified assessors who work with your
    product type; facilitate the connection

Objection type 4: "We had an incident with a [competitor product] and now have concerns"
  Likely cause: procurement and legal are risk-averse after a relevant incident
  Response:
  - Acknowledge the concern directly — do not minimize the incident
  - Provide your incident history transparently (see Step 4 for format)
  - Explain specifically how your product's design addresses the failure mode
    involved in the competitor's incident
  - Offer a supervised demo or site visit to demonstrate the safety behavior

RULE: never respond to a safety objection with general certification claims.
Name the specific data that addresses the specific concern.

---

Step 4 — Incident communication protocol

Use when a safety incident has occurred (or is reported by a customer or third party).

INCIDENT COMMUNICATION — FIVE-STEP PROTOCOL

Step 1: ACKNOWLEDGE FIRST (within 24 hours of becoming aware)
  Acknowledge publicly before the investigation is complete.
  Silence is interpreted as hiding.
  
  Format: "We are aware of a reported [incident description] involving [product].
  We are investigating. We will provide a full update by [specific date].
  Safety inquiry contact: [email/name]."
  
  Do NOT: wait for the full investigation before acknowledging.
  Do NOT: issue a "no comment" response.

Step 2: DESCRIBE THE FAILURE MODE SPECIFICALLY
  When communicating about the incident:
  "The system stopped unexpectedly when [specific condition]" is better than
  "a software issue was identified"
  
  Specific descriptions:
  - Show that you understand what happened
  - Give affected customers information they can act on immediately
  - Prevent speculation from filling the information vacuum

Step 3: DESCRIBE THE INVESTIGATION
  What you found, what you changed, how to verify the fix.
  Include: root cause, corrective action, verification method.
  Exclude: blame attribution, legal disclaimers in place of information.

Step 4: UPDATE AFFECTED CUSTOMERS DIRECTLY
  Every deployed customer hears about a safety incident from you before they
  hear about it elsewhere.
  
  Channel: direct email or call from a named contact (not a system notification)
  Timing: before any public disclosure
  Content: what happened, whether their system is affected, what action to take

Step 5: PUBLISH THE ROOT CAUSE AND FIX
  Publish a summary of the root cause and corrective action publicly.
  Format: technical summary accessible to an EHS engineer.
  
  Include:
  - Specific failure condition
  - Root cause determination
  - Corrective action taken
  - How to verify the fix on an existing deployment
  - Whether a field update / recall / advisory is required

THE TRANSPARENCY PARADOX IN PRACTICE:
  Companies that publish their incident handling process often score higher on
  enterprise procurement safety reviews than competitors with no documented incidents.
  Reviewers know incidents happen. They are evaluating your process.

---

Step 5 — Safety as positioning content

Safety data that lives only on the safety page is underutilized.

SAFETY CONTENT DISTRIBUTION

Surface                  | Content type               | Audience
Safety page              | Full data + certifications | EHS, procurement, legal
Demo (Step 4 in sequence)| Key specs in one sentence  | All
Sales email sequence     | "Safety review package"    | EHS, procurement
Partner enablement       | Safety FAQ for SI partners | Partners fielding objections
LinkedIn / industry media| Certification + explainer  | General industry awareness
                         | "How we designed for CE"   |
Trade press              | Third-party audit results  | Technical community
PR                       | Transparency report        | Media, general public

DIFFERENTIATION PRINCIPLE:
  If your top 3 competitors display certification logos without data,
  publishing data is a competitive differentiator.
  
  Frame: "We publish our safety test data because procurement and EHS engineers
  evaluate data, not logos. Here is what we tested, how we tested it, and what
  it means for your application."

SAFETY AS SALES ACCELERANT (for sales teams):
  The safety review is often the longest step in hardware procurement.
  A "safety review package" (safety page URL + Declaration of Conformity PDF +
  third-party audit summary + relevant test data for the customer's use case)
  handed to the prospect's EHS team at the start of the conversation — not at
  the end — reduces sales cycle by eliminating a reactive step.

---

Output format

## Safety Trust Brief

**Product:** [Name]
**Context:** [New content build / Deal stall / Incident response]
**Certifications held:** [List with numbers and expiry dates]

### Safety page status
  [ ] Certifications with issuing body, number, expiry date
  [ ] Standards designed to meet (named specifically)
  [ ] Key safety specifications (product-appropriate)
  [ ] Safety inquiry contact with SLA
  [ ] Third-party certification body named
  [ ] Declaration of Conformity download link
Overall: [Complete / Missing: list missing items]

### Certification-to-content conversion
| Certification | Content piece | Status |
|---|---|---|
| [Cert name] | [Content type] | [Published / Draft / Planned / Not started] |

### Deal stall response (if applicable)
Objection type: [Which pattern]
Specific concern: [What the stakeholder needs]
Response: [Specific data or action]

### Incident communication (if applicable)
Acknowledgment: [Sent / Not yet — deadline: date]
Failure mode description: [Specific language]
Customer notification: [Sent to N customers / Pending]
Public summary: [Published / Draft / Timeline: date]

---

Brain reads / writes

If a companion brain repo is connected:

Before starting:

• Read knowledge/icp-map.md — ICP segment determines which safety stakeholders are involved in procurement (factory automation buyers always involve EHS; consumer hardware buyers rarely do)
• Read playbooks/messaging.md — safety positioning should be consistent with the product's overall positioning narrative

Brain write (after safety content is produced):

• Write to decisions/: certifications available, content pieces produced, deal stall outcomes addressed

Brain not connected: proceed normally.

---

Anti-patterns

Anti-pattern	Why it fails	Fix
Safety page that only displays logos	EHS engineers evaluate data, not logos; sophisticated buyers see through it	Publish test data, standards names, and certificate numbers alongside logos
Waiting for full investigation before acknowledging an incident	Silence = hiding; speculation fills the vacuum	Acknowledge within 24 hours before investigation is complete
General certification claims in response to specific safety objections	Doesn't address the actual concern; signals you don't understand it	Name the specific test data for the specific scenario they asked about
Treating safety documentation as a legal deliverable	Legal minimum ≠ trust-building content; they serve different audiences	Build safety content for the EHS engineer who reads it, not the legal team that signed off
Not updating affected customers before public disclosure	Customers learn from press or social media before they hear from you	Direct customer notification is Step 4 — it happens before any public statement
Publishing the Declaration of Conformity only behind a form or login	Adds friction for the exact person (EHS engineer) you most want to reach	Direct PDF link, no login required
Treating safety as a one-time launch activity	Product updates, firmware changes, and new applications require safety re-validation	Safety content is maintained on a defined cadence tied to firmware and application updates

---

Benchmarks (2025–2026)

Benchmark	Value	Notes
Safety review as % of total hardware enterprise sales cycle	15–30%	Often the longest single step; safety review package shortens it
EHS review duration (well-prepared documentation)	2–4 weeks	Can be 8–12 weeks without pre-prepared safety package
Customer notification SLA after safety incident	Within 24 hours	After public acknowledgment; direct from named contact
Safety inquiry response SLA (standard)	≤24 hours acknowledgment	Resolution timeline varies by issue complexity
Enterprise procurement: % of deals that include a mandatory safety review	~85% for industrial/manufacturing hardware	Consumer hardware: lower; safety-critical hardware: 100%

---

Related skills

Skill	When to use
hardware-gtm/demo-strategy/SKILL.md	Demo to EHS/safety audience: safety data belongs in the Step 4 numbers
hardware-gtm/launch/SKILL.md	Launch requires safety page to meet minimum content standard before go-live
pmm/positioning/SKILL.md	Safety transparency can be a positioning differentiator if competitors don't publish data
pmm/content-review/SKILL.md	Safety content pieces can be reviewed for clarity and banned patterns

---

Validation criteria

• Safety page meets the six-item minimum content standard
• Every held certification has a corresponding content piece (not just a logo)
• Safety inquiry contact is named with a response SLA
• Declaration of Conformity is accessible as a direct PDF link (no login)
• If incident has occurred: five-step protocol initiated with specific timelines
• Deal stall response names specific data for the specific objection (no generic certification claims)

References & Sources

Tier 1:

• hw-safety-trust-content (growth-skills v1.0, score 7.5/10): certification-to-content conversion, safety page minimum standard, incident transparency five-step protocol, the transparency paradox, certification landscape by market (Step 0)