FOI Fuel Continuity Utility

Technical Brief 001

Platform Adaptive Access & Protected Evidence Architecture

Object ID: FCU-BRIEF-PLATFORM-001
Version: 1.0
Published: August 17, 2026
Publisher: FOI Laboratories

Abstract

The FOI Fuel Continuity Utility (FCU) establishes a governed continuity protocol for carrying critical fuel-quality events from physical asset identification through sampling, custody, laboratory performance, review, corrective action, verification, preservation, trending, and the next event.

This technical brief documents how an external enterprise platform may access that continuity environment without assuming governance of the fuel-continuity event or replacing its own role as an operational system of record.

The architectural principle is:

Identity crosses the doorway. Governance does not. Evidence returns across the doorway.

Enterprise platforms may initiate and reference the event.

The FOI Fuel Continuity Utility governs the specialized fuel-continuity protocol.

Preserved evidence is then returned to the enterprise management environment.

1. Standards Environment

The Fuel Continuity Utility operates within life-safety and emergency-power environments that may include requirements associated with:

NFPA 101 — Life Safety Code
NFPA 99 — Health Care Facilities Code
NFPA 110 — Standard for Emergency and Standby Power Systems

These standards establish applicable life-safety, health-care risk, emergency-power performance, maintenance, testing, and operating requirements.

The FOI Fuel Continuity Utility does not replace NFPA standards, an Authority Having Jurisdiction, regulatory authority, facility responsibility, engineering judgment, or the customer’s existing system of record.

The FCU governs only FOI’s continuity protocol for connecting and preserving the fuel-quality event.

2. Utility Genesis

The Fuel Continuity Utility is the governing architecture from which the operational workflow is expressed.

The hierarchy is:

Standards Environment
↓
FOI Fuel Continuity Utility
↓
Governed Continuity Protocol
↓
Adaptive Platform Access
↓
Operational Workflow Event
↓
Preserved Evidence

The workflow is therefore an operational expression of the Utility.

3. The Governed Fuel-Continuity Rail

The FCU carries the event through the following continuity sequence:

IDENTIFY → SAMPLE → CUSTODY → LABORATORY PERFORMANCE → REVIEW → CORRECT → VERIFY → PRESERVE → TREND → NEXT EVENT

Each stage maintains a relationship to the same physical asset and continuity event.

The purpose is to prevent critical fuel-quality information from becoming separated across people, contractors, laboratories, maintenance systems, reports, or successive service events.

4. Doorway Does Not Equal Integration

The FCU uses an Adaptive Access architecture.

An enterprise platform does not need to absorb, duplicate, or govern the Fuel Continuity Utility in order to make the workflow available to its users.

Instead, the platform provides a doorway into the Utility.

Platform Environment

The external platform may continue to manage:

Facility identity
Asset identity
Generator or EPSS records
Tank records
Preventive maintenance
Work orders
Users
Contractors
Schedules
Historical maintenance records
Operational documentation

FOI Utility Environment

The FCU manages the specialized fuel-continuity event, including:

Fuel-event identity
Sample event
Sample Information Form
Chain of custody
Laboratory receipt
Laboratory performance
Laboratory evidence
Review
Corrective-action continuity
Verification
Preservation
Fuel-quality trending
Next-event continuity

The two systems remain distinct while sharing sufficient identity to maintain traceability.

5. Platform Remains the System of Record

The enterprise platform remains the customer’s primary operational management environment.

The FCU does not seek to replace:

CMMS
EAM
Facility-management software
Generator-management systems
Engineering systems
Preventive-maintenance systems
Work-order systems

The platform can initiate the fuel-quality event and later receive the resulting continuity evidence.

The relationship is:

PLATFORM ENVIRONMENT
Facility / Asset / PM / Work Order / User
↓
ADAPTIVE ACCESS DOORWAY
↓
FOI FUEL CONTINUITY UTILITY
Identify → Sample → Custody → Laboratory → Review → Correct → Verify → Preserve → Trend
↓
AUDIT-READY ARTIFACTS / STATUS
↓
RETURN TO PLATFORM SYSTEM OF RECORD

6. Three-Part Identity Model

A platform-accessed continuity event should preserve three separate but related identifiers.

PLATFORM OBJECT ID

Owned and governed by the external enterprise platform.

Example:

PLATFORM_OBJECT_ID

FCU EVENT ID

Created and governed by the FOI Fuel Continuity Utility.

Example:

FCU_EVENT_ID

PHYSICAL SAMPLE ID

Identifies the physical evidence entering the laboratory and custody environment.

Example:

PHYSICAL_SAMPLE_ID

The relationship is:

PLATFORM_OBJECT_ID ↔ FCU_EVENT_ID ↔ PHYSICAL_SAMPLE_ID

This allows both systems to preserve their native identities without requiring either system to surrender governance of its own records.

7. Platform-to-FCU Initiation Payload

An enterprise platform may initiate a continuity event using a limited identity and intent payload.

Example fields may include:

PLATFORM_EVENT_ID
FACILITY_ID
FACILITY_NAME
ASSET_ID
ASSET_NAME
EPSS_ID
TANK_ID
WORK_ORDER_ID
PM_ID
USER_ID
USER_ROLE
EVENT_REASON
REQUESTED_ACTION
EVENT_TIMESTAMP
PLATFORM_RETURN_REFERENCE

The platform establishes the operational context.

The FCU then establishes the governed continuity event.

8. FCU Continuity Event Record

The FCU creates its own continuity object.

Example:

FCU_EVENT_ID
PLATFORM_EVENT_ID
FACILITY_ID
ASSET_ID
SAMPLE_EVENT_ID
SAMPLE_ID
EVENT_STATE
SIF_RECORD
CUSTODY_STATE
LAB_RECEIPT_STATE
TEST_PACKAGE
LAB_RESULT_REFERENCE
REVIEW_STATE
CORRECTIVE_ACTION_STATE
VERIFICATION_STATE
PRESERVATION_STATE
TREND_REFERENCE
NEXT_EVENT_STATE
CREATED_TIMESTAMP
LAST_STATE_CHANGE

The external platform record is referenced but not overwritten.

9. Protected Evidence Objects

Evidence should remain distinct from workflow interpretation.

Protected evidence may include:

Sample Information Form
Chain-of-custody records
Laboratory receipt records
Raw laboratory data
Released laboratory reports
Photographs
Fuel-delivery records
Vendor service records
Corrective-action documentation
Verification testing
Inspection records
Supporting documents

A representative evidence object may include:

EVIDENCE_ID
FCU_EVENT_ID
EVIDENCE_TYPE
SOURCE
CREATED_BY
CREATED_TIMESTAMP
RECEIVED_TIMESTAMP
DOCUMENT_REFERENCE
LAB_DATA_REFERENCE
CUSTODY_REFERENCE
VERIFICATION_REFERENCE
VERSION
INTEGRITY_HASH
SUPERSEDES
PRESERVATION_STATUS

Workflow logic may evolve.

Preserved evidence should remain attributable to the event that created it.

10. FCU-to-Platform Return Payload

Upon completion or meaningful state transition, the FCU may return a controlled evidence and status payload to the enterprise platform.

Example:

PLATFORM_EVENT_ID
FCU_EVENT_ID
FACILITY_ID
ASSET_ID
EVENT_STATUS
SAMPLE_ID
SAMPLE_DATE
LAB_COMPLETION_DATE
TEST_PACKAGE
RESULT_STATUS
CORRECTIVE_ACTION_STATUS
VERIFICATION_STATUS
CONTINUITY_STATUS
CONTINUITY_SUMMARY
REPORT_REFERENCE
CUSTODY_REFERENCE
EVIDENCE_PACKAGE_REFERENCE
TREND_REFERENCE
FOI_LIMS_DEEP_LINK
COMPLETION_TIMESTAMP
INTEGRITY_REFERENCE

The enterprise platform does not need the entire internal FCU data structure.

It receives the status and evidence necessary to preserve the operational history.

11. Continuity Summary

The return payload may include a human-readable field called:

CONTINUITY_SUMMARY

Its purpose is to allow an enterprise platform, facility manager, engineer, or authorized AI assistant to understand the current state of the continuity event without reconstructing the complete evidence record.

Example:

NFPA 110 fuel-quality event completed. Laboratory performance preserved. Corrective action verified. Continuity record current.

The summary describes the record.

It does not replace the underlying evidence.

12. Deterministic Event States

A fuel-continuity event may progress through defined states such as:

CREATED
IDENTIFIED
SAMPLED
IN_CUSTODY
RECEIVED
LAB_IN_PROCESS
LAB_COMPLETE
REVIEWED
ACTION_REQUIRED
NO_ACTION_REQUIRED
CORRECTED
VERIFIED
PRESERVED
NEXT_EVENT

These states allow the enterprise platform to reflect a simple operational status while the FCU preserves the detailed supporting evidence.

Example:

Fuel Continuity Event — Verification Pending

13. AI May Assist — AI Does Not Govern

Artificial intelligence may assist within the FCU environment, but it does not become the authoritative continuity record.

AI-Assisted Functions May Include

Information discovery
Workflow explanation
Education
Historical comparison
Trend recognition
Anomaly identification
Workflow routing
Scheduling assistance
Decision support
Continuity-summary generation

Protected Evidence Includes

FCU event identity
Physical sample identity
Facility and asset identity
Collector identity
Chain-of-custody events
Custody timestamps
Laboratory receipt
Raw laboratory measurements
Laboratory release records
Corrective-action evidence
Verification evidence
Preserved document versions
Integrity references

AI may reason about protected evidence when authorized.

AI does not silently alter protected evidence or become the source of the authoritative continuity record.

14. Evidence Integrity

The FCU architecture is designed to support traceability, integrity, version control, and auditability.

Important continuity transitions may preserve integrity references associated with events such as:

Event Established
↓
Sample Identity Established
↓
Custody Established
↓
Laboratory Evidence Released
↓
Corrective Evidence Added
↓
Verification Completed
↓
Continuity Event Preserved

Technical controls may include:

Authenticated users
Controlled permissions
Append-only audit history
Immutable or protected timestamps
Evidence versioning
Cryptographic hashes
Controlled laboratory release
Document provenance
Supersession records
Event-state history

These controls support evidence traceability and integrity.

They do not independently establish statutory compliance or legal admissibility.

15. Platform Example — Accruent

Accruent represents one example of how an enterprise platform may access the Fuel Continuity Utility.

An Accruent environment may continue to govern:

Facility → Asset → Generator → Tank → PM → Work Order → User → Historical Record

A doorway may then provide access to:

FOI FCU → Sample Event → Custody → Laboratory Performance → Review → Correct → Verify → Preserve → Trend

FOI can return:

Laboratory report
Event status
Chain-of-custody artifact
Corrective-action documentation
Verification documentation
Continuity summary
LIMS reference
Preserved evidence package

Accruent remains the system of record.

FOI remains the governing environment for the FCU fuel-continuity protocol.

This same architecture may be adapted to other qualified enterprise platforms.

16. Life-Safety Workflow Entry

A physical life-safety fuel sample may serve as an operational doorway into the Fuel Continuity Utility.

The workflow becomes:

Identify Asset
↓
Life-Safety Sample Event
↓
Sample Information Form
↓
Chain of Custody
↓
Laboratory Performance
↓
Review
↓
Corrective Action
↓
Verification
↓
Preserved LIMS Record
↓
Trend History
↓
Next Event

The sample is therefore not treated as an isolated bottle or laboratory report.

It becomes part of a preserved continuity history associated with the physical asset.

17. Architectural Principle

The FCU platform interface can be summarized in four statements:

The platform sends identity and intent.

The Fuel Continuity Utility establishes and governs the continuity event.

Evidence accumulates and is preserved through the rail.

Status and audit-ready artifacts return to the platform system of record.

And the governing interface rule remains:

IDENTITY CROSSES THE DOORWAY. GOVERNANCE DOES NOT. EVIDENCE RETURNS ACROSS THE DOORWAY.