Platform
One model, several surfaces, and nothing of yours in a database of ours.
A reliability engineer works at a desk. A tradesperson works on a walkway, in the rain, with a phone in a glove. AMS is built so both are running the same model.
Shape of the system
One shared data model and component library.
The entities, the business rules and the screens are defined once and delivered to several surfaces. A change to how a risk measurement behaves is a change in one place.
The data layer
No Entity Framework. No connection string to a plant database.
Every read and write in AMS leaves the process over HTTP and goes to the DDF API. There is no ORM mapping AMS onto a database, and no AMS component holds a database credential. That is unusual, and it is the single most important thing to understand about the architecture.
Queries are written as ordinary typed expressions in the application and compiled into DDF queries at the boundary, so the query surface is the same from the web app, the desktop shell and the phone. Payloads are compressed on the wire, which matters most on the phone, where connection setup costs are paid repeatedly during a master-data sync.
A WebSocket channel carries change notifications, so a screen can refresh because something actually changed rather than because a timer fired.
What this buys you
- The blast radius of an AMS outage is AMS. It is not your plant database.
- There is no schema of ours to migrate, version or reconcile against yours.
- The same access path serves every surface, so mobile is not a second-class integration.
Where your data lives
The honest version, including the part we cannot answer on a web page.
Some vendors would tell you at this point that AMS never holds your data, only references it. That is not true and you would find out quickly, so here is the accurate version.
AMS keeps its own register of the equipment you inspect and the company, area and location structure it sits in, along with every inspection answer, defect notification and risk measurement it records. It has to — those records are the product.
What it does not have is a database of its own to keep them in. They are held through the DDF API rather than in a schema AMS owns and connects to directly. Your equipment master, work orders and functional locations continue to live in your system of record; AMS holds a working copy of the structure it needs plus the evidence it generates.
Getting it back out. The registers and logs export to Excel from the product, and the REST hub exposes documented read routes. Your inspection history is not locked behind a screen.
Hosting, tenancy and exit terms depend on how your deployment is set up, and we are not going to publish a generic answer that turns out not to apply to you. Put these on the agenda for the technical walkthrough:
- Which tenant and which region the DDF instance for your site runs in
- How it is licensed, and what that includes
- How your equipment master stays in step with your system of record
- Retention, backup, and what a full export looks like on exit
Interfaces
A documented REST surface, both directions.
AMS publishes its own REST hub with an OpenAPI description and API-key authentication. It is the same surface the mobile app uses, which is the only honest test of whether an API is real.
Your systems can read planned inspection rounds and risk assessment logs, and post notifications, inspection answers and questionnaire definitions in — without asking us for an export.
Identity
Microsoft Entra ID via OpenID Connect on the web surfaces and MSAL on mobile, with username and password as the fallback where a site does not use Entra. Inside the product, roles map to functions explicitly rather than to screens.
Deployment
The web application is a framework-dependent ASP.NET Core app and runs on Azure App Service. The native mobile app is distributed as an Android or iOS application package.
Reporting
Power BI Embedded is authenticated server-side with client credentials and embed tokens minted per session, so report access follows your Power BI workspace permissions rather than a shared link.
The stack
What it is built on, and why each piece is there.
| Component | Version | What it is for |
|---|---|---|
| .NET | 10 | Runtime across every surface, including Android and iOS targets |
| Blazor | — | The shared component library behind the web, desktop and hybrid surfaces |
| .NET MAUI | — | The native mobile application, with SQLite as the on-device cache |
| Syncfusion Blazor | 32.2.5 | Grids, trees, tabs, toolbars and dialogs across the web screens |
| vis.js | — | The time-axis planning board behind the operations scheduler and timeline view |
| Monaco | 3.3.0 | Code editor for authoring risk measurement formulas and question logic |
| NCalc | — | Evaluates the risk formulas a site configures, on the server and on the device |
| Microsoft.Identity.Web / MSAL | — | Entra ID sign-in on web and mobile |
| EPPlus / ExcelDataReader | — | Excel export from grids, and bulk import through the import workbench |
Syncfusion Blazor is a commercial component suite and its licensing is included in an AMS deployment — it is not a separate line item you have to go and buy.
Bring your architect to the call
The technical walkthrough is a screen-share with the people who wrote this, not a slide deck. Data residency, identity, integration surface and exit are all fair game.