It reads the statement of work
Program, customer and software scope come from the customer's own document. Nothing is invented. Where the customer has not decided, DAI-SE writes the decision they have to make instead of guessing.
What this video demonstrates
The film has no narration. It carries its message in on-screen captions and music. This is that text, in order.
Opening. From LHP Engineering Solutions. DAI-SE. Digital AI Specialized Engineer. 25+ years of LHP safety-engineering work, calibrated into a validated skills library, and the platform that runs it. Engineering for safety-critical vehicle systems.
The program. 400 volts. 96 cells in series. Software between them and a fire. The customer's ask is the BMS application software. Not the hardware, which is sourced separately. This is how that software gets engineered.
Stage 1. Definition. A new program. The customer's statement of work is the starting point. DAI-SE loads LHP's validated skills for the stage: ISO 26262 item definition, interface control, system context. It plans before it writes, and sets an eleven-point pass bar for itself. It reads the statement of work. Program, customer, software scope. Nothing invented. Where the customer has not decided, it does not guess. It writes the decision they have to make. The item boundary. Every interface. Every external dependency.
Stage 2. Decomposition. The system decomposed into functions: state determination, battery control, fault management. Change it on the fly, in plain language. It edits the model, not a picture. Another layer of subfunctions. Seconds, not another workshop.
Requirements. Author the system requirement specification. Then 226 system requirements, each one traced back to the element it came from.
Stage 3. Architecture. System architecture. Every interface the customer has not specified is marked TBD, not invented. Then the software design: 26 components across four layers. Hardware abstraction, basic software, application, safety supervisor. Operating modes as a state machine: precharge, propulsion, charging, degraded, fault shutdown. Same architecture, now as models. A SysML v2 structure model and an OPM conceptual model, both from the same source. Software requirements. A verification test specification, each test linked to the requirement it verifies.
The gate review. Sixteen artifacts, filed by lifecycle stage, every one traceable. Then the review. Ask it whether the work is ready to move. It reads the whole project against the gate criteria. Example finding: first software delivery is due the same week as the requirements review, six weeks before the architecture review. Acceptance is the agreed test suite. There is no test suite. Gate recommendation: Hold. Six gates. Six holds. Every one cited to a clause.
Into the ALM. And it lands where the program lives: your ALM. Here that is Jama. The same mapping works for any tool with item types and trace links. It reads the ALM's item types and proposes the mapping, with its reasoning for each rule. Then it pushes: every requirement as its own item. 226 requirements in the ALM. Individual items. Trace links intact.
Into the development toolchain. DAI-SE is also an MCP server. Point any agent harness at it, GitHub Copilot, Claude Code, Codex, and it gets LHP's validated skills library and the program's artifacts. Connect the skills library to your repository. Link Jira so stories flow back. Assign a story to a coding agent. Through MCP it picks up the skills, the requirements, the interface spec and the test cases it needs, and develops against them. The pull request cites the requirements it implements, the interface it honors and the tests that verify it, traced back to the story in Jira.
Close. One session. Sixteen artifacts. 226 traced requirements in your ALM. And an honest list of what is still open.
16artifacts, filed by lifecycle stage
226system requirements, each traced
6gates reviewed, every hold cited
25years of LHP safety engineering
One session, on a battery management system program, from the customer's statement of work to requirements in Jama.
Inside DAI-SE
Sixteen artifacts, filed by lifecycle stage, every one traceable
Each stage feeds the next as context, so the chain holds from the statement of work through to test cases.
Item definition and decomposition
An ISO 26262 item definition with the item boundary, every interface and every external dependency. Then the system decomposed into functions such as state determination, battery control and fault management, with another layer of subfunctions added in seconds.
Requirements
A system requirements specification with every requirement traced back to the element it came from. In the walkthrough, 226 of them.
Architecture, as models
System architecture with unspecified interfaces marked TBD. Software design across four layers. Operating modes as a state machine. The same architecture expressed as a SysML v2 structure model and an OPM conceptual model from one source.
Verification
Software requirements and a verification test specification, each test linked to the requirement it verifies.
Diagrams are generated as models rather than pictures, which is what makes them editable in plain language and portable into MBSE tooling.
A tool that only ever says yes is not governance
Ask DAI-SE whether the work is ready to move. It reads the whole program against the gate criteria, every artifact and every clause of the statement of work, and comes back with a recommendation and the clause it is citing.
In the walkthrough it found that first software delivery was due the same week as the requirements review, six weeks before the architecture review, with acceptance defined as "the agreed test suite" when no test suite existed. Six gates, six holds, each one cited.
It drafts the work, then tells you honestly whether the work is ready.
Built to be governed, not just prompted
Skills carry a status
Engineering skills are catalogued and marked validated or draft, so a program draws on methods that have been reviewed rather than whatever the model improvises.
Workflows encode your process
Stages, gates, work products, playbooks and the skills available at each stage are configured per workflow, including V-model layouts.
Access is scoped
Customers, projects, groups, users and skill packages are managed separately, so each team sees only what it should.
Skills are packaged by role
A package maps a set of skills to a group, so an engineer gets exactly the set their role needs.
Traceability top to bottom
With an audit and evidence record behind it.
The engineer stays in the loop by design
DAI-SE plans, drafts, checks itself against a defined pass bar, and recommends. A person reviews and approves.
Into your ALM, and into your development toolchain
Your ALM
DAI-SE reads the ALM's item types and proposes the mapping, with its reasoning for each rule. Then it pushes every requirement as its own item, trace links intact. The walkthrough shows 226 requirements landing in Jama as individual items. The same mapping approach works for any ALM with item types and trace links.
Your documentation
Connect a wiki or documentation space and the platform works from your own material rather than generic sources.
Your development toolchain
DAI-SE is also an MCP server. Point an agent harness at it, such as GitHub Copilot, Claude Code or Codex, and the agent gets the validated skills library along with the program's requirements, interface specification and test cases. Link Jira so stories flow back. Assign a story to a coding agent and it develops against those artifacts, and the pull request cites the requirements it implements, the interface it honors and the tests that verify it.
From the customer's statement of work to a pull request, with the thread intact the whole way.
Three phases, each with its own decision point
Proof of concept: prove and prioritize
A scoped pilot on your work products, measured by the reduction in expert effort needed to produce an approved deliverable.
Contract to hire: specialize and qualify
DAI-SE is tuned to your processes, templates and review requirements, then qualified against the work products you care about.
Operate and scale
AI-native services, enterprise license, or a hybrid of the two.
Frequently asked questions
What is DAI-SE?
DAI-SE stands for Digital AI Specialized Engineer. It is a governed AI engineering platform from LHP Engineering Solutions that drafts traceable engineering work products from a customer's statement of work, including ISO 26262 item definitions, functional decomposition, system requirements specifications, system and software architecture, SysML v2 and OPM models, and verification test specifications, with LHP's validated engineering skills built in.
What can DAI-SE produce today?
In a single session it produces sixteen artifacts filed by lifecycle stage: the item definition, functional decomposition, a system requirements specification with every requirement traced to its source element, system and software architecture across four layers, operating modes as a state machine, SysML v2 and OPM models, software requirements, and a verification test specification with each test linked to the requirement it verifies.
Does DAI-SE replace engineers?
No. DAI-SE plans, drafts, checks itself against a defined pass bar, and recommends. An engineer reviews and approves. At a gate review it will recommend a hold and cite the clause behind it, which is only useful because a person makes the final call.
Does DAI-SE perform functional safety analysis such as HARA?
No. DAI-SE is focused on systems engineering work products. Its outputs follow LHP's ISO 26262-aligned internal templates, which means the work sits inside a safety-relevant process, but DAI-SE does not perform hazard analysis or derive safety goals. LHP provides functional safety services separately.
Does DAI-SE connect to our requirements management tool?
Yes. DAI-SE reads your ALM's item types, proposes a mapping with its reasoning for each rule, and pushes every requirement as its own item with trace links intact. Demonstrated with Jama, and the same approach works for any ALM with item types and trace links.
Does DAI-SE work with coding agents and our repository?
Yes. DAI-SE runs as an MCP server, so an agent harness such as GitHub Copilot, Claude Code, or Codex can pick up the validated skills library along with the program's requirements, interface specification, and test cases, and develop against them. Pull requests cite the requirements they implement and the tests that verify them.
What happens when the customer has not decided something?
DAI-SE marks the interface or parameter TBD and writes the decision that has to be made. It does not invent a value to fill the gap.
How is our data kept separate from other customers?
Work is organized into customers, projects and groups, and access to skills and work products is managed through packages mapped to those groups.
How does an engagement start?
With a scoped proof of concept on your own work products, measured by the reduction in expert effort required to produce an approved deliverable. From there, engagements move to specialization and qualification, then to operating at scale.
Who builds and supports DAI-SE?
LHP Engineering Solutions, which has worked in safety-critical and mission-critical embedded systems for 25 years. DAI-SE is built by LHP solution architects and backed by LHP's engineering teams.
© 2026 LHP, Inc.