Ask most asset management teams to pull up a pump record, and they'll open a spreadsheet row. You'll see a tag number, a description, maybe a location code. What you won't see is the pump's rated head, its impeller material, its last inspection photo, the O&M manual PDF, the commissioning certificate, or the maintenance task created last Tuesday.

That information exists somewhere. It's in six different systems, five different folders, and two email threads. The asset register just doesn't know about it.

In Oestler, every single asset record has ten structured views. Not tabs for the sake of it — ten distinct data dimensions, each answering a different question about the asset. Here's what each one does.

Attributes: The Structured Fact Sheet

Every asset type in Oestler has a defined attribute schema — the specific fields that must be populated for that asset to be considered complete. A centrifugal pump has different attributes than a fire damper or a circuit breaker. The schema is configurable: each attribute carries an ID, a display title, an example value, and a DPK (Data Package Key) that groups related attributes into logical bundles.

Attributes aren't just text boxes. Every attribute links to a validation rule that constrains what can be entered. Which brings us to the next view.

Validation: Six Types of Data Integrity

Data quality in construction asset registers typically means "someone checked it once". Oestler enforces it at the field level, continuously. Each attribute is bound to a validation type:

  • BOOL — true/false fields (e.g. "Is this asset safety-critical?")
  • INT — integer values (e.g. "Number of stages")
  • FLOAT — decimal values (e.g. "Rated flow in L/s")
  • STRING — free-form text with optional character limits
  • REGEX — pattern-matched strings (e.g. tag number format P-[0-9]{3})
  • LINK — validated URL or asset reference

An asset record with a REGEX validation failure on its tag number field is immediately visible. Not in a monthly data quality report — in real time, at the moment the data is entered. This is what continuous validation looks like in practice.

Photos: The Visual Evidence Layer

Every asset can carry an unlimited photo library. Each photo has a title, description, and type classification. The gallery view shows thumbnails inline within the asset record; full-screen preview opens a carousel navigator where inspectors can move through all associated images without leaving the asset context.

This isn't just aesthetics. A photo of a pump taken during commissioning, showing the installed nameplate, is evidence. When someone disputes a specification three years later, the photo record — timestamped, attached to the asset, not floating in a shared drive folder — is the answer.

Links: Dynamic URLs Bound to Asset Data

Construction assets often have external digital presences — manufacturer portals, vendor databases, internal CMMS entries. Oestler's Links view stores URL templates with an asset variable substitution system.

You define a link once: "Vendor portal: https://vendor.com/equipment/{AssetID}". For every asset, Oestler substitutes the real asset ID into the template and renders a live, clickable URL. One link definition. Thousands of unique, correct URLs generated automatically.

Tags, Tasks, Containers, Relationships, Data Requests

The remaining five views handle coordination and context:

  • Tags — classification labels for grouping and filtering across the register
  • Tasks — open action items attached directly to the asset (inspection due, defect to resolve, commissioning hold to clear)
  • Containers — logical groupings that place the asset within a system or package
  • Relationships — typed connections to other assets: parent/child hierarchy, feeds/fed-by process links, spatial co-location
  • Data Requests — formal requests for missing or updated information, trackable against a responsible party

A pump record with an open task ("Confirm rated head against design spec"), a parent container ("Process Train A"), and a relationship to a downstream tank is an asset that exists in context. Not a row in a spreadsheet. An intelligent record that knows its place in the facility.

QR Code: Closing the Physical-Digital Loop

Every asset in Oestler generates a unique QR code, printable directly from the record. Affixed to the physical equipment, this code becomes the bridge between the field and the platform.

Scanning it — via Oestler's built-in QR scanner or any standard QR reader — returns the user directly to the asset record. Full attribute set, photo history, open tasks, all of it. In the field, with one scan.

The Tag Portal extends this further. Oestler's QR infrastructure is interoperable with major CMMS and asset management platforms: IBM Maximo, Hexagon, Power BI, and native Oestler. A tag scanned in the field can route to whichever system the operator needs — chosen from a single interface, not configured per-device.

A QR code on a pump is not a novelty. It's the physical entry point to a ten-dimensional digital record. That's the difference between a label and a linked asset.

One Record, Not Seven Systems

The reason construction asset data ends up fragmented across spreadsheets, CMMS entries, shared drive folders, and email attachments is not that the data doesn't exist. It's that no single system was designed to hold all of it together, contextually, for one asset.

Oestler's ten-view asset record is designed for exactly that. Attributes and validation for data integrity. Photos for visual evidence. Links for external system integration. Tags, tasks, containers, relationships, and data requests for coordination and context. QR codes for physical-digital linkage.

It's not a spreadsheet with more columns. It's a structured record that reflects how assets actually exist — as physical objects with specifications, histories, relationships, and ongoing operational context — all in one place.