KavAI Platform (KAP)

Real-Time Integrity Intelligence System™

Investigate & Escalate

Version: 3.2

Date: 2026-04-15

Author: KavAI Development Team

1 Executive Summary

1.1 Kav AI — Real-Time Integrity Intelligence System™ · Active Physical Intelligence™

Kav AI is a Real-Time Integrity Intelligence System for refinery and petrochemical operators. It is the first platform to close the loop between what sensors see, what process data says, and what engineering codes require — delivering continuously updated risk assessments that an integrity team can act on in hours, not weeks.

The platform operates as a continuous Active Physical Intelligence™ layer over the facility: it ingests visual inspection data (RGB, thermal, OGI), reads operational data from SCADA and process historians, and reasons across both inside a persistent 3D model of the plant. In v3.2 that loop was extended by autonomous robot patrols, fixed plant infrastructure, and CAD / engineering context. v3.3 sharpens the operating posture for that loop: continuous coverage from commodity fleets, cross-source confirmation as the noise filter, and a partner-integrated delivery model that puts qualified integrity engineers in the human-in-the-loop seat. The result is a single system that connects physical condition to process context to damage mechanism to risk score to recommended action — the full integrity chain, automated and auditable.

Kav AI is not a hardware manufacturer, not a SCADA replacement, not a robotics company, and not a general-purpose industrial AI platform. It is the integrity intelligence layer that sits above existing systems — purpose-built for the closed-loop analytical chain from Integrity Operating Windows (IOWs) through Damage Mechanism Reviews (DMRs) to prioritised inspection plans. Kav AI reads from operational systems; it never writes to SCADA or control systems, never actuates valves, and never commands field equipment.

1.1.1 Why refinery and petrochemical first

Kav AI’s beachhead market is downstream oil and gas — refineries and petrochemical plants — where the convergence of regulatory pressure (API 580/581/584), high unplanned downtime cost, and fragmented inspection workflows creates the strongest initial pull. The platform’s architecture is industry-agnostic, but the domain model, validation data, and go-to-market are focused here until traction is established. Expansion to adjacent asset-intensive industries (power generation, LNG, chemicals) follows.

¹ Solomon Associates, Downstream Industry Report, 2023. ² Kav AI customer discovery interviews, 8 facilities, 2025. ³ Solomon Associates, RAM Study benchmarking data, 2023.

1.2 What Kav AI is — and is not

To anchor procurement and partner conversations on the same operating identity, the platform’s boundaries are stated explicitly:

1.3 Competitive Moat

Kav AI’s durable advantage rests on five reinforcing pillars that no single incumbent or combination of point solutions replicates:

The moat deepens with every deployment: each facility’s data trains better models, each integration validates the connector ecosystem, each partner DMR sharpens the integrity domain model, and each successful pilot becomes a reference customer. This is not a feature advantage — it is a compounding system advantage.

2 The Opportunity

2.1 Market context

Kav AI’s beachhead market is downstream oil and gas — refineries and petrochemical plants. These facilities face the sharpest version of a universal industrial challenge: inspection and operational data live in separate silos, and the people responsible for facility safety spend significant time manually correlating data across all of them. The regulatory framework (API 580/581/584), the cost of unplanned downtime ($500K–$2M/day), and the maturity of RBI adoption make downstream the market where Kav AI’s closed-loop integrity intelligence delivers the fastest, most measurable value.

⁴ MarketsandMarkets, Drone Inspection and Monitoring Market Report, 2024. ⁵ Grand View Research, Industrial AI Market Analysis, 2024. ⁶ MarketsandMarkets, SCADA Market Global Forecast to 2030, 2025.

2.1.1 Expansion roadmap

Once Kav AI establishes reference customers and repeatable deployment in refinery/petrochemical, the platform expands to adjacent asset-intensive industries where similar inspection and integrity challenges exist:

2.2 Why now

Four enabling technologies reached production readiness between 2023 and 2024 and only now make the Kav AI platform feasible at scale:

• Photorealistic 3D from drone imagery — 3D Gaussian Splatting (3DGS) now creates navigable, photo-quality facility models directly from standard drone imagery. Before 3DGS, equivalent fidelity required LiDAR at 100x the cost.

• Multimodal AI reasoning — multimodal large language models crossed the threshold for correlating visual, thermal, and sensor data in a single analysis — the foundation for connecting what you see with what your instruments tell you.

• Vendor-neutral SCADA access — OPC UA adoption reached the level required for read-only integration across Emerson, Siemens, AVEVA, and Ignition deployments without vendor lock-in.

• Plug-and-play AI tools — new integration standards make it possible to connect AI directly to specialized detection models as callable tools — removing the custom integration work that previously made multi-sensor AI pipelines impractical.

2.3 Competitive landscape

Kav AI’s most important competitor is the combination of tools the integrity team already pays for: an RBI platform (orKsoft, GE Vernova APM, or equivalent), a process historian (OSIsoft PI or AVEVA), and a CMMS (SAP PM or Maximo). Kav AI must demonstrate that it delivers more value than the integration budget that would otherwise connect these three systems.

2.4 The Data Flywheel — Kav AI’s Compounding Advantage

Kav AI’s competitive moat is not static — it compounds with every inspection campaign a customer runs through the platform.

How it works:

1. Campaign ingestion — Each inspection campaign (RGB, thermal, OGI) adds labelled examples of facility-specific defect patterns, corrosion signatures, and equipment conditions to the training corpus.
2. Patrol accumulation — Repeated robot patrols add temporal history on the same assets, turning one-time detections into trendable condition signals.
3. Model refinement — Detection models are retrained on the expanded dataset after each campaign and patrol cycle. Facility-specific patterns (e.g., CUI signatures on a specific insulation type, thermal profiles unique to a particular heat exchanger configuration) improve detection precision.
4. OOD detector calibration — The Out-of-Distribution detector is retrained on the expanded input distribution, reducing false OOD flags and improving the signal-to-noise ratio for operators.
5. Confidence calibration — Empirical accuracy data from operator confirmations, dismissals, and cross-source corroboration refines the confidence scoring model, tightening the calibration curve.

The compounding effect: A customer who has run 10 campaigns and built months of repeat patrol history has a detection model tuned to their specific equipment, corrosion patterns, route coverage, and operating conditions that a new entrant cannot replicate without running the same sequence. This advantage widens with each campaign and patrol — making Kav AI progressively harder to displace at each facility.

Pricing alignment: Campaign volume is reflected in the subscription model (see Appendix H). Higher-tier subscriptions include more campaigns per year, directly linking customer investment to model performance improvement.

3 The Journey So Far

Kav AI has been in development since May 2025. In less than a year, the platform has moved from a blank canvas to a live alpha with two major milestones fully delivered and a third in active shipment.

3.1 What M0 and M1 proved

The foundation milestones were validated against real inspection data — not synthetic benchmarks or demos. M0 was tested with a first inspection campaign producing RGB imagery from an industrial facility. M1 raised the bar: a second inspection campaign introduced thermal imagery alongside RGB, plus structured sensor readings — gas concentration, temperature, and humidity. The AI pipeline was tested against this richer, multimodal dataset, reasoning across modalities on real industrial data.

M1 also included a deliberate technical bet: a proof-of-concept machine vision engine, validating that defect detection models can be called on demand by the AI pipeline. The Q2 visual perception features build directly on that validated pattern.

3.2 MVP demonstration sequence

In parallel with the platform milestones, Kav AI runs a public-facing MVP demonstration sequence that turns the engineering work above into outcomes a non-technical buyer can evaluate. v3.3 makes that mapping explicit:

The Scale & Impact section reports the MVP v0.2 evidence in detail. The Operations and Integrity Analytical Chain sections describe the workflow that MVP v0.3 / v0.4 instrument.

4 Where We Are Going — Q3 and Q4 2026

With the core AI platform closing in Q2, Kav AI’s second half of 2026 focuses on two distinct ambitions: deepening integration across the full industrial data environment in Q3, and advancing the research capabilities that will define the platform’s long-term intelligence in Q4.

4.1 Q3 2026 — Deepening the platform

4.2 Q4 2026 — Completing the platform and advancing the intelligence

Q4* items are research-dependent, contingent on Q2 spike outcomes. Their deferral to 2027 does not affect the engineering workstream above.

4.3 AI Engine and Machine Vision

Kav AI’s AI engine coordinates specialized defect detection models — each trained for a specific modality (RGB, thermal, OGI) — and calls them on demand as part of the analytical pipeline. From v3.2 onward, that orchestration layer also becomes the convergence point for robot patrol findings, CAD-linked asset identity, and cross-source confirmation. v3.3 brings the cross-source confirmation engine to the front of the user-facing narrative: independent sources are the unit of confidence, and the engine is what converts a noisy single-modality signal into a multi-source confirmed finding.

• Model Versioning & Rollback: Each detection model is tagged with a version ID. The platform can switch model versions or roll back to a proven baseline if performance degrades on specific asset types.
• Detection Speed: Production GPU hardware targets ensure sub-second detection for RGB/Thermal imagery, with queuing for high-resolution OGI/drone campaigns.

5 Expanded Capture & Engineering Context

v3.2 kept the v2.9 product framing intact and extended the platform in the two areas that most materially strengthen the integrity loop: autonomous robot coverage and CAD / engineering context. v3.3 keeps that scope and adds two structural clarifications that have become important in external conversations: the architectural shift from onboard SLAM to fixed plant infrastructure, and the cross-source correlation engine as the explicit step that turns single-source detections into multi-source confirmed findings.

These additions do not change what Kav AI is. They increase how often the platform sees the plant, how precisely it localises findings, and how reliably it ties those findings back to asset identity and engineering intent.

5.1 Autonomous robot coverage

Autonomous robots extend Kav AI from campaign-based inspection to persistent facility awareness. The platform preserves the v2.9 hardware-agnostic position: robot data is an input layer, not a product-category shift.

5.1.1 Fixed infrastructure

Fixed plant infrastructure is the enabling layer for reliable, repeatable patrol coverage:

This architecture deliberately avoids turning Kav AI into a robot OEM stack. Kav AI specifies what needs to be seen next based on staleness and risk. Vendor fleet software or the operator still decides how to execute the patrol.

The combined effect is continuous coverage of ≥ 20 hours per day across the fleet at a fully equipped site — turning the historical “battery-bound 90-minute patrol” model into a continuous sensory web without paying the cost of a bespoke OEM stack.

5.1.2 Architectural shift: onboard SLAM vs. fixed infrastructure

Fixed plant infrastructure is not just an availability story — it is a different navigation and data-registration architecture. The promo-deck shift is captured below for procurement teams comparing Kav AI against onboard-SLAM-only competitors:

Fixed infrastructure is the architectural reason Kav AI can credibly claim fleet-agnostic, mission-specific coverage instead of taking on the cost of a proprietary robot OEM stack.

5.1.3 Robot sensing and mission intelligence

Robot ingestion in v3.2 extends the proven v3.0 adapter pattern:

• Extended telemetry sessions for 4–6 hour patrols, including timeout handling, buffering, and reconnection.
• Payload registration for thermal and visual sensing as baseline, with acoustic and gas payloads validated per platform.
• Mission-history analytics that detect progressive degradation, patrol gaps, calibration drift, and persistent connectivity failures.

The consequence is strategic, not merely technical: the data flywheel now compounds not only across periodic drone campaigns, but also across recurring ground patrols that revisit the same assets with tighter spatial repeatability.

5.2 CAD and engineering data

v3.2 also carries forward the v3.1 expansion of the engineering context layer. v2.9 introduced CAD overlay as a roadmap item; v3.2 makes it a central extension to the integrity workflow rather than a standalone visual feature.

5.2.1 Per-format scope

5.2.2 Digital twin and change management

CAD only becomes operationally useful when tied to the live spatial record. v3.2 therefore combines:

1. CAD-derived design intent from the engineering model.
2. As-built geometry from 3DGS and LiDAR-derived scans.
3. Inspection findings from drone, robot, and fixed/SCADA sources.

This allows the platform to surface engineering changes, geometric deviations, and repeated anomaly patterns as part of the same integrity conversation rather than as separate systems.

5.3 Cross-source confirmation engine

The robot and CAD additions are most valuable when they strengthen the core analytical chain rather than sitting beside it. v3.2 incorporated the v3.1 cross-source correlation model into the v2.9 integrity narrative; v3.3 promotes that primitive to a named engine:

5.3.1 How the engine works

The cross-source correlation engine operates as a deterministic pre-stage to the AI confidence model:

1. Tag — every detection from a drone campaign, robot patrol, fixed sensor, or SCADA IOW exceedance is timestamped, geo-located inside the 3D model, and tagged with its modality (RGB, thermal, OGI, acoustic, gas, process telemetry).
2. Match — independent detections within a 2 m spatial radius and an aligned temporal window are grouped as candidate corroborations.
3. Score — confidence is rescored from the per-source baseline. A representative example: a thermal anomaly at 0.70 confidence corroborated by an acoustic / thermal ground patrol and a SCADA insulation surface-temperature IOW exceedance is rescored to ~ 0.95.
4. Surface — the rescored finding is presented to the operator with all source records attached. The Filter Skill and Stage 3.5 consistency gate (see Integrity Analytical Chain) still apply; cross-source uplift cannot override a hard rejection.

5.3.2 Why this is the moat

A single-source detection is structurally exposed to environmental noise. A multi-source confirmed detection is the result of independent physical signals agreeing on a precise spatial-temporal coordinate — a much harder thing to fake. v3.3’s external claim follows directly: multi-source confirmed findings target TPR > 98% / FPR < 2%, while single-source modality-specific targets remain as documented in Operations.

Cross-source confirmation does not replace engineering validation. It improves prioritisation, confidence calibration, and inspection planning by showing when multiple independent signals are converging on the same asset condition.

6 Scale & Impact — From “We Found Something” to “Inspect These Eight Locations Next”

A common failure mode for industrial AI platforms is that they are demonstrated, not deployed: a single anomaly on a single asset, dressed up as a product. v3.3 promotes the MVP v0.2 evidence to a dedicated chapter so the procurement team can see, on one page, that Kav AI operates at facility scale, repeatably, and with a direct line to financial impact.

6.1 What MVP v0.2 proves

MVP v0.2 is the second step in Kav AI’s public-facing demonstration sequence (see Journey — MVP demonstration sequence). It answers the three questions an operator will ask at the first procurement meeting:

6.2 Facility-scale evidence

The MVP v0.2 facility scan demonstrates Kav AI operating at a unit-level scale that is procurement-relevant rather than demo-relevant:

Coverage is repeatable and extendable across the facility. This reframes the platform from an “interesting detection tool” to a practical inspection coverage solution.

6.3 Decision context — detection → diagnosis → action

The platform does not stop at flagging an anomaly. The MVP v0.2 representative finding shows the full chain a buyer expects to see:

The selection basis for high-priority items combines thermal severity, pattern consistency across the dataset, and cross-asset comparison — not raw anomaly count.

6.4 Economic framing

Thermal anomalies are translated into business-relevant risk so that the procurement conversation can move from “interesting” to “fundable”:

This ties the platform output directly to the same economic levers that Solomon Associates RAM benchmarking uses to compare top- and bottom-quartile facilities (see Executive Summary).

6.5 Role of AI at this scale

A critical positioning shift between MVP v0.1 and MVP v0.2 is making the role of AI explicit:

The drone and thermal camera collect data — Kav AI is what makes that data usable at scale.

At facility scale the AI layer is responsible for:

• Indexing and organising inspection data across thousands of assets
• Detecting anomalies across large datasets in a single run
• Ranking findings by priority and cross-asset comparison
• Enabling natural-language retrieval across the same dataset
• Surfacing coverage gaps and revisit candidates back to the patrol planner

Without this layer the workflow does not scale beyond manual review — and manual review is the workflow that today reviews fewer than 10% of captured imagery.

6.6 Where Scale & Impact connects in the rest of the PRD

7 Operational Workflow — Anomaly-to-Action

To ensure Kav AI reduces cognitive load rather than creating “alarm fatigue,” the platform follows a structured escalation path for every identified anomaly. v3.2 preserved the v2.9 human-in-the-loop workflow and extended it to account for robot-sourced findings, cross-source confirmation, and richer engineering context at the point of triage. v3.3 keeps that workflow intact and adds a cross-source confirmed performance target alongside the per-modality targets.

7.1 The Triage-to-Escalation Path

The workflow from AI detection to field action is governed by a four-stage process involving distinct operational roles:

1. Stage A (Automated Triage): AI identifies an anomaly, runs the cross-source correlation engine, and assigns an initial severity score (Critical/Standard/Info). Low-confidence alerts (<0.7) are filtered from the primary ‘Action’ dashboard and moved to a ‘Review’ queue. From v3.2 onwards, the triage packet also includes source type (drone, robot, SCADA), patrol or campaign identifier, and CAD-linked asset identity. v3.3 adds the explicit correlation category (single-source / corroborated / multi-source confirmed) on the triage packet.
2. Stage B (Human Verification): High-severity anomalies are surfaced to the On-call Integrity Engineer’s dashboard (desktop/mobile). The engineer must select: ‘Confirm’ (Escalate to Field), ‘Dismiss’ (False Positive - Model Feedback), or ‘Reclassify’ (Adjust Severity). Cross-source corroboration can raise priority and, in the multi-source confirmed class, can shorten the queue, but it does not bypass deterministic Filter Skill rejection or Stage 3.5 inconsistency flags.
3. Stage C (Escalation & Audit): Confirmed anomalies generate an “Actionable Insight” record. Every ‘Dismiss’ or ‘Confirm’ decision is timestamped and logged in a shift-handover audit report visible to the Operations Supervisor. Coverage context and engineering-change context are attached where available.
4. Stage D (CMMS Integration): Verified insights provide a structured data packet for the operator’s CMMS (e.g., SAP PM, Maximo) to initiate a work order. Kav AI reduces the ‘Triage-to-Work Order’ cycle from 5–10 days to < 4 hours. SAP PM remains the first certified connector priority because it opens the largest installed-base pathway.

7.2 Performance and Accuracy Targets

To maintain operational trust, Kav AI commits to the following detection and false positive targets for Q3/Q4 2026 (benchmarked against M0/M1 datasets and validated by ground-truth NDT):

Detection rates are based on the Kav AI M0/M1 validation campaigns and require site-specific calibration during the 90-day pilot phase. The multi-source confirmed line is the externally-quoted “moat” claim and is the only class that may bypass the manual verification queue (still subject to Filter Skill and Stage 3.5 consistency).

7.3 Human-in-the-Loop (HITL) Validation

Kav AI is a decision-support tool, not an autonomous inspector. No “Critical” severity output or “Remaining Life” adjustment can be finalized without individual engineer sign-off in the platform. Every such action is captured in the version-controlled audit trail.

7.4 Business Readiness & Referenceability

Kav AI recognizes that enterprise procurement requires a clear path to value and financial predictability.

7.4.1 Cost Model & ROI Modelling

Kav AI recognizes that enterprise procurement requires a clear path to value and financial predictability. Indicative pricing components include:

• Annual Subscription (License): Per-facility tiered pricing based on asset count.
• Implementation & Integration: One-time setup fee for SCADA/Historian mapping and 3D Model ingestion.
• Success & Support: Ongoing model retraining and integrity engineering support.

7.4.2 Availability & Payback Commitment

Based on Solomon RAM benchmarking, Kav AI targets a 1.0 percentage point improvement in facility availability within 18 months of full operational deployment. This is achieved through the elimination of data-latency-driven shutdown delays and the early detection of high-consequence failure modes.

For sites that adopt fixed infrastructure and repeat patrol coverage, the business case broadens:

• Coverage continuity: higher percentage of the facility seen between major campaigns.
• Trend visibility: progressive degradation detected across repeated passes, not only one-time campaigns.
• Human entry reduction: especially relevant where dose, confined space, or outage logistics make manual inspection disproportionately expensive.

7.5.1 Bidirectional Integration Architecture (FR-INT-03)

7.5.2 Certified Connector Priority (FR-INT-04)

A certified integration means: a documented data schema, a tested connector, a reference customer who has run it in production, and a support SLA.

7.5.3 orKsoft Coexistence Architecture

orKsoft and Kav AI are complementary, not competitive. The coexistence pattern:

• Audit Consistency: Ensures the 3D ‘Spatial Record’ (Kav AI) and the IDMS ‘Compliance Record’ (orKsoft) remain synchronised via scheduled SQL/Web API connectors.

7.5.4 Reference Customers

Kav AI is currently executing its third major inspection campaign at a European Tier-1 oil refinery (Crude/Vacuum unit). Reference calls with the lead Integrity Engineer can be facilitated upon request for qualified enterprise buyers.

7.5.5 Partner-led delivery channel

Where the customer prefers an integrated delivery model — platform plus mechanical-integrity engineering services in a single procurement vehicle — Kav AI engages with qualified partners (e.g., OI.Expert) who provide the human Integrity Engineer panel, DMR / IOW programme work, and HITL validation. The Partner-Integrated Delivery Model section describes this channel in full and reflects the framework set out in the April 2026 OI.Expert Letter of Intent.

8 The Integrity Analytical Chain — Architectural Ownership

The IOW/DMR closed-loop analytical chain is the core intelligence differentiator of the Kav AI platform from Q3 onwards. This section defines its architecture, its owner, and the data flow from SCADA ingestion to actionable risk output. From v3.2 the same chain is strengthened by robot patrol evidence, CAD-linked asset identity, and cross-source confirmation, while keeping the v2.9 architecture intact. v3.3 makes one further clarification: the cross-source correlation engine described in Expanded Capture & Engineering Context runs before Stage 3.5 and feeds the evidence-consistency check — it does not replace it.

8.1 The six-stage analytical chain

The chain runs from raw SCADA telemetry through to prioritised corrective action recommendations, benchmarked against the Solomon Associates database at the risk quantification stage.

The IOW/DMR chain becomes available from Q3 2026 when the SCADA/OPC UA connector is delivered. Stages 4 and 5 require physical inspection data from the Kav AI 3D model, which is available from Q2. v3.3 extends those stages with repeat patrol evidence, fixed-infrastructure continuous coverage, and engineering-context enrichment where present.

8.1.1 Inspection Plan Output Schema (FR-RBI-01)

The IOW/DMR chain does not terminate at risk score generation. Stage 6 produces an inspection plan — a prioritised, time-bound schedule. The minimum schema for a Kav AI inspection plan record:

This schema is agreed with the reference customer before Q3 delivery and governs the IDMS integration write interface.

8.1.2 Equipment Class Boundary of Automation (FR-RBI-02)

The Tier 1/Tier 2 automation boundary applies across equipment classes as well as damage mechanisms. Scope for v1:

8.2 Analytical Rigour — Confidence and Provenance

To satisfy enterprise integrity standards (API 581/510), Kav AI does not treat the analytical chain as a “black box.” Every safety-critical output carries clear provenance and uncertainty bounds.

8.2.1 Corrosion Rate (CR) Provenance

The platform applies a weighted hierarchy to corrosion rate inputs, favouring measured data over theoretical models:

1. Level A (Measured): Derived from localized Ultrasonic Testing (UT) trend data at specific Corrosion Monitoring Locations (CMLs).
2. Level B (Modeled): Derived from process-specific corrosion models (e.g., pH, H2S, CO2 concentration), if UT data is stale (>12 months) or unavailable.
3. Level C (Generic): Derived from the API 571/581 knowledge base for standard materials in nominal service.

8.2.2 Uncertainty Quantification (UQ)

Remaining Life (RL) estimates are never presented as single-point figures. Kav AI propagates uncertainty across the entire analytical chain:

• Measurement Tolerance: UT thickness measurements (tₓᴀᴄᴛ) carry a ±0.1–0.5mm tolerance based on technique/surface condition.
• Engineering Code Variance: Minimum thickness (tₘᴵⁿ) is calculated per ASME B31.3 / API 570 with baseline corrosion allowances.
• Model Variance: Corrosion Rate (CR) uncertainty varies by provenance (Level A/B/C).
• Output: P90 Remaining Life is the probabilistic interval used for inspection interval determination.

8.2.3 Timestamp Integrity and Windowing

Correlation across heterogeneous sources (SCADA scan vs. Event-driven historians) is governed by a ±500ms synchronisation window.

• Values exceeding this window or sourced from interpolated historian gaps are flagged as “Stale/High Variance” and reduced in weight for Stage 3-5 reasoning.
• Kav AI supports NTP/PTP-synchronised sources to maintain sub-second alignment in millisecond-sensitive environments.

8.2.4 Boundary of Automation — Expert-in-the-Loop

Not all damage mechanisms are equally detectable via process telemetry. Kav AI maintains a strict boundary:

• Tier 1 (Automated): Mechanisms with high process correlation (e.g., CUI via thermal anomaly, CO₂ corrosion via pH/temp).
• Tier 2 (Expert Required): Mechanisms requiring thermodynamic simulation or historical thermal fatigue analysis (e.g., NH₄Cl underdeposit, Creep, HIC). These are flagged as “Credible” by the AI but require manual engineer validation before inclusion in the Risk Quantification stage.

8.2.5 CML and PIL Integration — Lifecycle Management

The 3D facility model serves as the spatial system of record for Piping Inspection Locations (PILs) and Corrosion Monitoring Locations (CMLs).

• Registration: Operators can register and name CMLs in 3D space with sub-centimetre precision.
• Traceable History: Each CML maintains an immutable, timestamped history of UT readings, including inspector ID and instrument calibration references.
• Coverage Reporting: The platform generates compliance reports identifying inspected vs. overdue CMLs per the API 581 inspection plan.
• Visual Context: Click any CML to view its historical trend, IOW exceedance logs, and the resulting damage mechanism predictions.
• Engineering Context: Where CAD / P&ID mappings are available, the same view also carries design tag, line number, and recent engineering change history.

8.3.1 Probability of Failure (PoF)

The platform calculates PoF using the API 581 Damage Factor approach. This includes:

• Base Damage Factor: Derived from the active damage mechanism (API 571) and predicted degradation.
• Inspection Effectiveness: Adjustments based on the number and quality of past NDT inspections (Grade A/B/C/D).
• Management System Factor: Facility-specific multiplier for operational discipline.

8.3.2 Consequence of Failure (CoF)

CoF is categorised into four primary streams:

1. Flammable/Explosive: Area-based consequence of fire/explosion.
2. Toxic Release: Dispersion modelling for H₂S, HF, or other hazardous process fluids.
3. Environmental: Volume-based spill consequence for soil/water.
4. Financial: Production loss and repair costs, benchmarked against Solomon Associates CPA™ facility profiles.

8.3.3 Ranked-to-Calibrated Transition

During the initial deployment and pilot phase (90 days), risk outputs are presented as Relative Risk Rankings for prioritisation. Full Calibrated Probability of Failure (mapping scores to physical failure frequencies) is achieved after the first ground-truth inspection cycle is ingested and the model is site-validated. The transition is triggered by a minimum dataset: a defined number of UT readings at registered CMLs with known inspection history, agreed with the operator during pilot onboarding.

9 AI Safety — Hallucination Mitigation & Grounding

Given the safety-critical nature of asset integrity, the Kav AI analytical chain (IOW/DMR) includes specific safeguards to mitigate AI hallucinations and ensure engineering-grade reliability. v3.2 kept the v2.9 safety model intact and extended it to handle cross-source correlation, robot patrol evidence, and nuclear-package requirements without weakening the original guardrails. v3.3 keeps these safeguards unchanged and clarifies their priority order: Filter Skill > Stage 3.5 consistency gate > cross-source correlation uplift. A multi-source confirmed finding can shorten the operator queue, but it cannot promote a Filter-rejected mechanism or override an INCONSISTENT flag.

9.1 Grounding via Deterministic “Filter Skills”

To eliminate LLM hallucinations in the IOW/DMR chain, every AI output is passed through a deterministic validation layer before it reaches the operator:

• Susceptibility Filtering: Before a damage mechanism (Stage 3) is presented to the user, a “Filter Skill” checks the asset material and process conditions against a hard-coded API 571 susceptibility matrix.
• Schema Validation: Outputs are constrained to structured JSON schemas; any “hallucinated” fields or out-of-range values trigger a re-generation or a “Low Confidence” flag.

9.1.1 Filter Skill Performance Targets (FR-AI-01)

• False Positive Rate (FPR): The rate at which the LLM suggests a damage mechanism that the Filter Skill correctly rejects. Documented across M0/M1 validation data.
• False Negative Rate (FNR): The rate at which the LLM suggests a plausible-but-incorrect mechanism that the Filter Skill fails to catch. Measured via ground-truth labelling by an integrity engineer panel. The FR-ANO-02 spike objective (>90% agreement with human Integrity Engineer panel) applies to the full chain including Filter Skills, not just to the LLM output pre-filtering.
• Re-evaluation cadence: Filter Skill performance is re-evaluated after every new inspection campaign, since each campaign expands the input distribution.

9.2 Confidence Scoring and Calibration

Kav AI provides a 0.0–1.0 confidence score for every AI-generated output (mapping, detection, recommendation):

• Source Density: Weights based on the availability and quality of sensor/inspection data.
• Model Consensus: Variance across multi-agent reasoning paths.
• OOD Detection: Out-of-Distribution detection flags inputs (e.g., extreme sensor noise) that differ materially from the M0/M1 training distribution.
• Cross-Source Confirmation: In v3.2, corroboration across independent sources can increase confidence, but only after the output has survived deterministic validation.

9.2.1 Confidence Score Calibration Protocol (FR-AI-02)

Confidence scores are calibrated against empirical accuracy before they are used as a dashboard threshold:

1. For each confidence bucket (0.5–0.6, 0.6–0.7, 0.7–0.8, 0.8–0.9, 0.9–1.0), measure the proportion of outputs in that bucket that are confirmed correct by the operator pilot lead.
2. Plot the calibration curve. A perfectly calibrated model has a diagonal curve (0.7 confidence = 70% accuracy). Report the calibration error.
3. Adjust the dashboard surfacing threshold based on the calibration curve, not the raw confidence score. If the 0.7 bucket has 50% empirical accuracy, the surfacing threshold should be raised to the bucket that achieves the target accuracy.
4. Include the calibration curve as a deliverable in the 90-day pilot success evaluation (Appendix G), updated at Week 9–10.

v3.2 / v3.3 extension: calibration must be reported separately for single-source findings, corroborated findings, and multi-source confirmed findings. Cross-source uplift is disabled by default until empirical accuracy demonstrates that the uplift is warranted. v3.3 additionally requires that the externally-quoted multi-source confirmed TPR > 98% / FPR < 2% target be reported against the same calibration curve and re-evaluated after every campaign and patrol cycle.

The current threshold of 0.7 for Action dashboard surfacing and 0.6 for UNCERTAIN flagging is provisional until calibration data from the third inspection campaign is available.

9.2.2 OOD Detection Update Cadence (FR-AI-04)

The M0/M1 training distribution covers two facilities. The OOD detector trained on this distribution will flag the majority of inputs from a third facility as OOD.

• After each new inspection campaign, retrain the OOD detector on the expanded distribution. This is lower-cost than retraining the detection models and can be done continuously.
• New facility onboarding procedure: The first campaign at a new facility is treated as baseline data collection, not production anomaly detection. OOD flags are expected and are used to calibrate the detector, not to surface UNCERTAIN alerts to operators.
• This procedure is documented in the pilot framework (Appendix G) so that operators understand that Week 1–4 detection performance will differ from steady-state performance.
• v3.2 / v3.3 extension: High-endurance robot sessions, IFC/RVT metadata variance, fixed-infrastructure continuous-coverage telemetry, and nuclear-environment sensor readings are each treated as distinct distribution expansions. The first mission set in each category is baseline calibration data, not production-grade alerting data.

9.3 Safety Fallbacks and HITL

If an AI output fails a Filter Skill or returns a confidence score below 0.6:

1. The output is automatically marked as “UNCERTAIN - REVIEW REQUIRED.”
2. The Integrity Engineer is presented with the conflicting evidence (e.g., “AI suggests SCC, but material is Carbon Steel - check required”).
3. The system prevents the anomaly from propagating to the “Critical Action” dashboard until manually resolved.

9.4 Chain-Level Consistency Gate (FR-AI-03)

The IOW/DMR chain is a 6-stage pipeline. A hallucination in Stage 3 that passes the Filter Skill will propagate through Stages 4, 5, and 6, compounding at each step. The consistency gate (Stage 3.5 in the analytical chain table above) performs three checks to prevent this:

1. Material-mechanism consistency: Is the predicted damage mechanism chemically plausible given the asset’s material of construction and process fluid? (This is the existing Filter Skill.)
2. Rate-mechanism consistency: Is the predicted corrosion rate in Stage 5 consistent with the predicted damage mechanism in Stage 3? For example, if Stage 3 predicts CUI (external), the corrosion rate should not be derived from internal process chemistry data.
3. Evidence consistency: If Stage 4 physical validation data is available, does the visual evidence (thermal anomaly pattern, OGI reading) match what the predicted damage mechanism would produce? A thermal anomaly consistent with insulation damage is consistent with CUI. A uniform wall-loss pattern from UT is not consistent with pitting corrosion from NH₄Cl underdeposit.

Failures produce an explicit “INCONSISTENT — ENGINEERING REVIEW REQUIRED” flag rather than propagating to Stage 5. The inconsistency reason and the conflicting evidence are surfaced to the engineer alongside the flag.

From v3.2 onwards, multi-source confirmation strengthens evidence consistency only when the corroborating sources are genuinely independent. A second source can support a finding; it cannot override a Filter Skill rejection or erase a material-mechanism inconsistency. v3.3 restates the priority order explicitly — Filter Skill > Stage 3.5 > cross-source uplift — so that the cross-source correlation engine cannot be misread as a Filter Skill bypass. Nuclear-package deployments additionally require mandatory engineer review before any downstream CMMS handoff.

10 Deployment Architecture — On-Premise, Air-Gapped, and Fixed-Infrastructure Options

Enterprise procurement in the oil and gas, chemical, and power sectors requires defined answers to three infrastructure questions: where does the data go, who controls the model, and can the system operate without cloud connectivity. v3.2 kept the v2.9 answers intact and added a fourth: what changes when the site adopts persistent robot coverage and higher-regulation operating constraints. v3.3 keeps all four answers in place and surfaces an additional procurement-relevant detail in line with the OI.Expert LOI commitments: on-premise / air-gapped deployments require no heartbeat, telemetry, or licence callbacks of any kind.

10.1 SCADA Compatibility Matrix (Qualifications)

Deployment complexity for OPC UA varies by vendor and version:

• Emerson DeltaV: Native support from v14.3+; earlier versions require an OPC UA gateway.
• AVEVA System Platform: Requires Historian configuration to expose tags via UA; typically restricted by DMZ policy.
• Siemens WinCC/SIMATIC: Requires WinCC OPC UA Server licence; server configuration often requires Siemens Professional Services.
• Ignition (Inductive Automation): Full native compatibility with built-in UA module.

10.1.1 Secrets and Credential Management

Kav AI does not store plain-text credentials in container configurations.

• OPC UA Authentication: Supports X.509 Client Certificates (PKI) for Mutual TLS (mTLS) or encrypted username/password via integration with HashiCorp Vault or cloud-native secrets managers (Azure Key Vault, GCP Secrets Manager).
• Encryption: All data is encrypted at rest using AES-256 and in transit via TLS 1.2/1.3.

10.1.2 Container Supply Chain Security

To ensure the integrity of on-premise and tenant deployments:

• Image Signing: All production container images are signed using Sigstore/cosign and verified at runtime.
• Vulnerability Scanning: CI/CD pipelines use Trivy for deep-layer vulnerability scanning before image promotion.
• SBOM: A Software Bill of Materials (SPDX format) is provided for every production release to facilitate operator-side security audits.

10.2 Security and compliance targets

10.3 Fixed infrastructure deployment

The fixed-infrastructure additions are treated in v3.2 as deployment extensions rather than as a separate product:

These components do not alter the OT/IT boundary described above. In air-gapped deployments they operate entirely within the operator’s network perimeter.

10.4 Regulated-environment considerations

Higher-regulation deployments add operating constraints without changing the core architecture:

11 Partner-Integrated Delivery Model

Kav AI’s customers do not buy a platform in isolation. They buy a working integrity programme — anomalies that have been surfaced, reviewed by a qualified engineer, embedded in a Risk-Based Inspection (RBI) plan, and pushed into a CMMS work order. v3.3 formalises a delivery model in which the Kav AI Platform (KAP) is the technology layer and a qualified mechanical-integrity engineering partner provides the human Integrity Engineer panel.

11.1 Why a partner channel exists

The Kav AI position on Human-in-the-Loop (HITL) validation is non-negotiable: no Critical severity output, no Remaining Life adjustment, and no automatic CMMS work order can be finalised without a qualified Integrity Engineer’s sign-off. That requirement creates a recurring engineering workload that some customers prefer to outsource to a specialist firm rather than staff in-house.

Both models are supported. The partner channel is an option for customers who want a unified procurement vehicle and faster time-to-RBI-impact.

11.2 Reference partnership — OI.Expert × Kav AI

The reference partnership documented in the April 2026 LOI defines the shape of every partner channel:

11.2.1 What KAP provides

• The Real-Time Integrity Intelligence System™ platform (Cloud SaaS, customer cloud tenant, or on-premise / air-gapped tier).
• The 3D Gaussian Splatting facility model from the customer’s existing inspection imagery.
• The IOW / DMR six-stage analytical chain, including Stage 3.5 consistency gate and the cross-source correlation engine.
• Multi-modal AI anomaly detection across RGB, thermal, OGI, gas, and SCADA — surfaced through the natural-language operator interface.
• The bidirectional CMMS / IDMS integration (SAP PM Q4 2026, Meridium / Hexagon ALI H1 2027).
• All platform security, data-handling, and SLA commitments described in Deployment Architecture.

11.2.2 What the partner provides

11.2.3 The integrated workflow

The end-to-end operational workflow follows the IOW / DMR six-stage analytical chain documented in the Integrity Analytical Chain section, with the partner explicitly placed at the Stage 3.5 / Stage 4 review seat:

All outputs are recommendations to a qualified human operator. KAP never writes to SCADA, never issues work orders autonomously, and never commands field equipment. Read-only enforcement is technical — OPC UA access rights restricted to Read / Subscribe; DMZ proxy rejects all Write / Call requests; firewall TCP/IP port restriction (4840 / 4843).

11.3 Commercial framework for partner-integrated engagements

The pilot framework, MSA framework, and subscription tiers in Appendices G and H apply unchanged in a partner-integrated engagement. The only commercial additions are:

11.4 Where this connects in the rest of the PRD

12 Appendix A. Feature Summary

Q4* = research-dependent, contingent on Q2 spike outcomes.

13 Appendix B. Research Classification and Spike Objectives

Features classified as “research-dependent” follow a structured validation protocol before engineering commitment.

14 Appendix C. Non-Functional Requirements

15 Appendix D. Version History

16 Appendix E. Glossary

3DGS 3D Gaussian Splatting — a photorealistic 3D rendering technique used to create navigable facility models from drone imagery.

ADR Architecture Decision Record — a formal document capturing a technical decision, its rationale, and consequences.

AG-UI Agent-UI protocol used for streaming AI responses and structured events from the backend to the frontend.

CDC Contextual Data Chat — a feature set (F-APP-02) that enables operators to query facility data in natural language.

CMMS Computerized Maintenance Management System — the systems operators use to track work orders and asset maintenance history. Kav AI does not write to CMMS autonomously; all outputs are operator-confirmed recommendations.

DMR Damage Mechanism Review — a structured assessment of the degradation modes that can affect specific equipment based on its service conditions, materials, and operating history.

IDMS Inspection Data Management System — the platform that holds CML history, inspection plans, compliance records, and RBI models. Kav AI integrates bidirectionally with IDMS platforms (SAP PM, Meridium, Hexagon ALI, orKsoft).

IEC 62443 The international standard series for industrial cybersecurity. Defines security levels and requirements for OT systems including SCADA and control networks.

IOW Integrity Operating Window — a set of process parameter limits within which equipment is expected to operate safely. Exceedances trigger the damage mechanism analytical chain.

KRSI Kav AI Robot Sensor Interface — the robot-ingestion and normalisation layer that accepts patrol telemetry and payload data from supported autonomous platforms.

MCP Model Context Protocol — the protocol that enables AI agents to call object detection models and other tools as structured, callable interfaces.

OGI Optical Gas Imaging — a camera technology that visualises gas emissions invisible to standard cameras.

OOD Out-of-Distribution — inputs that differ materially from the training distribution. Kav AI’s OOD detector flags these and routes them to a Review queue rather than surfacing them as production alerts.

OPC UA OPC Unified Architecture (IEC 62541) — the universal industrial middleware standard providing secure, platform-independent read access to SCADA systems, historians, and PLCs. Kav AI’s Q3 SCADA integration uses OPC UA.

P&ID Piping and Instrumentation Diagram — the engineering drawing that documents process equipment, piping, and instrumentation.

Purdue Model A hierarchical reference model for industrial control system network architecture, defining five levels from field devices to enterprise systems. Kav AI operates at Level 3.5 (IT/OT DMZ) and above.

RBI Risk-Based Inspection — the methodology (API 580/581) for prioritising inspection effort based on the probability and consequence of equipment failure. Kav AI’s IOW/DMR chain produces API 581-aligned risk scores and inspection plans.

RLS Row-Level Security — database access control ensuring each operator can only access their organisation’s data.

SCADA Supervisory Control and Data Acquisition — the operational backbone of industrial facilities, collecting real-time sensor data from field devices. Kav AI reads from SCADA via OPC UA; it never writes to or replaces SCADA.

Solomon Associates An industry benchmarking organisation maintaining comparative databases of refinery and petrochemical plant performance. Kav AI uses Solomon benchmarks as the validation baseline for corrosion rates, equipment life estimates, and damage-mechanism statistics.

SOC 2 Service Organization Control 2 — a security certification audit framework widely required by enterprise customers.

17 Appendix F. Technical Integration Specification

This appendix defines the technical requirements and validated configurations for integrating Kav AI with an operator’s existing OT and IT infrastructure. It is intended for the operator’s OT engineering team and IT security department during procurement technical review.

17.1 F.1 OPC UA connector — supported configurations

Kav AI’s SCADA integration uses OPC UA (IEC 62541) in read-only subscription mode. The connector has been tested against the following OPC UA server implementations:

17.2 F.2 Data ingestion parameters

17.3 F.3 Historian compatibility

17.4 F.4 Visual sensor compatibility

Kav AI is hardware-agnostic. The platform ingests data from any visual sensor source that produces output in supported formats.

17.5 F.5 Network and firewall requirements

17.6 F.6 Infrastructure requirements by deployment tier

18 Appendix G. Pilot Framework

This appendix defines the standard 90-day proof-of-concept framework Kav AI uses for new enterprise customers. The pilot is designed to deliver a defensible, data-backed success evaluation before any long-term contract commitment is required.

18.1 G.1 Standard pilot scope

18.2 G.2 Pilot timeline

18.3 G.3 Success criteria

Success criteria are agreed in writing between Kav AI and the operator before data ingestion begins. The standard criteria set is defined below. Operators may substitute or add criteria by agreement.

18.4 G.4 Responsibilities matrix

18.5 G.5 Pilot commercial terms

19 Appendix H. Master Services Agreement Framework

This appendix describes the key commercial and legal positions Kav AI takes in its Master Services Agreement (MSA). It is intended to accelerate legal review by identifying Kav AI’s standard positions and areas where negotiation is anticipated. The full MSA template is provided separately by Kav AI’s legal counsel upon request.

This appendix is a summary of Kav AI’s standard MSA positions for discussion purposes. It does not constitute legal advice and does not supersede the executed MSA. Operators should engage their own legal counsel to review the full agreement.

19.1 H.1 Key MSA provisions

19.2 H.2 Subscription tiers

Pricing is indicative. Final pricing provided in a separate commercial proposal. Volume discounts available for multi-facility and multi-year commitments.

19.3 H.3 Anticipated legal review areas

Based on Kav AI’s experience with enterprise procurement in the oil and gas sector, the following provisions typically require negotiation or additional schedules during legal review. Kav AI’s legal counsel is prepared to engage on all of these.

• Data residency schedules for operators subject to specific jurisdictional requirements (e.g. Canadian data sovereignty, EU GDPR, US ITAR)

• Security addenda for operators with their own information security standards (e.g. ISO 27001, NIST CSF, or internal OT security frameworks)

• Subprocessor lists and approval rights, particularly for cloud infrastructure providers and LLM API vendors

• Incident response and notification procedures, including integration with the operator’s existing incident response plan

• Change control procedures for material platform updates that may affect integrated workflows

• Export control compliance for operators subject to US EAR or ITAR restrictions on technology transfer