KavAI Platform (KAP)

Real-Time Integrity Intelligence System™

Investigate & Escalate

Version: 3.12

Date: 2026-09-03

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 closes 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. The loop is multi-modal by design and built one modality at a time: it runs today on inspection imagery (RGB and thermal), adds field survey readings in Q3, and gains OGI and process telemetry in Q4 — the same six-stage chain, entered from each new evidence stream as it arrives (see The chain by evidence modality in the Integrity Analytical Chain section). The loop extends through autonomous robot patrols, fixed plant infrastructure, and CAD / engineering context. The operating posture is 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 one closed-loop analytical chain — observed anomaly, damage mechanism review, engineering decision, risk, recommended action — entered today from inspection evidence and, from Q4 2026, from Integrity Operating Window (IOW) exceedances through Damage Mechanism Reviews (DMRs) to prioritized 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 >10x 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 labeled 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. The platform has moved from a blank canvas to a live alpha with three foundation milestones delivered and the Q2 AI milestone closed on production — its workspace surface running on alpha as a functional prototype.

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. Each capability and MVP table below carries an explicit delivery-state Status.

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 / v0.5 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. Across both quarters the integrity chain grows one evidence modality at a time — inspection imagery now, field survey readings, then OGI and process telemetry — rather than waiting for the last input to arrive.

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 H2 2027 and beyond — Roadmap

The following capabilities are directional and sit beyond the committed milestones (M0–M7). Autonomous patrol and navigation left this table in v3.10 — it is now committed as M6 (Q1 2027) and M7 (Q2 2027) above. They are documented so procurement teams can see the long-term direction, but the current platform focus is downstream refinery and petrochemical.

4.4 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. The same orchestration layer is the convergence point for robot patrol findings, CAD-linked asset identity, and cross-source confirmation. The cross-source confirmation engine is the user-facing primitive: 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

The platform extends in the two areas that most materially strengthen the integrity loop: autonomous robot coverage and CAD / engineering context. Two structural choices anchor that scope: 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 localizes 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 a hardware-agnostic position: robot data is an input layer, not a product-category shift.

High-hazard and regulated-environment deployments — including dose-aware operations (radiation dosimetry and high-dose zone handling) — are on the H2 2027 roadmap; the current platform focus is downstream refinery and petrochemical. See the Q4 / H2 2027 roadmap in the Journey section.

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 design target 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 extends the proven KRSI 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

The engineering context layer is a central extension to the integrity workflow rather than a standalone visual feature: CAD overlay is integrated directly into how integrity findings are mapped, validated, and explained. It is built on open, vendor-neutral standards — IFC4 (BIM STEP) for physical 3D geometry and DEXPI (XML) for logical P&IDs — rather than proprietary exports.

5.2.1 Per-format scope

5.2.2 Logical P&IDs via DEXPI and tag interoperability

Physical geometry (IFC4) is paired with logical process structure through DEXPI (XML), the open P&ID exchange standard, which carries equipment, nozzles, piping runs, and connectivity. A deterministic dual-tagging layer reconciles legacy CAD tag conventions with standard operator / DEXPI tags and resolves both to the same asset record — so a 3D element, its P&ID, and its integrity findings line up automatically. The mapping is rule-based and auditable rather than inferred.

On one example process unit — a 109-asset reference dataset — the IFC4 and DEXPI schemas were both ingested at 100% coverage, confirming traceability from the 3D model through the P&ID to the asset record for that deployment. The figure is a single illustrative example, not a generalized benchmark.

5.2.3 World model and change management

CAD only becomes operationally useful when tied to the live spatial record. The platform 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. The cross-source correlation engine is the named primitive that does this work:

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. The external claim follows directly: multi-source confirmed findings target TPR > 98% / FPR < 2%, while single-source modality-specific targets are documented in Operations.

Cross-source confirmation does not replace engineering validation. It improves prioritization, 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. This chapter consolidates the MVP v0.2 evidence 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 organizing 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 How to Evaluate Kav AI — The 90-Day Pilot

The fastest way to test whether Kav AI delivers value at your facility is a structured 90-day pilot run against your own data. The full framework — timeline, success-criteria template, responsibilities matrix, and commercial terms — is in Appendix G. The summary below is what a buyer needs to decide whether to start one.

This sequence — evidence of what Kav AI has already done (Scale & Impact) → how to run a pilot (this section) → how the workflow operates day to day (Operational Workflow) — is the recommended reading path for a procurement team. The complete pilot framework, including the success-criteria thresholds and MSA positions, is in Appendix G and Appendix H.

8 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. The human-in-the-loop workflow accounts for robot-sourced findings, cross-source confirmation, and richer engineering context at the point of triage, with a cross-source confirmed performance target alongside the per-modality targets. A single canonical verification rule (below) applies consistently wherever the manual verification queue is referenced.

8.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. The triage packet includes source type (drone, robot, SCADA), patrol or campaign identifier, CAD-linked asset identity, and the explicit correlation category (single-source / corroborated / multi-source confirmed).
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, for non-Critical multi-source confirmed items, can shorten or skip the queue per the canonical verification rule. It never bypasses deterministic Filter Skill rejection or Stage 3.5 inconsistency flags, and Critical findings and Remaining Life adjustments always require individual engineer sign-off.
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. Pilot objective: reduce the ‘Triage-to-Work Order’ cycle from a typical 5–10 days to < 4 hours, benchmarked against M3 deployment. SAP PM remains the first certified connector priority because it opens the largest installed-base pathway.

8.1.1 From Finding to Action — A Worked Example

8.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):

All figures are targets for the quarter shown, not yet-delivered results; 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” target. Per the canonical verification rule above, it is the only class that may bypass the manual verification queue, and then only for non-Critical severity items — Critical findings and Remaining Life adjustments always require engineer sign-off, and all classes remain subject to the Filter Skill and Stage 3.5 consistency gate.

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

Kav AI is a decision-support tool, not an autonomous inspector. Consistent with the canonical verification rule above: no “Critical” severity output or “Remaining Life” adjustment can be finalized without individual engineer sign-off in the platform, regardless of how many independent sources corroborate the finding. The non-Critical queue-bypass available to multi-source confirmed findings does not extend to these items. Every such action is captured in the version-controlled audit trail.

8.4 Business Readiness & Referenceability

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

8.4.1 Cost Model & ROI Modeling

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.

8.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.

8.5.1 Bidirectional Integration Architecture (FR-INT-03)

8.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.

8.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 synchronized via scheduled SQL/Web API connectors.

8.5.4 Reference Customers

Kav AI works primarily with Tier-1 refineries in California and Texas. A third major inspection campaign at a U.S. refinery (Crude/Vacuum unit) is planned; ahead of it, the near-term data path is ingesting the operator’s existing inspection data. Reference calls with the lead Integrity Engineer can be facilitated upon request for qualified enterprise buyers.

8.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 program 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.

9 The Integrity Analytical Chain — Architectural Ownership

The integrity analytical chain — observed anomaly → damage-mechanism review → engineering decision → risk → recommended action — is the core intelligence differentiator of the Kav AI platform. It is one chain with several entries: modality-agnostic at the point of entry, so each evidence stream the platform ingests enters at Stage 1 and enables a different subset of the later stages. Today the chain is entered from inspection evidence — RGB and thermal campaign imagery, with field survey readings arriving in Q3 — and runs end to end as a functional prototype, closing with the engineer’s decision where quantified risk will later sit. From Q4 2026 it gains its process-telemetry entry (SCADA and historians via OPC UA), which is what turns Stage 2 into true Integrity Operating Window checks and makes Stage 5 quantifiable. This section defines the chain’s architecture and owner, the stages in their process-telemetry (IOW/DMR) form — the Q4 commitment — and then the same stages by evidence modality. The chain is strengthened by robot patrol evidence, CAD-linked asset identity, and cross-source confirmation. One clarification of the data flow: 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.

9.1 The six-stage analytical chain

In its process-telemetry form — the Q4 commitment — the chain runs from raw SCADA telemetry through to prioritized corrective action recommendations, benchmarked against the Solomon Associates database at the risk quantification stage. The stage definitions below are written for that form; The chain by evidence modality shows how each stage is entered from the other evidence streams.

The process-telemetry form of the chain becomes available from Q4 2026 when the SCADA/OPC UA connector is delivered (FR-INT-01). The chain itself is already entered from inspection evidence, as the next section shows. Stages 4 and 5 also draw on repeat patrol evidence, fixed-infrastructure continuous coverage, and engineering-context enrichment where present.

9.2 The chain by evidence modality

The chain is entered by modality. Each evidence stream Kav AI ingests has its own Stage 1 intake, and what differs between streams is not the stages but how far up the chain a finding can be carried on that evidence alone. The ladder below is the order in which the platform adds them; the matrix after it places every stage-by-modality cell in the shared status vocabulary of the Journey section.

Two statements keep this table honest. First, the inspection-imagery column closes the loop with the engineer’s recorded priority, not with a quantified risk score: remaining life needs thickness and API 581 risk needs consequence data, and neither comes from a photograph, so Stage 5 stays a Q4 commitment for every modality. Second, Alpha (prototype) means what the status key says — a functional prototype on the alpha lineage, not the production platform — and the inspection path has so far been exercised on a small number of findings rather than a full campaign. The requirements that would record each stage of the inspection path are proposed for the next revision (Appendix D, v3.11 item 5).

9.2.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 prioritized, 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.

9.2.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:

9.3 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.

9.3.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.

9.3.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.

9.3.3 Timestamp Integrity and Windowing

Correlation across heterogeneous sources (SCADA scan vs. Event-driven historians) is governed by a ±500ms synchronization 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-synchronized sources to maintain sub-second alignment in millisecond-sensitive environments.

9.3.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.

9.3.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.

9.4.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.

9.4.2 Consequence of Failure (CoF)

CoF is categorized into four primary streams:

1. Flammable/Explosive: Area-based consequence of fire/explosion.
2. Toxic Release: Dispersion modeling 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.

9.4.3 Ranked-to-Calibrated Transition

During the initial deployment and pilot phase (90 days), risk outputs are presented as Relative Risk Rankings for prioritization. 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.

10 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. The platform handles cross-source correlation, robot patrol evidence, and high-regulation requirements without weakening the core guardrails, and all safeguards follow a clear 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.

10.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.

10.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 labeling 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.

10.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: Corroboration across independent sources can increase confidence, but only after the output has survived deterministic validation.

10.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.

Cross-source extension: calibration is 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. The externally-quoted multi-source confirmed TPR > 98% / FPR < 2% target is 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 next labeled refinery dataset — the operator’s existing inspection data ahead of the planned third campaign — is available.

10.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.
• Distribution-expansion extension: High-endurance robot sessions, IFC/RVT metadata variance, fixed-infrastructure continuous-coverage telemetry, and highly regulated 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.

10.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.

10.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.

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. The priority order is explicit — Filter Skill > Stage 3.5 > cross-source uplift — so that the cross-source correlation engine cannot be misread as a Filter Skill bypass. Highly regulated deployments additionally require mandatory engineer review before any downstream CMMS handoff.

11 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 four infrastructure questions: where does the data go, who controls the model, can the system operate without cloud connectivity, and what changes when the site adopts persistent robot coverage and higher-regulation operating constraints. Aligned with the OI.Expert LOI commitments, on-premise / air-gapped deployments require no heartbeat, telemetry, or license callbacks of any kind.

11.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 license; server configuration often requires Siemens Professional Services.
• Ignition (Inductive Automation): Full native compatibility with built-in UA module.

The platform’s secrets management, encryption, container image signing, vulnerability scanning, and SBOM practices are documented in full in Appendix F.7 (Security Technical Reference) for the operator’s IT/OT security team.

11.2 Security and compliance targets

11.3 Fixed infrastructure deployment

Fixed-infrastructure additions are treated 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.

11.4 Regulated-environment considerations

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

12 Partner-Integrated Delivery Model

Kav AI’s customers do not buy a platform in isolation. They buy a working integrity program — 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. The platform supports 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.

12.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 finalized 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.

12.2 Reference partnership — OI.Expert × Kav AI

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

12.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 H2 2027).
• All platform security, data-handling, and SLA commitments described in Deployment Architecture.

12.2.2 What the partner provides

12.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).

12.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:

12.4 Where this connects in the rest of the PRD

13 Appendix A. Feature Summary

Q4 2026* = research-dependent, contingent on Q2 spike outcomes. The Status column uses the shared delivery-state vocabulary defined in the Journey section (Status key): Delivered / Alpha (prototype) / Demonstrated (simulated data) / In Progress (Q2) / Q3 Target / Q4 Target / Q1 2027 Target / Q2 2027 Target / H2 2027 Roadmap; it is consistent with the Quarter column.

14 Appendix B. Research Classification and Spike Objectives

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

15 Appendix C. Non-Functional Requirements

16 Appendix D. Version History

17 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 (FR-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.

CML Corrosion Monitoring Location — a specific point on equipment where wall-thickness measurements (typically by ultrasonic testing) are repeated over time to track corrosion rate. Kav AI registers CMLs in the 3D facility model with sub-centimeter precision.

DEXPI Data Exchange in the Process Industry — an open, vendor-neutral XML schema for exchanging logical P&ID data (equipment, nozzles, piping, and connectivity). Kav AI ingests DEXPI to read P&ID structure without proprietary lock-in.

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.

IFC / IFC4 Industry Foundation Classes — the open, vendor-neutral standard for Building Information Modeling (BIM) data exchange. Kav AI uses the IFC4 STEP format to represent physical process equipment (tanks, pumps, heat exchangers, compressors) and its geometry, materials, and properties.

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 normalization layer that accepts patrol telemetry and payload data from supported autonomous platforms.

LLM Large Language Model — the AI model class behind Kav AI’s natural-language interface and reasoning chain. Kav AI supports self-hosted LLMs (e.g., Llama-3-70B, Mistral-Large) in on-premise / air-gapped deployments.

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

NDT Non-Destructive Testing — inspection techniques (ultrasonic testing, radiography, eddy current, etc.) that measure equipment condition without damaging it. Kav AI’s Stage 4 physical validation uses NDT data as the ground truth for AI findings.

OGI Optical Gas Imaging — a camera technology that visualizes 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 Q4 SCADA integration uses OPC UA.

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

PIL Piping Inspection Location — a registered point on a piping circuit where inspection measurements are repeated. Analogous to CML but for piping rather than fixed equipment. Kav AI tracks PILs in the 3D facility model alongside CMLs.

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 prioritizing 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 organization’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 organization 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.

18 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.

18.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:

18.2 F.2 Data ingestion parameters

18.3 F.3 Historian compatibility

18.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.

18.5 F.5 Network and firewall requirements

18.6 F.6 Infrastructure requirements by deployment tier

18.7 F.7 Security technical reference

This subsection consolidates the granular security implementation detail referenced from the Deployment Architecture section. It is intended for the operator’s IT/OT security team during procurement technical review.

18.7.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).
• Credential rotation: Secrets are rotated through the managed secrets store rather than redeployed in image configuration.
• Encryption: All data is encrypted at rest using AES-256 and in transit via TLS 1.2/1.3.

18.7.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.

19 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.

19.1 G.1 Standard pilot scope

19.2 G.2 Pilot timeline

19.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.

19.4 G.4 Responsibilities matrix

19.5 G.5 Pilot commercial terms

20 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.

20.1 H.1 Key MSA provisions

20.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.

20.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