Engineering And Requirements Intelligence

The following discussion illustrates a project that is well suited to the capabilities of an independent consultant in the Umbrex Shipbuilding & marine systems Practice. This is an illustrative example. Umbrex consultants adapt their methodology, timeline, and deliverables to the specific needs of each client.

1) Client Situation

The client operated a complex naval shipbuilding program within a broader Aerospace & Defense portfolio and required support to stand up Engineering And Requirements Intelligence: Apply retrieval augmented generation (RAG) with Large Language Models (LLMs) across specifications, standards, and manuals to answer design queries and flag ambiguous or conflicting requirements. The current state reflected fragmented knowledge management across hull, mechanical, and electrical (HM&E), combat systems, and auxiliary systems engineering teams. We documented the following pain points tied to Shipbuilding & marine systems engineering processes:

• Operational friction in design query resolution: Engineers escalated routine questions about class rules, NAVSEA standards, and OEM interface requirements through email chains and meetings, resulting in prolonged mean time-to-answer (MTTA) that exceeded the program target by 3–5 days. RFIs accumulated before SRR/PDR/CDR milestones, inflating late-stage engineering change volume.
• Inconsistent interpretation of specifications: Multiple versions of MIL-STD-961/962, ABS and DNV class rules, and program-unique specifications coexisted. Conflicting interpretations led to non-conformances identified during design reviews and class comment cycles. Requirements volatility exceeded target thresholds, with high rework hours logged to resolve misreads of acceptance criteria and test procedures.
• Weak traceability and provenance: Requirements in DOORS and Jama were not consistently linked to source paragraphs in prime contract specifications, S1000D tech pubs, or OEM manuals. Trace gaps surfaced during configuration audits and CDRLs review, impacting compliance readiness and extending the time to prepare responses for certification bodies.
• Ambiguity in requirements language: Frequent use of TBD/TBR, “as required,” “sufficient,” and passive constructions went undetected until verification planning. Quality checks flagged an elevated rate of ambiguous requirements; defect density in requirements and verification artifacts remained above program benchmarks.
• Data fragmentation and findability issues: Engineering artifacts were scattered across SharePoint, Confluence, PLM (Teamcenter/3DEXPERIENCE), PDM vaults, and network shares. Legacy PDF scans with poor OCR compounded search failures. Search hit rates within document repositories remained low, and duplicate queries repeatedly surfaced to subject matter experts.
• Limited reuse of prior program knowledge: Lessons learned, class comment dispositions, and waiver/deviation rationales were stored in siloed repositories and not searchable at paragraph-level granularity. Engineering change lead time and ECP cycle time lagged expectations because teams could not quickly retrieve analog solutions or precedent decisions.
• Controls and compliance constraints: ITAR/EAR, CMMC, and NIST 800-171 controls mandated strict access governance. Engineering teams hesitated to use AI due to model risk, hallucination concerns, lack of audit trails, and uncertainty about where inference occurred (on-prem vs. external), limiting adoption of emergent tools.
• Supplier integration challenges: Interface Control Documents (ICDs) for propulsion, power distribution, HVAC, and combat systems used varying nomenclature. Misaligned requirements cascaded into late supplier inquiries and SDRs. Supplier deviation requests spiked ahead of production readiness reviews.
• Underperforming KPIs: We recorded lagging performance against engineering KPIs: response time to design queries, requirement clarity index, precision of search results, class comment resolution cycle time, change request aging, and share of requirements with verified lineage to source standards. Metrics trended below thresholds set in the program’s Systems Engineering Management Plan (SEMP).

Against this backdrop, we were engaged to build an AI, Data & Analytics capability using RAG with LLMs to unify specifications, standards, tech manuals, and prior decisions into a reliable, governed engineering assistant that could answer design queries and proactively flag ambiguous or conflicting requirements, with citation and traceability suitable for regulated defense shipbuilding environments.

2) Project Objective

Primary objective: Deploy an engineering and requirements intelligence capability using retrieval augmented generation (RAG) with LLMs that provided authoritative, citation-backed answers to design queries and detected ambiguous or conflicting requirements across specifications, standards, and manuals, thereby accelerating engineering decision cycles and reducing rework risk.

Secondary objectives:

• Increase precision and recall of technical document retrieval at paragraph-level, enabling faster, higher-confidence query resolution for naval architecture and marine systems design decisions.
• Improve requirements quality by automatically flagging ambiguity, incompleteness, duplication, and conflicts, aligned to the program’s requirements quality rubric and verification planning templates.
• Strengthen compliance by embedding provenance, traceability, and auditability into AI-assisted responses to satisfy class society review, NAVSEA oversight, and CMMC/NIST 800-171 controls.
• Reduce engineering change cycle time by enabling reuse of prior program dispositions, class comments, and waiver/deviation rationales through structured retrieval and knowledge graph context.
• Enable digital thread integration by connecting MBSE (SysML), DOORS/Jama, PLM/PDM, and S1000D tech pubs metadata to the retrieval stack, supporting end-to-end configuration control.
• Establish model risk management and AI guardrails to mitigate hallucinations, enforce access controls (ITAR/EAR), and implement abstain-on-uncertainty policies with human-in-the-loop review.
• Build internal capability through training, prompt patterns, and governance processes so engineering, ILS, and configuration management teams could own and evolve the solution.

3) Methodology and Approach

We structured the engagement around seven integrated workstreams that reflected the needs of the AI, Data & Analytics capability for Shipbuilding & marine systems and the specific scope of Engineering And Requirements Intelligence.

Workstream 1: Corpus Ingestion, Normalization, and Metadata Strategy

Activities we conducted:

• Inventory and connected heterogeneous repositories: SharePoint libraries, Confluence spaces, PLM (Teamcenter/3DEXPERIENCE), DOORS/Jama exports, S1000D data modules, OEM manuals, class rules (ABS, DNV, Lloyd’s Register), NAVSEA drawings/specifications, and historical class comment databases.
• Built ETL pipelines to ingest PDFs (born-digital and scanned), Word, XML (S1000D), and structured CSV/JSON. We applied OCR with layout-aware models to preserve tables, figures, and paragraph numbering crucial for citation.
• Defined a shipbuilding-specific metadata schema: system (HM&E, combat systems, auxiliary), zone, drawing reference, requirement ID, standard reference (e.g., MIL-STD-882E), class rule clause, configuration baseline, revision/date, and export control markings.
• Implemented document chunking at paragraph and subsection levels with cross-links to figures and tables. We indexed both dense embeddings and sparse tokens to support hybrid retrieval for technical terminology and acronyms common in naval engineering.
• Established canonical versioning and supersession logic to surface latest valid clauses, while maintaining links to prior versions for traceability and precedent research.

Tools and frameworks:

• Data lakehouse and search services (e.g., Databricks/Snowflake for storage, OpenSearch/Elasticsearch for keyword, FAISS/Weaviate/Pinecone for vector retrieval).
• Layout-aware OCR and document parsers, S1000D ingestion with DMRL mapping, and metadata enrichment via NLP entity recognition for standards and systems.

Stakeholders involved:

• Configuration management, technical publications/ILS, PLM/PDM administrators, class society liaison, cybersecurity/IT, and systems engineering leads.

Outcomes enabled: A unified, searchable corpus with authoritative version control improved findability, supported high-precision RAG, and reduced time-to-value by curating only validated, export-compliant sources.

Workstream 2: Ontology and Knowledge Graph for Marine Systems and Standards

Activities we conducted:

• Designed a domain ontology linking ship systems (propulsion, power, HVAC, hull structure), functions, performance parameters (shock, noise, EMI/EMC), and standards (ABS steel rules, SOLAS, MARPOL, MIL-STD, STANAGs).
• Constructed a knowledge graph mapping requirements to sources, class clauses, ICDs, SysML elements, verification methods, and historical dispositions (waivers/deviations, class comments, hazard analyses).
• Implemented entity resolution and synonym dictionaries for shipyard-specific nomenclature, aligning vendor terms to program taxonomy and avoiding retrieval gaps.
• Encoded precedence rules (e.g., prime contract supersedes enterprise standard unless class or statutory requirement dictates otherwise) to support conflict detection logic and response synthesis.

Tools and frameworks:

• Graph store and reasoning tools (e.g., Neo4j or similar), schema governance, and integration with MBSE repositories (e.g., Cameo/Capella) via export APIs.

Stakeholders involved:

• Naval architects, systems engineers/MBSE, class liaison, legal/compliance, and configuration control board representatives.

Outcomes enabled: Context-aware retrieval, structured citation trails, and early detection of cross-document inconsistencies, reducing risk of misinterpretation during design reviews.

Workstream 3: RAG Pipeline Engineering and LLM Orchestration

Activities we conducted:

• Developed hybrid retrieval combining BM25 keyword search with vector similarity; implemented re-rankers (cross-encoders) tuned on shipbuilding Q&A to improve paragraph-level precision.
• Built prompt templates for design queries, requirement clarification, and conflict checks, with explicit instructions to cite source document, clause, revision, and confidence bands.
• Implemented context assembly strategies (windowing, de-duplication, metadata filters like class rule version and export control) to constrain the model to relevant, approved sources.
• Configured abstention thresholds and fallback logic: if retrieval confidence fell below a set band, the assistant returned “insufficient evidence” with suggested SMEs and queries.
• Integrated answer provenance, highlighting exact passages used. We logged prompt/response pairs with metadata for auditability and continuous improvement.

Tools and frameworks:

• LLM orchestration layer (e.g., LangChain/LlamaIndex patterns), guardrails for prompt injection resistance, and on-prem inference options where required by ITAR/CMMC policies.

Stakeholders involved:

• Engineering leads, IT architecture, cyber/compliance, and knowledge management teams.

Outcomes enabled: Reliable, explainable responses with traceable citations reduced model risk and built trust while accelerating query handling.

Workstream 4: Requirements Quality and Conflict Detection Analytics

Activities we conducted:

• Defined a requirements quality rubric aligned to ISO/IEC/IEEE 29148 and program templates, covering clarity, completeness, testability, atomicity, and verifiability.
• Implemented detectors for ambiguity patterns (TBD/TBR, passive voice, indefinite quantifiers, missing units/tolerances), duplication detection via semantic similarity, and contradiction checks using entailment models (NLI) and simple constraint solvers for numeric conflicts.
• Built cross-document conflict scans: e.g., comparing allowable vibration/shock limits in class rules vs. OEM manuals; checking compartment ratings against SOLAS fire boundaries; verifying EMC requirements alignment between MIL-STD-461 and vendor equipment specs.
• Surfaced flagged items with severity and affected artifacts (requirements IDs, ICD clauses, test procedures), and routed to the appropriate change control workflow in DOORS/Jama and PLM.

Tools and frameworks:

• NLP pipelines, entailment/contradiction models, and rule-based validators integrated with requirements repositories and verification plans.

Stakeholders involved:

• Requirements engineering, verification & validation (V&V), QA/design assurance, and configuration management.

Outcomes enabled: Early visibility into ambiguous and conflicting requirements, improved quality of verification planning inputs, and reduced downstream rework risk.

Workstream 5: Integration with Toolchain and Digital Thread

Activities we conducted:

• Connected the RAG assistant to DOORS/Jama for bi-directional trace, enabling “answer-in-context” within the requirements tool and creating backlinks to source paragraphs.
• Integrated with PLM (Teamcenter/3DEXPERIENCE) to reference EBOM/MBOM items and engineering change objects (ECR/ECN/ECP), linking knowledge citations to affected parts and configurations.
• Synchronized with MBSE repositories (SysML block definition, parametric, and requirement diagrams) to maintain alignment between textual requirements and model elements.
• Embedded the assistant in collaboration platforms (SharePoint/Confluence) and CAD/CAE viewers where engineers worked, to reduce context switching.

Tools and frameworks:

• APIs and connectors to requirements, PLM/PDM, MBSE, and collaboration systems; SSO/Zero Trust integration; role-based access control enforcing export control boundaries.

Stakeholders involved:

• IT enterprise architecture, PLM admins, tool owners, and engineering process leadership.

Outcomes enabled: A cohesive digital thread that anchored AI responses in the authoritative systems of record, improving adoption and governance.

Workstream 6: Evaluation, Red Teaming, and Model Risk Governance

Activities we conducted:

• Established an evaluation harness with ground-truth Q&A derived from known-good design clarifications, class comment dispositions, and engineering standards FAQs.
• Measured precision@k, recall@k, answer faithfulness, citation correctness, and time-to-answer; ran A/B tests against baseline search workflows.
• Conducted adversarial testing for prompt injection, data leakage, and hallucination propensity; tuned retrieval filters and response policies accordingly.
• Implemented model risk management artifacts: model cards, data lineage, change logs, approval workflows, and periodic revalidation procedures.

Tools and frameworks:

• Evaluation frameworks for RAG, logging/telemetry, and dashboards for KPI tracking; policy engines to enforce guardrails and abstention behavior.

Stakeholders involved:

• Chief engineer, quality assurance, cybersecurity, legal/compliance, and program management.

Outcomes enabled: Confidence in AI behavior within a regulated environment, with clear governance and continuous improvement mechanisms.

Workstream 7: Change Management, Training, and Operating Model

Activities we conducted:

• Defined roles and responsibilities for content stewards, ontology owners, AI product owner, and engineering champions across HM&E and combat systems.
• Developed training for engineers on effective querying, reading citations, reviewing flagged requirement issues, and submitting feedback to refine the system.
• Created SOPs covering corpus curation, access reviews (ITAR/EAR), and operational monitoring. We mapped integration points with Configuration Control Board (CCB) and V&V gates.
• Ran pilot cohorts in naval architecture, power distribution, and HVAC, collected adoption feedback, and incorporated enhancements into the roadmap.

Tools and frameworks:

• Playbooks, onboarding modules, office hours, and an intake process for new source libraries and use cases.

Stakeholders involved:

• Engineering directors, functional managers, HR/L&D, and PMO.

Outcomes enabled: Scalable adoption, sustained content freshness, and a clear path to long-term ownership by the client.

4) Data Request

To execute the engagement, we issued a structured data request with explicit scopes, time horizons, and granularity expectations:

• Commercial/contractual:
  • Prime contract specifications and revisions, Statements of Work (SOW), CDRLs, and compliance matrices; 5–10 year program horizon; document-level with clause IDs and revision dates.
  • Supplier contracts and ICDs for major systems (propulsion, switchboards, HVAC, combat systems); latest baselines plus two prior versions; paragraph-level granularity.
• Operational/engineering:
  • Requirements repositories (DOORS/Jama) exports with IDs, attributes, and trace links; current baseline and last two baselines; item-level granularity.
  • MBSE models (SysML) and mapping tables to textual requirements; latest model plus change history; element-level granularity.
  • PLM/PDM metadata for EBOM/MBOM, ECR/ECN/ECP, and configuration states; 3–5 year history; object-level with change logs.
  • Design review artifacts (SRR/PDR/CDR/FDR), class comments, waiver/deviation logs; 5-year history; issue-level with dispositions.
• Technical/standards:
  • Class rules (ABS, DNV, LR) and statutory regulations (SOLAS, MARPOL, IMO codes) with crosswalks; maintain current and previous revisions; clause-level.
  • MIL-STDs, STANAGs, NAVSEA standards; maintain current and superseded versions; clause-level and paragraph IDs.
  • OEM manuals, S1000D data modules, maintenance instructions; latest with previous revisions; data module/paragraph-level granularity.
• Regulatory/ESG:
  • Certification plans, hazard analyses (MIL-STD-882), environmental compliance requirements (e.g., emissions, noise), cybersecurity controls; program horizon; document-level and section-level granularity.
• People/governance:
  • CCB charters and minutes, engineering process documents (SEMP, verification plans), quality rubrics for requirements; 3-year history; policy-level and meeting-level artifacts.
• Systems:
  • Access to repositories: SharePoint/Confluence, PLM (Teamcenter/3DEXPERIENCE), requirements tools (DOORS/Jama), MBSE tools (Cameo/Capella), data lake/lakehouse, search indexes. Architecture diagrams, network zones, identity providers; current state documentation.

Common data quality pitfalls we addressed:

• Scanned PDFs with low OCR fidelity, inconsistent paragraph numbering, and missing revision metadata.
• Non-canonical filenames and uncontrolled duplicates across repositories; lack of supersession markers for standards.
• Trace links stored as free text rather than stable IDs; broken references between requirements and verification artifacts.
• Export control markings missing or inconsistent, complicating access controls and model partitioning.

5) Questions for Client

• What level of assurance is required for AI-generated answers (e.g., citation strictness, abstention policy), and who is the accountable authority for acceptance?
• Which engineering KPIs (MTTA for design queries, requirements clarity index, class comment cycle time) are priority metrics for this capability to influence in the next two quarters?
• What are the definitive systems of record for specifications, standards, and manuals, and how should conflicts between repositories be adjudicated?
• Which export control boundaries (ITAR/EAR) and CMMC requirements constrain model training and inference locations, and what data must remain on-prem?
• What are the top 10 recurring design queries by system domain (propulsion, power, HVAC, hull structure, combat systems) that we should target for the initial pilot?
• How should we handle superseded standards and class rule revisions—visible for precedent only, or eligible for current answers with warning labels?
• What is the client’s risk tolerance for model hallucination versus answer latency, and where should abstention thresholds be set?
• Which stakeholders need embedded access (DOORS/Jama, PLM, MBSE, SharePoint), and what role-based controls are required for suppliers and external partners?
• What governance forum (e.g., CCB or dedicated AI oversight board) will own content curation, ontology evolution, and policy changes?
• What integration sequencing is preferred across DOORS/Jama, PLM, and MBSE tools, and what change freeze windows must we avoid?
• Are there ongoing audits or certification events (class review cycles, NAVSEA audits) that should define decision gates and release timing?
• What training and adoption model is expected—centralized enablement or functional champions—and how much engineer time can be allocated?
• What is the capital and operating budget envelope for year-one build-out and year-two scale, including hosting, licensing, and support?
• What legacy programs or analogous vessels provide reusable knowledge (class dispositions, waivers, test reports), and what is the legal posture for reuse?
• How will feedback and corrections from engineering teams be processed, prioritized, and incorporated into the RAG system?

6) Interview Guide for Subject Matter Experts

Naval Architect (Hull Structure and Hydrostatics)

• Which class rule clauses most frequently drive design iterations for hull structure, and where are conflicts with program-specific standards most common?
• How do you currently locate precedent decisions or class comment dispositions; what identifiers or paragraph patterns do you rely on?
• What ambiguity patterns in structural requirements (e.g., scantlings, welding standards) have historically caused rework?
• Which data (drawings, load cases, fatigue criteria) must be co-retrieved with textual requirements to make a decision?
• How do you validate that the latest class rules are applied when design baselines straddle revisions?
• What is your preferred workflow to review AI-proposed citations and flag errors for correction?

Systems Engineering Lead / MBSE Architect

• How are SysML elements currently traced to textual requirements and verification methods, and where do trace gaps occur?
• What decision rules guide reconciliation when MBSE models and textual requirements diverge?
• Which verification attributes (method, environment, acceptance criteria) should be surfaced by AI answers to support V&V planning?
• What are common conflict types across ICDs (signals, interfaces, tolerances) that the system should detect automatically?
• How do you assess the quality of requirements (29148 criteria), and which checks would you automate first?
• What modeling contexts (block definition, parametric constraints) should the assistant access for accurate responses?

Requirements Management Lead (DOORS/Jama)

• What conventions exist for requirement IDs, attributes, and change history, and how might the AI align to these structures?
• Where do ambiguity and duplication typically enter the backlog, and how are they resolved during peer reviews?
• What queries or dashboards are needed to triage AI-flagged issues by severity, owner, and verification impact?
• How should the assistant create backlinks or annotations within DOORS/Jama to maintain audit trails?
• What import/export processes could be leveraged to batch update metadata or trace links based on AI findings?
• What are the CCB entry/exit criteria for requirement changes that the assistant should be aware of?

Class Society Liaison / Certification Manager

• What are the most commonly misunderstood class rules for this vessel type, and how are interpretations documented?
• How should precedence be handled between class rules, statutory regulations, and program-specific requirements?
• What citation format and evidentiary standards are required to support class review and audit readiness?
• How are class comment histories stored and retrieved, and how might they be indexed for future reuse?
• What cadence of rule updates must the system track, and how should supersession be flagged in responses?
• What governance guardrails are required to ensure AI outputs do not inadvertently misstate regulatory positions?

PLM / Configuration Management Lead

• What are the authoritative sources for EBOM/MBOM, configuration baselines, and change objects, and how are they linked to requirements?
• Which change workflows (ECR/ECN/ECP) should the assistant integrate with to route flagged conflicts?
• What metadata is critical to maintain configuration traceability when requirements touch parts, assemblies, and documents?
• How are supplier ICDs and deviation requests tracked, and how should AI suggestions be recorded in configuration records?
• What are the common failure modes in configuration audits that this capability should help prevent?
• What access controls and data partitioning are necessary to segregate export-controlled or proprietary data?

Cybersecurity / IT Architect

• What are the approved hosting patterns for AI inference (on-prem, VPC, edge), and how do they intersect with ITAR/EAR and CMMC controls?
• What logging, monitoring, and retention policies govern AI prompts, retrieved content, and responses?
• How will identity, SSO, and role-based access control be enforced across repositories feeding the RAG pipeline?
• What data loss prevention and redaction requirements must be satisfied during ingestion and retrieval?
• What security assessment or ATO process applies to this capability, and what evidence must be produced?
• How should model updates and dependency changes be managed through change control and patch windows?

ILS / Technical Publications Lead

• How are S1000D data modules organized and versioned, and what metadata is required for accurate retrieval?
• What typical ambiguities arise in maintenance procedures or service limits that should be flagged?
• How are OEM manual updates reconciled with S1000D content, and what approval workflow exists?
• What cross-references to tooling, spares, or training materials must the assistant support to be useful for ILS queries?
• What is the process to validate AI-proposed edits or clarifications before publication?
• Which KPIs (publication cycle time, error corrections) should we observe during rollout?

7) Timeline

We executed a 12-week plan with phased milestones and decision gates aligned to the Engineering And Requirements Intelligence scope.

• Weeks 1–2: Discovery and Architecture Definition
  • Held stakeholder workshops to confirm priority use cases (top design queries, ambiguity patterns), risk posture, and compliance constraints.
  • Mapped the target-state architecture: ingestion pipelines, retrieval stack, LLM orchestration, access controls, and integration points with DOORS/Jama and PLM.
  • Decision gate: approve scope, repositories, and hosting pattern; confirm evaluation KPIs and model risk governance approach.
• Weeks 3–4: Corpus Ingestion and Metadata Foundations
  • Connected to source repositories; executed initial ingestion of standards, specs, manuals, and class rules; normalized revisions and established supersession logic.
  • Defined metadata schema and applied tagging; implemented paragraph-level chunking with preservation of figures/tables references.
  • Critical path: OCR quality and document normalization; access approvals for export-controlled content.
• Weeks 5–6: RAG Prototype and Ontology/Graph Build
  • Built hybrid retrieval indexes; deployed initial prompt templates for design Q&A and requirements checks.
  • Constructed the initial ontology and knowledge graph linking requirements, standards, and verification artifacts.
  • Decision gate: validate top-20 Q&A precision/faithfulness with SMEs; confirm ontology coverage for pilot systems.
• Weeks 7–8: Evaluation, Red Teaming, and Requirements Quality Checks
  • Ran evaluation harness with ground-truth datasets; tuned re-rankers and context assembly; set abstain thresholds.
  • Implemented ambiguity and conflict detectors; integrated issue routing to requirements and change workflows.
  • Critical path: model guardrails, adversarial testing, and approval of AI usage policies.
• Weeks 9–10: Integration and Pilot Deployment
  • Embedded the assistant into DOORS/Jama and collaboration platforms; added PLM backlinks and MBSE synchronization.
  • Launched pilot cohorts in three domains (e.g., power, HVAC, hull); monitored adoption and captured feedback.
  • Decision gate: approve scale-up plan based on KPI trends and user acceptance criteria.
• Weeks 11–12: Governance, Training, and Handoff
  • Finalized model risk governance, SOPs, and content stewardship roles; implemented dashboards for ongoing metrics.
  • Delivered training and playbooks; transitioned operations to internal product owner and engineering champions.
  • Next validation: confirm readiness for broader rollout and plan for additional corpora (e.g., test reports, supplier portals).

8) Deliverables

• Current-State Diagnostic and Opportunity Map
  • Assessment of repositories, toolchain, KPIs, and pain points; prioritized use cases for the RAG assistant in Shipbuilding & marine systems.
• Target Architecture and Security Blueprint
  • End-to-end design for ingestion, retrieval, LLM orchestration, access control, and logging; alignment with ITAR/EAR and CMMC/NIST 800-171 requirements.
• Corpus and Metadata Catalog
  • Inventory of ingested sources with version lineage, supersession rules, and metadata schema; guidance for ongoing content curation.
• Ontology and Knowledge Graph Schema
  • Domain ontology for marine systems, standards, and verification; graph data model with mappings to DOORS/Jama, PLM, and MBSE elements.
• RAG Assistant Prototype and Prompt Library
  • Configurable prompt templates for design Q&A, requirement clarification, and conflict detection; retrieval and re-ranking configuration with tunable parameters.
• Requirements Quality and Conflict Detection Playbook
  • Defined checks for ambiguity, duplication, and contradiction; severity rubric; workflows to route flagged items to owners and CCB.
• Evaluation and Model Risk Report
  • Results from precision/recall tests, faithfulness checks, red teaming; approved guardrails, abstention thresholds, and monitoring plan.
• Integration Adapters and API Specifications
  • Connectors for DOORS/Jama, PLM (Teamcenter/3DEXPERIENCE), MBSE tools, and collaboration platforms; data contracts and eventing patterns.
• Operational SOPs and Governance Charter
  • Roles and responsibilities, change control, content stewardship, access review procedures, and escalation paths; cadence for audits and model revalidation.
• Training Materials and Adoption Toolkit
  • Role-based training, quick reference guides, example queries, and troubleshooting; playbook for engineering champions.
• Roadmap and Investment Case
  • Phased scale plan, incremental use cases (supplier integration, test data ingestion), estimated run costs, and capability-building milestones.
• Dashboard and KPI Pack
  • Operational metrics (time-to-answer, retrieval precision, issue backlog), adoption analytics, and compliance reporting views.

9) Industry Insights

Shipbuilding & marine systems programs operate under stringent performance, safety, and regulatory regimes, with a growing volume of standards and complex multi-system interactions. Several trends informed the delivery of Engineering And Requirements Intelligence in the AI, Data & Analytics capability group:

• Escalating complexity and pace of change: Integrated electric propulsion, advanced materials, and increasingly software-defined capabilities elevate the interdependence of requirements. Frequent updates to class rules (ABS, DNV, LR), statutory regimes (SOLAS, MARPOL), and defense standards (MIL-STDs, STANAGs) increase the risk of misalignment and require automated supersession awareness.
• Model-based engineering adoption: MBSE and digital thread initiatives connect SysML models, requirements repositories, PLM, and manufacturing systems. AI-assisted retrieval that understands both textual and modeled context strengthens consistency and accelerates verification planning.
• S1000D and ILS digitization: Technical publications and maintenance data organized as data modules create opportunities for fine-grained retrieval and automated cross-referencing with design requirements and OEM manuals, improving lifecycle supportability decisions.
• Data fragmentation and security: Multi-program, multi-supplier environments distribute knowledge across secured repositories. Zero Trust architectures, CMMC, and export controls necessitate on-prem or VPC-compliant inference and rigorous access controls in any AI solution.
• AI maturity curve in engineering: Engineering leaders seek explainability, provenance, and audit trails to adopt AI. RAG with citation-backed answers, abstain policies, and integration with systems of record represent a pragmatic path compared to end-to-end generative approaches.
• Supplier ecosystem integration: OEMs and tiered suppliers maintain their own standards and manuals; aligning ICDs and resolving interface conflicts benefits from shared retrieval semantics, controlled access, and standardized metadata across parties.
• What “good” looks like: Organizations target paragraph-level retrieval precision with authoritative citations, low false-positive rates in ambiguity/conflict flags, sub-day turnaround for common design queries, and robust traceability from requirements to verification and configuration items. Governance includes periodic model revalidation, change control for content sources, and clear accountability for AI recommendations.
• Disruptions and inflections to watch: On-prem LLMs with improved context windows, multimodal capabilities (text + drawings + schematics), class society APIs for rules updates, and standardized ontologies for marine systems will expand the scope of reliable AI assistance. Regulatory guidance for AI in safety-critical engineering is evolving and warrants continued alignment.

For defense-focused shipyards and integrators within Aerospace & Defense, standing up an engineering and requirements intelligence capability with RAG and LLMs provided a structured way to reduce interpretation risk, accelerate design decision cycles, and embed compliance and traceability into daily workflows. The approach aligned with digital thread strategies, protected sensitive information through strong governance, and built internal capability to sustain and scale the solution across programs and suppliers.