What happens when AI reads a requirements specification? A report from railway engineering

Introduction

What actually happens when you give an AI system a specification with 800 technical requirements and tell it: „Assess this“? The answer is neither the science-fiction vision of a fully automated bid machine nor the cynical answer „nothing useful“. Reality lies somewhere in between, and it is more nuanced than most AI vendors' marketing claims suggest.

This article describes, step by step, what happens when an AI system processes a real railway-industry specification. It is based on experience with real tender documents, including the points where the technology works and those where it fails.

The question is not academic. According to the Loopio 2025 RFP Response Trends & Benchmarks Report 68% of proposal teams across industries already use generative AI, double the 34% in 2023. The rail industry is still at an early stage, although specialist platforms such as Tendric address this exact use case. The annual NLP4RE workshop (Natural Language Processing for Requirements Engineering) also shows that automating requirements analysis with NLP has long since moved beyond a niche application.

What does AI see when it opens a specification?

From an AI system's perspective, a specification is first of all a document: an Excel file with eight worksheets (LH1 to LH8), thousands of rows and a dozen columns. Or a PDF. Or, ideally, a structured data set in ReqIF format (Requirements Interchange Format), the OMG standard for exchanging requirements across tools. It originated in the automotive industry and is increasingly used in rail as well.

Before it can process any content, the system must solve three basic tasks:

1. Structure detection: Which rows are requirements, which are section headings, and which are blank rows or comments? The VDB requirements-management guide recommends a standard attribute structure for specifications. In practice, documents often diverge substantially from it.
2. Field extraction: Where is the requirement ID, the text, the binding level (must/should/optional), and the standards reference? The international ISO/IEC/IEEE 29148:2018 standard defines the attributes a requirement should have, but railway customers rarely follow it explicitly.
3. Cleaning: Merged cells, line breaks in the middle of text, Unicode special characters (‰ vs. %), different date formats, and semantically relevant cell formatting such as colours and bold type, which disappear in a plain-text export.

This preprocessing sounds trivial, but it is not. Every customer structures its specification differently. Column order varies, section headings sit in the same column as requirement text, and some customers use colours or formatting as semantic information that is lost during import. The field of document parsing describes this exact problem: documents are „visually rich text data“. Their meaning comes not only from the text, but also from layout, typeface, table structure and visual elements.

Phase 1: Requirement extraction

Extracting individual requirements from the raw document is the first and most critical step. Errors here propagate through every subsequent processing step. Neither good classification nor good routing can make up for flawed extraction.

Extraction involves several sub-steps, each with its own challenges:

• ID detection: The typical X.35.YYYY.ZZ format is identified through pattern matching. The hit rate is high as long as the customer uses a consistent ID scheme. Deviating formats are more difficult: some customers use hierarchical IDs (3.2.1.4), others use sequential numbers (REQ-0412), and others dispense with formal IDs entirely and use row numbers instead.
• Binding-level detection:„must“, „should“, „may“, „is to“ and „has to“ are recognised as indicators of binding force. This follows the distinction between mandatory and optional wording established in the INCOSE framework . Context-dependent wording is harder, for example „should where possible“ (does that mean should or may?). The same applies to passive wording: „Compliance with the standard is assumed“ contains no explicit „must“, but is clearly mandatory.
• Standards-reference extraction:Identification of standards such as „DIN EN 45545-2:2020+A1:2023“, including version number and amendments. Here too, hit rates are high for standardised notation. But customers sometimes write „in accordance with the fire-safety standard“ without a specific standard number, or refer to the „current version“ of a standard, which may be a different version at contract award than at bid submission.
• Contextual requirement boundaries:Where does one requirement end and the next begin? In free-text documents, one paragraph can contain several implicit requirements: „The vehicle must be able to operate on route class D4 while complying with the TSI Noise limits.“ Technically, these are two independent requirements (axle load and noise) packed into one sentence.

Phase 2: Classification proposals

After extraction, the content work begins: every requirement is matched against the internal knowledge base. In practice, this is now typically handled through a RAG architecture (Retrieval-Augmented Generation): the system searches product data sheets, manufacturer specifications and standards registers for the most relevant passages, passes them to a language model together with the requirement, and receives a classification proposal: OK, OKB, NOK, OKM or R.

Why RAG? Rather than letting a general language model „answer freely“ (which leads to hallucinations), it is restricted to specific source documents. It can access only information that is actually present in the knowledge base and must substantiate its answer with source references. That reduces hallucinations. It does not eliminate them.

The quality of these proposals varies greatly by requirement type:

Estimated accuracy of AI first-pass classification by requirement type (a qualitative assessment based on practical experience, not a benchmark). Current research on automatic requirements classification using NLP shows similar patterns: F1 scores of 0.73–0.84 depending on the method ( Nature Scientific Reports, 2024).

Where it works well

Parametric requirements are the sweet spot: „Maximum speed at least 100 km/h“ is matched against the product data sheet (our value: 100 km/h), the comparison logic is applied (≥ 100 → met), and the result is a substantiated „OK“ with a source reference. This works because the requirement is unambiguously quantitative, the comparison operation is clear (≥, ≤, =) and the source data is machine-readable.

Matching works similarly well for standards requirements when the internal standards register is maintained: AI identifies the standards reference in the requirement text, looks up the compliance status in the register and returns a classification with the certificate number.

Where it gets difficult

Qualitative requirements and novel wording are the weak point. If a requirement says, „The bidder must submit a maintenance concept that covers the vehicle lifecycle over 30 years,“ AI can:

• Identify that it concerns maintenance (correct)
• Assign the „maintenance“ subsystem area (correct)
• Establish the RAMS link, namely that the requirement concerns the maintainability dimension within the meaning of EN 50126 (RAMS) (correct)
• But not assess whether the company has or can create such a concept (that depends on internal knowledge, which is rarely documented in full)

In such cases, „R“ (query required) is the most honest classification. A good AI system should propose exactly that instead of hallucinating an unsupported „OK“. Research on LLM hallucinations describes the problem: language models „learn to guess confidently instead of expressing calibrated uncertainty.“ In requirements classification, that is dangerous because a false „OK“ has direct contractual consequences.

Source: CONTACT Software, Bummelzug zum Anforderungsmanagement. This quotation is from 2014. Requirements density has increased further since then. Current vehicle tenders regularly contain 1,500–3,000 requirements across all sub-specifications.

Phase 3: Recognising and linking standards

In practice, automatic standards recognition delivers the greatest time savings. A typical rolling-stock specification refers, directly and indirectly, to a three-digit number of standards. At European level, the rail standards ecosystem is defined by the ERA (European Union Agency for Railways) through the Technical Specifications for Interoperability (TSIs) and translated into harmonised European standards by CEN/CENELEC.

For a supplier, that means that when a specification requires „EN 45545-2“ (fire protection), it must know not just the status of that one standard, but also:

• The associated TSI SRT (Safety in Railway Tunnels), which defines the regulatory framework
• The test methods in EN 45545-1 (general requirements)
• The material classifications under EN 45545-2 (fire behaviour)
• Product-specific certifications and their validity periods

AI can make these links visible in four steps:

The DIN Standards Committee for Railway Engineering and Rolling Stock (FSF) coordinates the development and national implementation of rail standards. The resulting standards landscape includes around 50–60 relevant standards for rolling stock. As a structured catalogue, it is manageable once it has been captured and maintained. The challenge is its dynamism: standards are revised, amendments are published, and TSIs are updated. In 2025 alone, the ERA published several updated TSI specifications , including the new TSI Telematics, which enters into force on 2 March 2026 and defines data-quality and cybersecurity requirements for rail transport for the first time.

Phase 4: Expert-routing proposals

Based on the identified topic and standards references, AI can propose which specialist department should be responsible for each requirement. According to the Loopio 2025 RFP Response Trends Report , 48% of proposal teams across industries report difficulties collaborating with subject-matter experts. Automated routing can absorb at least some of this work.

The routing problem is pronounced in the rail industry. A specification for a mainline vehicle covers 10–15 different subsystems, from carbody, traction and braking to passenger information and maintenance documentation. The responsible specialists sit in different departments, sometimes at different locations. Without structured routing, the bid manager spends a substantial share of their time assigning requirements to the right people by hand.

How AI works technically: RAG and embedding-based search

For readers with a technical background, it is worth looking under the hood. The basic principle of modern AI systems for processing specifications is a Retrieval-Augmented Generation (RAG) architecture, which combines two components:

1. Retrieval (search):The requirement is converted into a numerical vector (embedding) and matched against a vector database of the internal knowledge base. The result is the 5–10 most relevant passages from product data sheets, standards registers and earlier bids.
2. Generation (assessment): A large language model (LLM) receives the requirement together with the retrieved source documents and generates a classification proposal with a rationale and source reference.

The advantage over a „bare“ LLM is that the system can access only information that is actually in the knowledge base. If no relevant source is found, it should honestly propose „R“ (query required) rather than hallucinate a plausible-sounding but unsupported answer.

Where AI reaches its limits

An honest look at the limits matters more than any success story. Today, AI systems for processing specifications run into five systematic limits:

1. Tacit knowledge

A company's most valuable knowledge is often undocumented. If an experienced engineer knows that a particular requirement led to exclusion in an earlier tender and therefore frames a strategic response, AI cannot access that information. It sees only the documents made available to it. This „tacit knowledge“ plays a major role in rail because the community is relatively small. Experienced bid managers know the preferences and evaluation standards of specific customers from years of collaboration.

2. Strategic assessment

Classifying a requirement as NOK is sometimes a strategic decision, not a purely technical one. Experienced bid managers ask targeted clarification questions to „soften“ requirements, for example by asking the customer why a requirement is stricter than the underlying standard. They may also use the opportunity to propose a more innovative alternative that convinces the customer. This kind of strategic communication lies outside AI's capabilities.

3. Document quality

The quality of AI results depends directly on the quality of internal documents. Outdated product data sheets, incomplete standards registers or contradictory manufacturer specifications produce faulty classification proposals. The principle of „garbage in, garbage out“ applies without qualification. The paradox is that companies that maintain their documentation well need AI support least, while those that need it most have the weakest data foundation.

4. Missing negotiation context

A specification is not a static document. It is the starting point of a negotiation. The second revision will contain different requirements from the first, based on feedback from all bidders. AI can process the current version, but it cannot anticipate which requirements the customer is likely to relax. Experienced bid managers develop that instinct through years of working with particular customers.

5. The hallucination risk

Even with a RAG architecture, the language model may infer connections that do not exist, or interpret source documents as apparently meeting the requirement when close inspection reveals material differences. A recent survey of LLM hallucinations describes the problem: language models are optimised to produce plausible answers, not to express calibrated uncertainty. In a bid process, where every classification implies a contractual commitment, this is a real risk.

What changes: The workflow with and without AI

According to the Loopio 2025 RFP Response Trends Report , 68% of proposal teams across industries already use generative AI (double the 34% in 2023). 65% use specialist RFP software (up from 48% the previous year), and the average win rate is 45%. The rail industry, traditionally more cautious about digital requirements management, is still at an early stage. According to Bidara , the cross-industry content-reuse rate is 66%. Most rail companies do not tap this potential because they lack a searchable knowledge base. Platforms such as Tendric address this by building and making that knowledge base searchable across projects.

Conclusion

What happens when AI reads a specification? It does the routine work: extraction, structuring, parameter comparison and standards recognition. It does so faster and more completely than a manual process. For 70–80% of requirements, it produces a useful first proposal with source references. For the remaining 20–30%, the strategic, qualitative and novel requirements, it correctly flags its uncertainty and passes them to a human expert.

That is not a failure. It is the point. AI gives the subject-matter expert freedom to focus on the requirements where their judgement makes a real difference instead of spending hours searching product data sheets. The INCOSE working group for AI Systems calls this „AI for SE“: AI supporting systems-engineering processes.

The next task is not better models. It is maintained standards registers, current product data sheets and searchable archives of earlier bids. Tools such as Tendric address this exact issue: they create the structured data foundation that makes AI-assisted classification reliable in the first place.