The master data, knowledge and intelligence layer of the entire AGL Asset Lifecycle Guide. Divisions 01–24 generate, update and consume asset information; Division 25 brings that information together into one controlled asset-intelligence structure so every major AGL asset can be traced from identification through installation, operation, maintenance, failure, health, lifecycle decision, replacement and disposal — one asset, one master record, one complete lifecycle history.
The question this division answers — what is the single controlled identity and complete lifecycle record for every AGL asset, and what does that record tell us to do next?
Division 25 does not generate new field activity of its own — it is the data, knowledge and intelligence layer that Divisions 01–24 feed into and draw from. Every asset register entry, criticality score, design decision, inspection, test, maintenance job, failure record, cost entry, audit finding and case study ultimately resolves back to one master record, keyed by one Asset ID.
Division 25 is more than a database. Each master record is built up through five layers that turn raw asset data into a lifecycle decision.
Asset ID → Type → Model → Serial → Location
Installation → Commissioning → Maintenance → Inspection → Testing → Failures → Repairs
Condition → Health → Reliability → Performance → RUL
Failure risk → Obsolescence → RUL → Replacement forecast → Lifecycle cost
Maintain → Monitor → Repair → Refurbish → Upgrade → Replace → Dispose
All eleven linked databases — register, inspection, testing, maintenance, failure, warranty, spares, lifecycle cost, health, replacement and disposal — connect through one common key:
Every asset must have a unique and permanent Asset ID — the single controlling identity that every other lifecycle record, in every division and every linked database, keys against.
The coding structure itself should follow the airport's approved asset-coding standard.
The Asset ID should not change simply because the asset is repaired, refurbished or relocated, unless the organization's asset-governance rules explicitly define that event as creation of a new asset.
Asset Type defines the standardized asset category so records can be grouped, compared and benchmarked across the entire AGL population.
Standardized asset types enable asset population analysis, failure comparison, maintenance planning, spare forecasting, lifecycle-cost analysis and reliability benchmarking across like-for-like equipment.
Provide a clear engineering description of the asset — enough detail to distinguish it from similar assets on the same field.
The description should be sufficiently specific to distinguish similar assets — not a generic label repeated across hundreds of records.
Record the manufacturer exactly as approved in the controlled asset documentation.
Manufacturer data should be standardized to avoid multiple spellings or abbreviations of the same manufacturer fragmenting the analysis.
Record the exact equipment / model designation — the field that lets similar-looking assets be told apart by generation and configuration.
For equipment with multiple revisions, the relevant model / version should be retained rather than overwritten.
The serial number provides manufacturer-level traceability beneath the organization's own Asset ID.
Asset ID = the organization's lifecycle identifier. Serial Number = the manufacturer's equipment identifier. The two are different fields and should never be merged.
Location identifies where the asset is physically installed, in terms the field and the register both understand.
Record the date the asset was physically installed.
Installation date should be supported by an appropriate installation or project record where available.
Record when the asset was formally commissioned / accepted for operational use.
Installation Date ≠ Commissioning Date. The two dates can support different lifecycle calculations — installation marks physical fitting, commissioning marks operational acceptance — and both should be retained separately.
Record the expected service life established through the applicable asset / product / design information.
Expected service life should not automatically be treated as the replacement date. Actual replacement should also weigh condition, reliability, risk, performance, obsolescence and lifecycle cost.
Record the complete warranty position for the asset, not just an expiry date.
The database should be able to identify assets approaching warranty expiry, and assets currently under warranty with recorded failures — the two situations that need action.
Record the approved asset criticality classification.
The criticality record should link to the methodology established under Division 03 — Asset Criticality & Risk Assessment rather than duplicating a separate scoring logic here.
Record the condition at the beginning of the operational lifecycle.
This creates the reference point against which all future deterioration is measured.
Record the latest validated condition assessment.
The Health Index consolidates relevant condition and performance information according to the approved health-index methodology.
The database should store both a Current Health Index and, where the system supports it, a Historical Health Index so deterioration trends can be analyzed over time.
Maintain the complete lifecycle maintenance history for the asset.
The system should be able to answer: how much maintenance has this asset required during its lifecycle?
Store or link all relevant inspection records for the asset.
Maintain traceability to the testing records associated with the asset.
Historical test values should ideally be trendable rather than stored only as PDF attachments — the difference between a searchable record and a filed document.
This field should connect directly with the AGL Failure Database rather than duplicating its structure.
The master database should identify which assets have failed repeatedly, and which failure modes are becoming dominant across the population.
Where data is available, record or link the asset's operating and energy data.
For a CCR: operating hours, output current, loading, intensity-step operation.
For lighting: operating hours, energy consumption, operating profile.
This information supports performance, lifecycle-cost and energy analysis.
The master record should connect the asset with its complete lifecycle-cost history.
What has this asset actually cost throughout its lifecycle? — substantially more useful than storing only the original purchase price.
Repair history should be recorded as a distinct field from general maintenance history.
This allows identification of high-repair-frequency assets and high-repair-cost assets across the population.
Record every major refurbishment event applied to the asset.
Refurbishment should not erase the original lifecycle history — it extends the record, it does not replace it.
Record significant technology or performance upgrades applied to the asset.
This should be an intelligence field, not merely a fixed replacement date.
The forecast should be reviewed periodically rather than fixed at commissioning and left unchanged.
Track the final lifecycle status of the asset.
Every master asset record should provide controlled links to its relevant documentation.
One Asset Record → One Controlled Document Trail.
Record the standards, specifications or requirements applicable to the specific asset.
The database should identify which requirement applies to this asset, rather than simply storing a generic list of standards against every record.
Every significant change made to a master asset record should be traceable.
Rev 03 — Current Condition changed: Good → Fair. Reason: periodic condition assessment.
All 29 fields of the Standard Asset Record, in order, with the primary question each one answers.
| No. | Field | Primary Question |
|---|---|---|
| 01 | Asset ID | What is the asset's unique, permanent identity? |
| 02 | Asset Type | What standardized category does it belong to? |
| 03 | Asset Description | What exactly is it, engineering-wise? |
| 04 | Manufacturer | Who made it? |
| 05 | Model | Which product/version is it? |
| 06 | Serial Number | What is the manufacturer's own traceable identity? |
| 07 | Location | Where is it physically installed? |
| 08 | Installation Date | When was it physically installed? |
| 09 | Commissioning Date | When was it accepted for operational use? |
| 10 | Expected Service Life | How long is it designed to last? |
| 11 | Warranty Period | Is it under warranty, and until when? |
| 12 | Criticality | How important is it to safety and operations? |
| 13 | Initial Condition | What was its baseline condition? |
| 14 | Current Condition | What condition is it in now? |
| 15 | Health Index | How healthy is it overall, and is it trending down? |
| 16 | Maintenance History | How much maintenance has it required? |
| 17 | Inspection History | What have inspections found over time? |
| 18 | Testing History | What do its trended test results show? |
| 19 | Failure History | How and how often has it failed? |
| 20 | Energy / Operating Data | How hard and how much is it being used? |
| 21 | Lifecycle Cost | What has it actually cost so far? |
| 22 | Repair History | Is it a high-repair-frequency or high-repair-cost asset? |
| 23 | Refurbishment History | Has it been given a new baseline and extended life? |
| 24 | Upgrade History | What technology or performance upgrades has it received? |
| 25 | Replacement Forecast | What should happen to it next, and when? |
| 26 | Disposal Status | Where is it in its final lifecycle stage? |
| 27 | Related Documents | What is its complete controlled document trail? |
| 28 | Related Standards | Which requirements actually apply to it? |
| 29 | Revision History | How has its master record changed over time, and why? |
The mandatory outputs of Division 25.
Division 25 should remain the master data, knowledge and intelligence layer — it does not replace the detailed methodologies of the earlier divisions (criticality logic stays in Division 03, audit logic stays in Division 23), it connects them through one governed identity.
One Asset → One Master Record → Complete Lifecycle History → Intelligent Decision Support. The Asset Register tells you what the asset is; the Master Database & Intelligence layer tells you what has happened to it, how it is performing, what risks it carries, what it may need next, and what lifecycle decision should be considered.
This is why Division 25 closes the guide rather than opening it: every earlier division needs the trusted identity that Division 02 establishes, and every earlier division's output ultimately needs somewhere authoritative to live — Division 25 is that place.
Quick answers about Asset Lifecycle Master Database & Intelligence in the AGL Asset Lifecycle Guide.
Division 25 is the master data, knowledge and intelligence layer connecting every division. It covers 29 topics on the Standard Asset Record: Asset ID, type, description, manufacturer, model, serial number, location, installation/commissioning dates, service life, warranty, criticality, condition, health index, maintenance/inspection/testing/failure history, operating data, lifecycle cost, repair/refurbishment/upgrade history, replacement forecast, disposal status, related documents, related standards and revision history.
It is the master data, knowledge and intelligence layer of the guide. Divisions 01 to 24 generate, update and consume asset information, and Division 25 brings it together into one controlled asset record.
It defines 29 fields, MDI-01 to MDI-29, running from Asset ID through to revision history.
Asset ID, asset type, description, manufacturer, model, serial number and location. The Asset ID must be unique and permanent, and it is the single controlling identity that every other lifecycle record refers to.
Installation date, commissioning date, expected service life, warranty period, criticality, initial condition, current condition and Health Index, plus energy and operating data and lifecycle cost.
Maintenance, inspection, testing, failure, repair, refurbishment and upgrade history. Failure history should connect directly with the AGL Failure Database rather than duplicating its structure, and repair history is recorded separately from general maintenance history.
It should be an intelligence field and not merely a fixed replacement date. It draws on age, expected service life, condition, Health Index, RUL and reliability.
Every master record provides controlled links to related documents such as datasheets, drawings, installation and commissioning records and test reports. Related standards can include ICAO, FAA, DGCA and applicable Indian Standards, and every significant change is traceable through revision history with the previous value, new value and reason.
The disposal status field tracks the final lifecycle status, from active and under maintenance through under refurbishment or replacement to decommissioned and removed.
Effective AGL asset management starts with a master database that holds every fact about an asset in one place.
Learn how asset identity, condition, history, cost and forecast data connect across the complete AGL asset lifecycle.
Turn technical reference knowledge into a deeper understanding of how AGL assets are planned, managed, operated and sustained throughout their lifecycle.
Structure better. Unlock the intelligence. Build technical capability.
Build structured knowledge in:
Please read before relying on any content on this page or on any record downloaded from it.