Governance workflow engine managing Management of Change, corrective actions, escalation chains, decision journals, and lessons learned across the asset integrity lifecycle.
The Management of Change (MOC) workflow is one of the most safety-critical processes in asset integrity management, required by OSHA PSM 1910.119(l) and EPA RMP. Reliatic implements a six-stage MOC workflow with enforced gate-keeping at each transition. Draft: The initiator creates the MOC request, describing the proposed change, its scope (equipment, process conditions, materials, operating procedures), the technical justification, and the affected assets. Draft MOCs are visible only to the initiator and can be edited freely. Submitted: The initiator marks the MOC as ready for review. At this point, the platform records the submitter identity, the submission timestamp, and prevents further editing of the core change description without creating a new revision. The system automatically identifies affected assets and queues their damage mechanism assessments and FMEA reviews for update. Review: The MOC enters the review queue for the designated technical authority. Reviewers can add comments, request additional information (which sends the MOC back to the initiator), or advance to approval. Multiple reviewers can be assigned for complex changes, and the platform tracks each reviewer's disposition. Approved: Only users with the APPROVE_MOC permission (restricted to admin roles) can advance a MOC to approved status. The approval is recorded in the immutable audit log with the approver's identity and timestamp. Approved MOCs generate action items for implementation. Implementing: The approved change is being executed. Implementation tasks are tracked as linked actions with individual owners, due dates, and completion evidence. The MOC cannot advance to closed until all implementation actions are verified. Closed: All implementation actions are complete, post-change inspections (if required) are done, and operating procedures are updated. The MOC record is sealed and becomes a permanent part of the facility's change history.
Corrective actions, FMEA mitigations, inspection findings, and MOC implementation tasks all follow a standardized action lifecycle in Reliatic. Draft: The action is being defined. The creator specifies the description, the type (corrective, preventive, detective, or improvement), the affected asset(s), the priority, and the target completion date. Draft actions are not yet visible in team workloads. Proposed: The action has been submitted for review and approval. The designated approver (typically the reliability engineer or asset owner) reviews the action for technical adequacy and resource availability. Proposed actions appear in the approval queue. Approved: The action has been approved for execution. At this point, it appears on the assigned owner's task list and is counted in workload metrics. The approval timestamp and approver identity are recorded. In Progress: Work on the action has begun. The assignee can attach evidence (photos, reports, measurement data), update progress notes, and log time spent. Status changes are tracked in the audit log. Verification: The action has been completed by the assignee and is awaiting verification by an independent reviewer. Verification ensures that the action was executed as planned and achieved its intended risk reduction. For FMEA-linked actions, verification includes rescoring the failure mode to confirm the expected RPN reduction. Closed: The action has been verified and is complete. The closure timestamp, verifier identity, and any final notes are recorded. Closed actions cannot be reopened — if further work is needed, a new action must be created referencing the original.
Reliatic enforces service level agreements (SLAs) on every action and approval in the system. When an item exceeds its SLA, the platform triggers an escalation chain. SLA Definitions: Each action priority level has a default SLA: Critical actions must be completed within 7 days, High within 30 days, Medium within 90 days, and Low within 180 days. Approval SLAs are shorter: MOC reviews must be completed within 5 business days, and action approvals within 3 business days. These defaults are configurable per tenant. Level 1 Escalation (Warning): At 75% of the SLA duration, the assigned owner receives a notification reminding them of the approaching deadline. The item is flagged yellow in dashboards and work lists. Level 2 Escalation (Overdue): When the SLA expires, the item is flagged red and the owner's manager (the team lead or asset owner) is notified. The overdue item appears in the management dashboard and in weekly compliance reports. Level 3 Escalation (Critical Overdue): At 150% of the SLA duration, the item is escalated to the tenant administrator and appears in executive reporting. A formal overdue justification is required from the owner, which is recorded in the audit log. All escalation events are logged immutably. The escalation chain ensures that no action or approval silently stalls — there is always a next-level reviewer who is aware and accountable.
Every significant decision in the platform is recorded in the decision journal — an immutable, hash-chained audit log that provides a complete forensic trail for regulatory audits, incident investigations, and management reviews. What gets recorded: Every state transition in the MOC and action workflows, every risk assessment score change, every FMEA score update, every inspection result entry, every approval and rejection with the decision-maker's identity, and every escalation event. The decision journal captures not just what happened, but who decided, when they decided, and what information was available at the time. Why it matters: In a regulatory investigation following an incident, the decision journal demonstrates that the organization followed its risk management procedures. It shows that risks were assessed, that high-priority actions were assigned and tracked, that MOC requests were reviewed by qualified personnel, and that escalations were triggered when timelines were not met. The hash-chain integrity ensures that the journal cannot be retrospectively altered — each entry's cryptographic hash includes the previous entry's hash, making any tampering detectable. Implementation: The audit log uses database triggers to capture events automatically, removing the possibility of application-level bypass. Immutability is enforced by database policies that prevent UPDATE and DELETE operations on the audit log table. The hash chain is computed server-side using SHA-256, with each entry hashing the concatenation of the previous hash, the event type, the actor, the timestamp, and the event payload.
After an incident, a near-miss, or the closure of a significant MOC or corrective action, Reliatic supports a structured lessons learned workflow to capture and disseminate organizational knowledge. Capture: The lessons learned record captures what happened (the event), why it happened (the root cause or contributing factors), what was done about it (the corrective actions taken), and what should be done differently in the future (the recommendation). Each lesson is tagged with the relevant damage mechanism, equipment type, and operational context to enable future retrieval. Review and Approval: Lessons learned are reviewed by the technical authority to ensure accuracy and to generalize the findings beyond the specific incident. The reviewer may expand the applicability — for example, a lesson learned from a specific heat exchanger failure may apply to all heat exchangers in similar service. Dissemination: Approved lessons learned are surfaced to relevant teams based on their asset portfolios and roles. When an engineer creates a new FMEA, the platform surfaces relevant lessons learned from similar equipment and damage mechanisms. When a MOC is submitted for equipment in a service where a previous lesson was recorded, the lesson is displayed as context for the reviewer. Effectiveness Tracking: Lessons learned are linked to the actions they generate. The platform tracks whether the recommended actions were implemented and whether similar incidents recurred, providing a measure of organizational learning effectiveness. This closed-loop system transforms individual incidents into organizational capability, ensuring that knowledge gained from failures is systematically applied to prevent recurrence.