Metadata driven forms: change the workflow, not the code

An inspection lead rewrites the external visual procedure to add a field for insulation condition at each CML. The change is approved in a week. Getting the field onto the form takes a quarter, because the form is code, the code belongs to the vendor, and the vendor has a release schedule. Meanwhile the technicians write insulation condition in the comments box, where it cannot be counted, filtered or trended. The gap between how fast a procedure changes and how fast a hard-coded form changes is where paper and spreadsheets come back. Configurable inspection forms exist to close that gap, and the way they are built determines whether they close it safely.

Why do inspection forms change more often than software releases?

Inspection forms are the operational surface of a procedure, and procedures change constantly for reasons that have nothing to do with software.

• Standards revisions. A new edition of API 510, API 570 or API 653 adjusts what must be recorded. Owner-user procedures follow, and the form must follow the procedure.
• Incident learnings. After a finding, a plant often adds a check. A CUI program adds a field for jacketing damage after a leak under insulation. That is a form change, not a software feature.
• Regulator and auditor requests. An audit finding that says "the record does not show who verified the calibration" produces a new required field and a new signature step.
• Site differences. A company running twelve facilities has twelve local variations on a common procedure. The variations are legitimate; the process piping at an LNG terminal and at a refinery are not inspected identically.
• Contractor and crew changes. A new NDE contractor brings a technique sheet with different fields. The record has to accommodate it without losing comparability.

Each of these arrives on its own schedule. Software releases arrive on the vendor's. When every form change is a release, the backlog grows, and the workaround is always the same: put it in the comments, or put it in a spreadsheet beside the system. Both destroy the value of having a system at all, because the data that mattered most, the new field added after the incident, is the data that ends up unstructured.

What does metadata driven mean in an inspection platform?

In a metadata driven platform, the form is not compiled into the application. It is described by data that the application reads at runtime. The description covers more than field names.

• Entity definitions. What kinds of records exist (a CML reading, a damage mechanism, a turnaround delay event, a coating DFT verification) and what fields each carries, with types, units and constraints.
• Form and workspace layouts. How those fields are arranged into sections, which are visible under which conditions, which are required, and what help text and lookup lists they use.
• Validation rules. Ranges, cross-field checks, required-if conditions, and format constraints, expressed as rules rather than as code branches.
• Workflow definitions. The states a record can be in and the transitions between them: submit, approve, reject, hold, resume, reopen, owner sign-off. Who may perform each transition and what must be complete before it is allowed.
• Reference data. The option lists, equipment classes, damage mechanism catalogues and locale settings that fields draw from.

intelliSPEC, as one concrete example, is configured by 223 entity definitions and 672 workspace and form definitions stored as JSON, and a tenant changes forms and workflows through the form designer rather than through code. The point of citing the numbers is not the numbers. It is that everything a user sees on a form is data that a tenant can inspect, version and change.

The consequence is that the vendor's release cycle governs capabilities (a new field type, a new instrument profile, a new calculation), while the tenant's own cycle governs procedure. The two are decoupled, which is the whole objective.

Configurable inspection forms vs hard-coded forms: what actually differs?

The visible difference is a form designer. The differences that matter are underneath it.

Who can make the change. Hard-coded: a developer, usually the vendor's, usually after a change request and a quote. Configurable: a tenant administrator or inspection lead with the right permission, on their own schedule.

How long the change takes. Hard-coded: a release cycle, often quarters. Configurable: the time it takes to edit and test the definition, often an afternoon.

What the change costs. Hard-coded: professional services. Configurable: staff time.

Whether the change survives upgrades. Hard-coded changes for one customer create a fork, and forks are what make upgrades expensive or impossible. Configuration lives in data the product knows how to carry forward, so a tenant's forms upgrade with the product.

Whether the change is auditable. A code change is auditable in the vendor's repository, which the tenant cannot see. A configuration change is a data change in the tenant's own system, and it can be written to the same audit trail as every other record change, with who, when and what.

Whether the change is consistent across sites. A configurable platform can hold a common form and per-site variations as data, so the corporate integrity function can see exactly how site B differs from site A. Hard-coded variations are invisible until someone reads the code.

There is one difference that cuts the other way. A hard-coded form cannot be broken by a tenant administrator on a Friday afternoon. A configurable one can. That is why the two topics that follow, record pinning and the boundary between configuration and code, matter as much as the form designer itself.

How do you keep a completed record faithful when the form changes?

This is the problem most demonstrations skip. A form designer that lets you add, remove and rename fields is easy to build. The hard part is what happens to the ten thousand records already completed under the old form.

The naive implementation stores the record as a set of values and renders it under whatever the current form definition is. The moment the form changes, every historical record changes with it. A removed field vanishes from records that had values in it. A renamed field relabels a value that was entered under a different meaning. A field whose lookup list changed shows a code that no longer resolves. A record signed in 2021 now looks different from the PDF the inspector signed, and an auditor will notice.

The correct implementation pins the configuration to the record. A completed record carries, or references immutably, the exact form definition, the locale and the reference option lists it was executed with. When it is opened later, it renders under that pinned configuration, not the current one. The inspector's signature is over a rendering that can be reproduced exactly.

The practical requirements that follow from this:

• Form definitions are versioned, and a version in use by completed records can never be edited in place, only superseded.
• Reference lists are versioned the same way, because "Option 3" in 2021 and "Option 3" in 2026 may not be the same option.
• Locale is captured, because a date or a decimal separator rendered under a different locale is a changed record.
• In-progress records are handled explicitly. A record started under version 4 and completed under version 5 needs a rule, either migrate on open with the user's knowledge or finish under the version it started with.
• Reports render from the pinned version, so a regenerated PDF matches the signed one.

intelliSPEC pins the field configuration, locale and reference options on every completed record, so a finished record renders as executed for as long as it exists. Any platform claiming configurable inspection forms should be asked to demonstrate the same thing: change a form, then open a record completed before the change, and show that nothing moved.

What should a form designer let a non-developer control?

The designer's scope is a design decision, and the wrong scope produces either a toy or a hazard. A useful boundary gives the tenant control over everything that expresses procedure, and withholds everything that changes what a stored value means.

Tenant-controlled:

• Adding, removing, reordering and grouping fields within the field types the platform provides.
• Requiredness, visibility conditions and default values.
• Validation rules within the platform's rule vocabulary: ranges, required-if, cross-field comparisons, pattern constraints.
• Lookup lists and their options, with versioning.
• Workflow transitions and which roles may perform them.
• Which calculators a form offers and which fields feed them.
• Which instrument profiles a field accepts, so a thickness gauge reading lands in the right field without retyping.
• Report layouts and branding.
• Labels and translations.

Platform-controlled:

• Field types and their storage semantics. A thickness is a number with a unit; a tenant should not be able to redefine it as text.
• Calculation logic. The formula behind tMin, a corrosion rate or a remaining strength factor.
• Identity and hierarchy semantics. What an asset node is and how CMLs attach to it.
• Security, permissions and audit behaviour.
• Sync and conflict semantics for offline capture.

The test of a good boundary is whether a determined tenant administrator can make a record mean something different from what it says. If a designer lets a user rename the "Nominal thickness" field to "Measured thickness" without the underlying field changing, the boundary is wrong.

Where does configuration stop and code begin?

The clearest place to draw the line is engineering calculation. A form may collect a thickness reading; it should not compute the corrosion rate from a formula the tenant typed into a designer. The reasons are worth stating plainly.

A calculation encodes a standard. Minimum thickness for piping routes to ASME B31.3, for vessels to ASME VIII Division 1, for tanks to API 653. Remaining strength under ASME B31G has an original and a modified method and editions with different constants. A remaining life is (t minus tmin) divided by the governing rate, and the governing rate is the maximum of the short-term and long-term rates. Each of these should be implemented once, reviewed against the standard, tested, versioned and returned with the design code and the formula alongside the number, so an engineer can check it. None of that is possible if the formula lives in a tenant's form definition.

Calculations also need their own governance. intelliSPEC registers 199 calculators, each with its own permission grant, and enforces a segregation-of-duties rule that a calculator's author cannot approve it. Results from fitness-for-service screening are provisional until an engineer verifies them, and the platform never auto-derates equipment from a calculation. API 579 Part 5 Level 1 is deliberately not implemented pending licensed-engineer verification. Those are code-level controls. A form designer cannot provide them, and should not pretend to.

The same logic applies to Spectra, the platform's grounded AI layer. Its 59 agentic actions are generated from the same metadata that defines the forms, so an action to create or update a record follows the tenant's field rules, and create and update actions require approval by default. Configuration defines what the actions can touch; code defines how approval, expiry and undo work.

What to check in your own program

A short list, in the order it usually matters.

1. Time a change. Pick a real recent procedure change and measure how long it took to reach the form. If the answer is measured in quarters, count how many fields are living in comments boxes as a result.
2. Ask who holds the pen. Can your inspection lead add a required field, or does it need a purchase order? See intelliINSPECT for how the form designer scopes that control.
3. Open an old record after a change. Change a form in a test tenant, then open a record completed before the change. If anything moved, your history is not stable.
4. Find the calculation boundary. Ask where tMin, corrosion rate and remaining life are computed, who can change the logic, and whether the result comes back with its formula and code reference. intelliINTEGRITY returns both.
5. Check the audit trail covers configuration. A form change should be an audited event with an actor and a timestamp, like any record change.
6. Count the sites. If you run more than one facility, ask how per-site variations are held and whether the corporate view can compare them.
7. Price the model. Configuration that lives with the tenant should not be billed as professional services. Compare the pricing model against what you currently spend on change requests.

The objective is not a platform that can be configured. It is a program where the form always matches the procedure, and where the records signed under last year's procedure still look exactly like they did when they were signed.