Three applied service areas alongside the core railway practice, delivered with the same working method: senior involvement, evidence over claims, and no subcontracting of the substantive work.
Alongside its railway practice, Efios Rail works in three adjacent fields: LLM and AI agent development for specification analysis and issue discovery in data-rich technical environments; social network analysis for organisational resilience, knowledge bottlenecks and programme coordination; and sensing and LoRaWAN for infrastructure condition monitoring, environmental sensing and asset tracking. The operating model is the same as in the railway practice, every engagement is handled at principal level and the substantive work is not subcontracted.
Twenty years of railway work taught Efios how to handle safety-critical systems: environments where a missed requirement costs months, and where every claim has to be backed by evidence.
Efios now applies that working method in three adjacent fields. The common thread is simple: technology only pays off when the person applying it understands the operation it lands in, and is honest about where it still falls short.
Specification analysis · Issue discovery · ERTMS and digital system environments
Railway digitalisation, ERTMS rollouts, ETCS baseline transitions, digital interlocking programmes, produces a particular kind of documentation environment: hundreds of requirement specifications, test evidence packages, interface control documents, and design records that are interdependent, versioned inconsistently, and never fully read by any one person. This is precisely the kind of problem where LLM-based tooling adds genuine value, and precisely the kind of problem where it must be used carefully.
Efios works on the design and development of AI agent systems applied to specification analysis and issue discovery in data-rich technical environments. Concretely: agents that cross-reference requirement sets to surface contradictions, that identify coverage gaps between a test campaign and the specification it is meant to address, or that trace a design decision across multiple document generations to flag where the rationale has been lost.
Current language models hallucinate. They produce plausible-sounding output that is factually wrong, without reliably signalling uncertainty. In a safety-critical context, a requirement gap analysis for an ERTMS baseline transition, a contradiction check across interface control documents, an undetected hallucination is not a minor inconvenience. It is a programme risk. The correct response is not to avoid the technology, but to architect the system so that model output is always verified against source material, that human domain expertise remains in the loop at the points where correctness is consequential, and that the agent's role is defined as finding candidates for review, not reaching conclusions.
Building that architecture, the prompting, the retrieval layer, the evaluation framework, the human handoff points, is what Efios brings to these engagements.
Organisational resilience · Knowledge flow · Programme coordination
Organisations generate relational data constantly, in communication logs, project structures, procurement chains, and collaboration platforms, and almost never look at it as a network. Social network analysis maps the actual flow of information and influence, rather than the nominal one shown on org charts.
Efios applies network methods to questions of organisational resilience, knowledge bottlenecks, and programme coordination: where single points of failure sit in a stakeholder graph, which teams are structurally isolated, how information actually propagates before a decision is made.
Identify nodes where knowledge or decisions concentrate and where loss of a single actor creates programme risk.
Find teams or stakeholders who are nominally in scope but effectively disconnected from the active information network.
Map how decisions and signals actually travel before they become visible in formal reporting structures.
Infrastructure monitoring · Asset tracking · Operational intelligence
LoRaWAN has made long-range, low-power sensor deployment genuinely practical, but most implementations stop at getting data to a dashboard. Efios approaches sensing as an operational intelligence question: what decisions does the data need to support, what latency and reliability profile does that require, and how does the sensing layer integrate with the rest of the information architecture?
Work spans network planning, sensor selection and placement, gateway infrastructure, and backend integration, for infrastructure condition monitoring, environmental sensing in complex sites, and asset tracking where cellular coverage is unavailable or cost-prohibitive.
Every frontier engagement is handled at principal level. The person who assesses the problem is the person who does the work, not a proxy.
These technologies have real constraints: hallucination, coverage gaps, network reliability. Engagements are designed around those limits, not in spite of them.
Technology choices follow from operational requirements, not the other way around. The question is always what decision the system needs to support.
Every claim the agent makes is traceable to a source passage, and the agent is scoped to find candidates for review, never to close a finding. What the agent never does is author or sign off a safety argument. It narrows where a specialist looks; the specialist still decides.
Agents earn their keep where the corpus is large, stable and internally cross-referenced. They are a poor fit where the corpus is small enough to read properly, where the answer depends on undocumented context, or where being wrong once is unacceptable and there is no cheap way to verify.
Typically three things: who is load-bearing without having the title, which groups are formally in scope but effectively disconnected, and how far a decision has already travelled before it is minuted. Inputs are metadata rather than content, so the analysis does not require reading anyone's messages.
When readings are small, infrequent and needed from places power and cellular do not reach. It is the wrong choice more often than vendors admit: duty-cycle limits and small payloads make it unsuitable for anything resembling streaming, and latency is minutes, not seconds.
A direct conversation is the right starting point. No sales process, just a focused discussion about whether and how these services are relevant to your situation.