An inspection file can tell an engineer what was recorded. A map can show where an asset sits. A supporting document can explain what the numbers alone cannot. But when those pieces live apart, even a simple question—what does this finding mean for this stretch of pipeline?—becomes a search across files, tables and locations.
An Asset Integrity Management System (AIMS) is built around that gap. Rather than treating upload as the finish line, it connects source material to structured records and geographic context in one engineering workspace. The aim is to make the journey from an incoming file to an informed review easier to follow.
A connected architecture
The architecture follows the same journey: an Angular workspace gives engineers a point of entry; Python services handle ingestion, data access and mapping; PostgreSQL holds structured records; and Azure Blob Storage retains the original files. Each component matters because of what it passes to the next, not because it stands alone.
From upload to review
An engineer uploads an inspection file, and the Ingest service keeps the source in Blob Storage while the workflow moves forward. The interface reports whether it is pending, ready for input, processing, failed or complete, so the engineer can see where the journey stands.
The first real obstacle is interpretation. One file may call a column by one name; another may use a different header, sheet or convention. Before content becomes records, the engineer reviews the available columns and selects the mapping. Ingest applies that choice and persists the result as structured data.
Now the file can do more than sit in storage. The data layer exposes records, metadata and table data; mapping workflows place that information alongside asset and geographic context. The engineer can move from a row in a file toward a review of the infrastructure it describes.
Not every upload needs the same route. A supporting document may need to be preserved and found, not turned into queryable records. Inspection and custom-node files take the processing path because the application needs to work with their contents.
Preserving evidence and lineage
Keeping the original file alongside its processed records preserves provenance: an engineer can trace usable data back to its source. That also creates an obligation. Identifiers and metadata must connect the two representations reliably, or the context that makes the records trustworthy is lost.
This lineage, together with ingestion and processing metadata, can support a future medallion architecture. Source files, refined records and analysis-ready datasets should remain traceable to one another rather than become another collection of disconnected copies.
The same foundation could support future AI and machine-learning work. Curated, validated records could become training data; linked documents and metadata could support retrieval-augmented generation grounded in source evidence. Model predictions and generated responses would still need to remain traceable to the underlying data and subject to engineering review.
What this implementation demonstrates
Seen end to end, the path is not just upload, process, store. It is a sequence of handoffs that turns a source file into something an engineer can review in context. The Angular workspace, FastAPI services, PostgreSQL records, Azure Blob Storage files and mapping workflows each carry a different part of that journey.
The implementation demonstrates a connected path from file to record to geographic context. It does not, by itself, prove production throughput, tenant isolation, uptime or cost savings; those claims still require measured operational and security evidence.
The story is therefore less about any one technology than about the links between them: not just what an inspection file contains, but how its contents relate to the pipeline an engineer needs to understand.