Reliability teams rarely begin with a pristine asset register, perfectly coded work history, and every drawing under revision control. Waiting for that condition can stall useful work. Ignoring the gaps, however, makes it impossible to tell whether an output is supported by evidence or merely plausible. A credible pilot sits between those extremes.
Define “ready” around a decision
Start with the decision the workflow is expected to support. “Use AI for maintenance” is not a bounded outcome. “Help engineers draft and review the failure logic for one cooling-water system” is closer: it identifies a system, a user, a review activity, and a result that can be assessed.
Before gathering more data, write down five things:
- Decision: what judgment or work product is being supported?
- Boundary: which asset, system, site, and operating modes are in scope?
- Authority: who can review, reject, correct, and approve the result?
- Evidence: which sources are allowed to inform the result?
- Acceptance: what would make the pilot useful, unsafe, or inconclusive?
Build a source ledger, not a file pile
A shared folder of manuals is not yet an evidence base. Create a small source ledger that gives every important item an owner, revision or date where available, scope, approval status, and known limitations. If two sources conflict, record the conflict rather than quietly choosing the more convenient one.
Source name · asset coverage · owner · revision/date · approval status · known gaps · superseded-by relationship · handling classification
Check the information in layers
1. Identity and hierarchy
Confirm that equipment identifiers resolve to the same physical items across documents and systems. Note aliases, parent-child relationships, package boundaries, and whether tag reuse or historical renaming could create ambiguity. A technically rich manual attached to the wrong equipment is worse than a visible gap.
2. Function and operating context
Record what the system is expected to do, the performance expectations that matter, and the modes in which those expectations change. Duty/standby operation, campaign changes, intermittent use, environmental conditions, and process constraints can all alter how evidence should be interpreted.
3. Maintenance and failure history
Work history is valuable, but it is not automatically ground truth. Check the time window, coding consistency, free-text quality, duplicate notifications, and whether recorded symptoms were later confirmed as causes. Keep observation, diagnosis, and remedy as separate concepts where possible.
4. Measurements and condition data
For monitoring use cases, document signal units, sampling behavior, expected range, sensor location, calibration practice, missing-data patterns, and maintenance periods. Capture relevant operating states alongside the measurement; a value without context may be normal in one mode and concerning in another.
5. Rights and handling
Decide which data may be used, where it may be processed, how it should be transferred, and who may access the resulting workspace. Include contractual restrictions, personal data, export or residency considerations, and confidential vendor material in the implementation review.
Make uncertainty visible in the workflow
Missing evidence should not disappear inside fluent generated text. Establish labels such as “source-supported,” “engineering assumption,” “requires field verification,” and “out of scope.” The labels must mean something operational: an unresolved safety-critical assumption, for example, should prevent publication until the designated authority addresses it.
| Readiness state | What it means | Typical action |
|---|---|---|
| Proceed | Evidence and review authority are adequate for the bounded decision. | Run the pilot and record exceptions. |
| Proceed with constraint | A known gap can be isolated without disguising uncertainty. | Limit scope and add a mandatory verification gate. |
| Hold | Identity, safety context, source rights, or accountable review is unresolved. | Resolve the blocker before processing or publication. |
Design the reviewer loop before the first output
Name reviewers by authority and discipline, not just by availability. Give them the source evidence, assumptions, and change history alongside the generated work. Define how corrections are captured and whether an approved result can be superseded. A comment box alone is not a governance model.
A compact pilot exit review
- Could reviewers trace important statements to an approved source or explicit assumption?
- Were asset identity and operating context preserved from input to output?
- Did the workflow surface conflicts and missing evidence rather than smoothing them over?
- Were rejection, correction, approval, and supersession clearly recorded?
- Did the pilot reveal a repeatable improvement, and can it be measured without overstating causation?
If the answer is mixed, that is useful information. Narrow the scope, improve the source ledger, or strengthen review. Data readiness is a managed condition, not a one-time certification.
For a broader implementation sequence, continue with the AndonEAM documentation overview.