Rail & InfrastructureTraceability your assessor can follow.
The rail pack sets agents up around SIL, hazards, safety-case claims, independent assessment, configuration baselines and tool qualification. They connect requirements to architecture, software, verification and evidence inside your Azure DevOps project, flag what a change touches, and open the re-review and retest work. Safety and assessment decisions stay with the people who hold them.
No card required. Your data stays in your Azure DevOps tenant.
- EN 50126
- EN 50128
- EN 50129
- EN 50159
- CSM-RA
- ERTMS/ETCS
Two records have to hold at once: the technical one and the assessor's.
A rail programme carries lifecycle evidence across RAMS, hazards, safety requirements, software rigour, independent assessment, configuration baselines, tool classification and qualification, system integration and safety-case claims. Every change has to keep the engineering trace intact and leave the assessor a clear path from claim to evidence. When that work lives in spreadsheets and email, the trace drifts between gates and the gap shows up during assessment.
- 01
Changes outrun the safety case.
A signalling requirement changes in Boards, but the hazard control, test rigour and safety-case claim that depend on it are still marked as reviewed. Nobody sees the gap until the next safety-case review.
- 02
SIL context gets lost downstream.
The SIL sits on the safety requirement, not on the software requirement, the code review or the test. Teams apply the wrong rigour, or argue about it late.
- 03
ISA findings close on paper only.
Assessor findings are logged, then answered by email. Closure evidence is scattered across work items, wiki pages and attachments, so proving closure takes days.
- 04
Baselines drift from as-built.
Configuration baselines, ERTMS/ETCS baseline references and tool evidence fall out of step with what was actually built and tested.
Your rail lifecycle, set up as configuration.
Four layers tell the agents how your programme classifies work, links it, maps it to standards and gates it. You adjust each layer to your own process.
- 01 Classification
Every item knows where it sits.
Railway application and subsystem, hazard and severity, SIL, software and tool class, change significance, configuration baseline, independent assessment status, and ERTMS/ETCS baseline.
- 02 Traceability model
From operational need to acceptance.
Operational need to system requirement, hazard and safety requirement, architecture and software requirement, implementation, verification and validation, safety-case claim and evidence, then acceptance and the operational baseline.
- 03 Standards & frameworks
Mapped to the standards you are assessed against.
EN 50126, EN 50128, EN 50129 and EN 50159, CSM-RA, ERTMS/ETCS and TSI context, Independent Safety Assessment, and tool qualification and classification requirements. Mappings are reviewed by your subject-matter experts.
- 04 Lifecycle gates & evidence
Gates that check their own evidence.
Lifecycle review, hazard and safety requirement review, software phase gates, independent assessment, configuration baseline, integration and test, safety-case review, and authorization and acceptance evidence.
The Rail chain, kept intact.
A changed software requirement breaks the link to its hazard control. The agent flags it, opens re-review, and verifies the link is restored.
- Operational need
- System req
- Hazard / safety
- Software req
- Implementation
- V&V
- Safety-case claim
- Acceptance
Six rail workflows to hand over first.
Each one runs the same controlled sequence: trigger, context, decide, act, approve, verify, record. Output lands on the work item, test or wiki page your team already uses.
SIL-aware requirements and traceability
Formalize safety requirements, carry the SIL down to software requirements, code and tests, and keep every link from requirement to evidence current.
Requirements Engineer Agent
Hazard and safety-case support
Maintain hazards, controls, claims, arguments, evidence, findings and residual risk as linked items, and flag any claim whose evidence has changed.
Compliance Officer Agent
Software and tool gate
Check development rigour, reviews, verification, and tool classification and qualification evidence before a software phase gate is passed.
QA Engineer Agent
Configuration and change control
Maintain baselines, change significance, impact, approvals and tests, and keep the as-built record consistent with what was approved.
DevOps Engineer Agent
ERTMS/ETCS conformity
Map requirements and tests to the applicable ERTMS/ETCS baseline, and track interface and conformance evidence against it.
Business Analyst Agent
ISA and acceptance readiness
Assemble the review pack, findings, closure evidence and approvals, and report safety-case readiness before the assessor or acceptance authority sees it.
Release Manager Agent
A rail advisor, plus a full persona team.
The library has a Rail Infrastructure section with 13 role-based persona agents grounded in EN 50126 RAMS, EN 50128 software, EN 50129 signalling safety and EN 50159 safe transmission, including interlocking, train detection, ETCS/ERTMS and CBTC architecture. Add one with Use. Compatibility Alignment maps it to your process template before it is saved.
Requirements Engineer Agent
Carries SIL context from safety requirements to software, code and tests, and runs suspect-link checks when one changes.
GovernCompliance Officer Agent
Keeps hazards, controls, claims and evidence linked, and drafts the trace report your safety-case review starts from.
TestQA Engineer Agent
Checks verification rigour against the SIL and records per-step test results on the linked test cases.
ReleaseRelease Manager Agent
Assembles the ISA and acceptance pack: findings, closure evidence, baselines and the named approvals still open.
Rail roles in the catalog
- Rail Infrastructure Advisor
- Product Owner
- Business Analyst
- Systems Architect
- Compliance & Risk Officer
- Requirements Engineer
A signalling requirement changes. Here is what follows.
A signalling software requirement is updated in Boards, and the condition on the advisor matches. It traces the change to the hazard controls, SIL context, architecture, code, test rigour, tool evidence, interfaces, the ERTMS/ETCS baseline, open assessor findings, the configuration baseline and the safety-case evidence that depend on it. It marks those links as suspect, creates re-review and retest tasks for the named owners, and pauses at a checkpoint. When the work is done, it verifies closure on each item and writes the run record to Job Explorer.
run started · REQ-207 materially updated
tracing: 2 hazards · SIL 4 · 3 PRs · 6 tests
ETCS baseline ref · 1 open ISA finding
re-review and retest tasks drafted
checkpoint · awaiting safety engineer
record · run history in Job Explorer
- ✓ Hazard controls linked
- ✓ SIL carried to software req
- ! Test rigour matches SIL
- ✓ Tool evidence current
- ! Safety-case claim reviewed
The agent keeps the record. Your authorities decide.
Safety, systems, software, verification, configuration, ISA, operator and acceptance authorities stay responsible for SIL allocation, the safety case, independence, assessment and authorization. The agent prepares, checks and links. With Required Approval on, any step with side effects pauses and opens a task for a named approver, who can answer, attach files, and approve, edit or reject. Every decision is recorded against the run.
[ Trusted by Microsoft and industry leaders ]
Rail and infrastructure questions.
It can maintain source-linked claims and evidence, and prepare drafts for review. Authorized safety and assessment personnel own the argument and the conclusion.
No. It supports classification, evidence collection and workflow checks. Tool qualification decisions and evidence go through your responsible process and assessor review.
Yes, once you configure the specific baseline. Version, applicability, licensing and conformance evidence remain under your control, and the mapping is reviewed by your experts.
Only where you want it. Conditional triggers combine field, operator and value rows with AND/OR logic, per work item type, so the advisor runs on safety requirements that change and spends no credits on the rest.
Yes. With Bring Your Own Data, agents retrieve from your uploaded documents, Azure DevOps queries and wiki pages during the run, so findings use your gate criteria and terminology.
No. Agents run inside your Azure DevOps environment with no separate portal or login, and your project data is not used to train models.
Nothing extra. Every plan includes the full catalog and all 15 industry packs. Credits cost $0.01 each, pooled across your organization with no per-user fees. A rule-based Execution Agent run is a flat 4 credits.
Bring one signalling change to the demo.
Start a free trial with 2,000 credits, no card required. Or book a 30-minute demo with a real requirement, hazard, change or ISA finding, and watch the classification, trace, approval point and run record live.
