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.
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.
The operating model is the same as in the railway practice. You work with a senior consultant, the substantive work is not subcontracted, and you get a straight answer on what is technically sound and what is hype.
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, and they do so 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. Expertise does not become less necessary when agents are present — it becomes the thing that determines whether the agent's output is safe to act on.
Building that architecture — the prompting, the retrieval layer, the evaluation framework, the human handoff points — is what Efios brings to these engagements.
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. The work has direct application in large programme environments, community-of-practice design, and post-merger integration analysis.
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. Application domains include infrastructure condition monitoring, environmental sensing in complex sites, and asset tracking in environments 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.
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.