Incident records: preserve facts, uncertainty and restricted access

Topics: oil and gas incident reporting, near miss record taxonomy, incident investigation evidence, EHS reporting data quality

How premature root-cause drop-downs and open permissions corrupt incident records

When an abnormal event occurs on an oil and gas installation—a compressor seal gas release, a crane load drop, or a high-potential (HiPo) hydrogen sulfide (H2S) detector alarm—statutory frameworks including OISD Incident Investigation Standards, DGMS Oil Mines Regulations 2017, and the Ministry of Labour and Employment New Labour Codes (OSHWC Code) require prompt initial notification followed by a formal technical investigation.

Most enterprise EHS software forms, however, sabotage investigation integrity through three structural design flaws:

1. Mandatory "Root Cause" Selection on Day-1 Initial Notifications: To submit an initial 24-hour Flash Incident Report, the EHS portal forces the shift supervisor to select a mandatory Root_Cause_Code from a drop-down menu before metallurgists, instrument engineers, or process safety specialists have even inspected the equipment. Faced with a required field, the supervisor selects Operator Procedure Non-Compliance or Equipment Component Failure. Months later, even after metallurgical lab testing proves high-temperature sulfidation corrosion was the true cause, the initial unverified guess remains in corporate BI extracts.
2. Overwriting Early Uncertainty Instead of Versioning Epistemic State: During a complex process upset, the estimated hydrocarbon release quantity or ignition source is initially bounded by a wide confidence interval (e.g., Estimated Release: 150 kg to 420 kg based on blowdown valve duration; orifice upstream pressure sensor PT-402 under calibration check). When systems lack dedicated uncertainty fields, engineers either type a false single-point guess (250 kg) that gets cited as hard fact in regulatory filings, or overwrite the initial record without preserving how and why the calculation evolved.
3. Unrestricted Exposure of Medical, Witness, and Privileged Records: Storing unredacted witness interview statements, occupational clinic medical notes, and operator badge IDs in the same world-readable EHS table as technical equipment lessons violates worker privacy, chills psychological safety during witness interviews, and breaches NIST SP 800-82 Rev. 3 and enterprise access-control governance.

Takeaway: Never force a Day-1 root-cause drop-down or expose witness and medical records in general EHS tables; version epistemic certainty over time and compartmentalize PII/legal sub-records.

Structural rules for high-integrity incident records

1. Epistemic state tagging on every claim (FACT, UNCERTAIN_ESTIMATE, HYPOTHESIS, VALIDATED_FINDING)

Instead of overwriting fields as the investigation progresses from Hour 1 to Day 30, every statement and numeric parameter in the incident record carries an explicit epistemic status:

• VERIFIED_PHYSICAL_FACT: Corroborated by an immutable physical source—e.g., Sequence-of-Events (SOE) trip log showing Emergency Shutdown Valve ESDV-104 closed at 14:02:11.420 UTC, or fixed gas detector GD-209 peaking at 42% LEL.
• BOUNDED_UNCERTAIN_ESTIMATE: Numeric parameters (such as fugitive hydrocarbon mass released or peak local temperature) where exact measurement was not possible. Stored as [lower_bound, best_estimate, upper_bound, estimation_methodology, confidence_status] rather than a deceptive single scalar.
• CANDIDATE_HYPOTHESIS: Potential causal mechanisms mapped on the investigation fault tree. Every candidate hypothesis must remain visible in the investigation log until it is explicitly marked either REFUTED_BY_EVIDENCE (citing the test report that ruled it out) or CONFIRMED_BY_EVIDENCE.
• VALIDATED_SYSTEMIC_FINDING: Populated only when the Qualified Investigation Owner and Technical Authority sign off on the completed investigation report.

2. Three-partition Role-Based Access Control (RBAC)

A single incident record (INC-2026-0118) is physically partitioned across three security envelopes:

1. PARTITION_A_TECHNICAL_LEARNING (Broad Read Access across Operations & Engineering): Contains de-identified timeline facts, process conditions, barrier performance (Bow-Tie prevention and mitigation barrier states), metallurgical/instrument findings, and corrective actions (CAPAs). Contains zero worker names, badge numbers, or clinical diagnoses.
2. PARTITION_B_INVESTIGATION_WORKING_FILE (Restricted to Active Investigation Team & Data Steward): Contains witness interview transcripts, shift log sign-in sheets, and unconfirmed working hypotheses (Layer 2). Access expires automatically when the investigation closes, leaving only the Data Steward and EHS Authority with audit read rights.
3. PARTITION_C_MEDICAL_AND_LEGAL_VAULT (Restricted to Occupational Health Physician, Statutory Reporting Officer, and Legal Counsel): Contains injured worker PII, clinic treatment logs, statutory DGMS / MoLE individual notice forms, and legally privileged counsel assessments. Hard-blocked from all BI dashboards, data lakes, and analytics pipelines.

3. Prohibition of automated blame or worker risk scoring

In alignment with modern process safety governance, the system enforces a hard prohibition against using incident participation logs to calculate "worker error scores," "repeat offender rankings," or automated disciplinary triggers. When human performance is involved in an event, the schema requires documenting the systemic barrier context (e.g., alarm flood rate > 40 alarms per 10 minutes, conflicting valve tag labels, or fatigue status).

Illustrative example (hypothetical scenario): 40 plant incident records across initial and final stages

Illustrative scenario notice: All site volumes, defect counts, error rates, engineering hours, and INR (₹) figures below are hypothetical scenario assumptions constructed to demonstrate the control math and workflow gating. Any time or cost reductions represent modeled process/capacity estimates under these assumptions, not achieved client benchmark savings or guaranteed cash realization.

Consider an internal quality and governance audit of 40 process safety and operational incident records logged across a gas processing complex over two quarters (1,000 total timeline, quantity, and causal data attributes evaluated by the EHS Data Steward):

• Before Epistemic & Partition Controls (Historical Baseline):
  • 62.5% (25 of 40) of initial 24-hour reports had a premature Root_Cause_Code selected on Day 1; in 17 of those 25 cases (68.0%), the final metallurgical or instrumentation investigation contradicted the Day-1 drop-down code.
  • 100% of release-quantity estimates were recorded as single numbers without uncertainty bounds, requiring 11 formal regulatory amendment letters when dispersion calculations were refined.
  • Witness names or medical treatment notes appeared in general free-text narrative fields in 9 of 40 records (22.5%).
• After Deploying the 3-Layer Epistemic & Partitioned Schema (40 New Incident Records):
  • Premature Day-1 Root Cause Assignment: 0 / 40 (0.00%) (field hard-locked as PENDING_INVESTIGATION_COMPLETION until the Qualified Investigation Owner signs Layer 3).
  • Bounded Uncertainty Compliance on Release Estimates: 40 / 40 (100.0%) of initial reports store [min_kg, max_kg, calculation_basis] intervals, reducing subsequent unscheduled regulatory retraction filings to 0.
  • Hypothesis Refutation Traceability: Across the 40 investigations, 136 candidate fault-tree hypotheses were logged in Layer 2; 92 (67.65%) were formally closed as REFUTED_BY_EVIDENCE with attached lab/test proofs, and 44 (32.35%) were promoted to VALIDATED_SYSTEMIC_FINDING in Layer 3.
  • PII / Medical Leakage in Partition A (Technical Learning View): 0 / 40 (0.00%) after automated PII pattern scanning and Data Steward pre-publication review.

Takeaway: Preserving the 92 refuted hypotheses alongside their disproving test reports prevents future teams or external regulators from re-litigating ruled-out theories.

Technical implementation: partitioned epistemic incident record schema

{
  "incident_id": "INC-O068-2026-0118",
  "facility_id": "GAS-PLANT-HAZIRA-02",
  "event_timestamp_utc": "2026-10-14T14:02:11Z",
  "investigation_stage": "FINAL_VALIDATED_CLOSED",
  "partition_a_technical_record": {
    "access_scope": "FLEET_ENGINEERING_AND_OPERATIONS",
    "pii_redaction_verified_by_steward": "STEWARD-HSE-03",
    "layer_1_verified_facts": [
      {
        "fact_id": "F-01",
        "timestamp_utc": "2026-10-14T14:02:11.420Z",
        "description": "High-pressure separator relief bypass flange leaked sour gas; fixed detector GD-209 peaked at 42% LEL; ESDV-104 isolated train in 4.2 seconds.",
        "source_evidence_ref": "HIST-SOE-20261014-HASH-88A1"
      }
    ],
    "layer_2_uncertainty_and_hypotheses": {
      "release_mass_estimate_kg": {
        "lower_bound_kg": 150.0,
        "best_estimate_kg": 245.0,
        "upper_bound_kg": 420.0,
        "methodology": "API 521 orifice blowdown integration over 180s depressuring curve"
      },
      "evaluated_hypotheses": [
        {
          "hypothesis_id": "H-01",
          "statement": "Thermal relief valve PSV-204B chattered due to excessive backpressure.",
          "disposition": "REFUTED_BY_EVIDENCE",
          "proof_ref": "WORKSHOP-POP-TEST-PSV204B-PASS"
        },
        {
          "hypothesis_id": "H-02",
          "statement": "Spiral-wound gasket installed during May turnaround lacked inner ring required for Class 900 sour service.",
          "disposition": "CONFIRMED_BY_EVIDENCE",
          "proof_ref": "METALLURGY-LAB-REP-2026-441"
        }
      ]
    },
    "layer_3_validated_findings": {
      "qualified_investigation_owner": "INV-LEAD-PSM-07",
      "signed_at_utc": "2026-10-20T09:30:00Z",
      "failed_prevention_barriers": ["Material Receiving PMI/Spec Check", "Flange Make-Up QA Checklist"],
      "systemic_root_cause": "Warehouse BOM for Class 900 sour-service flanges permitted substitution of non-inner-ring gasket part number.",
      "worker_blame_score_computed": false
    }
  },
  "partition_b_witness_vault_ref": "VAULT://INC-2026-0118/WITNESS-ENCRYPTED-PACK",
  "partition_c_medical_legal_vault_ref": "VAULT://INC-2026-0118/MED-LEGAL-RESTRICTED"
}

Acceptance tests and operational readiness thresholds

Summary and next actions

1. Remove mandatory root-cause drop-downs from initial incident notifications: Lock root-cause fields on Day-1 flash reports so supervisors record only verified physical facts, immediate containment actions, and explicit questions under investigation.
2. Store early numerical estimates as bounded intervals with methodology notes: Require [lower_bound, best_estimate, upper_bound] and calculation basis on initial release or damage estimates rather than forcing false single-point precision.
3. Preserve refuted fault-tree hypotheses in the permanent record: Log every tested hypothesis alongside the lab or field evidence that ruled it out so the investigation audit trail proves thoroughness.
4. Segregate witness transcripts and medical/legal files into restricted vaults: Partition the incident record so broad engineering and safety teams receive sanitised barrier lessons (Partition A) while PII, witness statements, and medical data remain locked behind strict RBAC (Partitions B & C).