What you are actually buying

You have a concept, an architecture or a safety case and you need it examined by someone who was not in the room when it was written. I review what exists, name what will not hold, and say so in a document you can put in front of your own management or your customer. Typical reasons to call: a safety concept that has to pass an external assessment, an architecture decision nobody wants to own, a supplier deliverable you suspect but cannot yet disprove, or a process that passes audits and still produces defects.

• Architecture and concept reviews
• ISO 26262 safety concept and work-product assessment
• Gap analysis against a standard or a customer specification
• Written findings with severity and a recommended action

What you receive — A written report: what was examined, what was found, how serious each finding is, and what to do about it.

You hand over a scope and a specification; I hand back the agreed work products, produced in your templates, in your tool environment and through your release gates. Acceptance criteria are written before work starts, so handover is a check against a list rather than a negotiation. This is the usual shape when an internal team is at capacity, when a workstream needs to run in parallel, or when a programme needs a capability it does not want to hire permanently.

• Requirements decomposition, specification and traceability
• Behavioural models in Matlab, Simulink, Stateflow and Simscape
• Safety analyses and the work products that go with them
• Verification evidence and documentation that survives assessment

What you receive — The agreed work products, in your templates and your toolchain, with the traceability and verification evidence that makes them acceptable.

Rather than adding one more pair of hands, this puts a lead on a workstream: breaking scope into packages, planning against your milestones, reviewing the work of the engineers on it, carrying the technical decisions, and escalating early enough that the decision is still cheap. I have led safety teams and a cluster development team on manufacturer programmes, working under contract to the supplier delivering them, which is the structure most of this industry actually runs on.

• Technical lead for a workstream or a discipline
• Planning and progress against your programme milestones
• Review and guidance of the engineers in the stream
• Interface management towards the customer and other suppliers

What you receive — A workstream that reports in your format, hits your gates, and whose status you can trust without re-checking it.

A product sold into the European Union has to satisfy requirements its original market may never have imposed. I identify which apply to your product and your role in the chain, translate them into engineering requirements your team can actually implement, and build the evidence a conformity assessment will ask for. The common case is a manufacturer or supplier outside the EU, or one entering a regulated segment for the first time, who knows the destination but not the route.

• Determining which requirements apply, and to whom in the chain
• Translating regulation into verifiable engineering requirements
• Functional safety evidence to ISO 26262
• Technical documentation structured for conformity assessment

What you receive — A requirement set traced to its legal or normative source, and the technical documentation that demonstrates each one is met.