A Maintenance Note Is Not a Closed Work Order

By Jared Mastroianni
Chief Operating Officer, modSTORAGE
CEO and Co-Founder, Facily.ai

Method and evidence boundary: This is an authored operating method. Every facility, person, work order, vendor, asset, timestamp, threshold, and result in the examples is fictional. The method is not a product description, customer case, legal or safety conclusion, service level, certification, or maintenance instruction. Qualified people must define and perform the work appropriate to the asset and consequence.

A facility manager writes: “Gate checked. Working now.”

The note may be useful. It is not enough to prove that the work order should be closed.

What was checked? Which gate? What condition was originally reported? Was a repair performed, or did the symptom disappear? Who had authority to evaluate it? Was the resulting state observed independently? Were temporary controls removed? Is another task still open? Did the work affect a customer, access schedule, vendor obligation, or future inspection?

Most maintenance queues do not fail because nobody typed the word done. They fail because observation, assignment, execution, verification, reconciliation, and closure are collapsed into one status.

A durable work-order process keeps those states separate. It lets a new manager understand what happened without reconstructing the story from free text. It also prevents an AI assistant, automation rule, vendor email, or hurried operator from promoting a record beyond the evidence it actually contains.

Start with the smallest truthful statement

A maintenance note is an assertion made by a person or system at a point in time. It may describe:

• a reported symptom;
• an observation;
• a diagnostic hypothesis;
• an action attempted;
• a part ordered;
• a vendor update;
• a temporary condition;
• a claimed result;
• a verification result;
• an unresolved question.

Those meanings are not interchangeable.

“Reset controller” describes an action. “Controller accepted reset command” describes a receipt. “Gate completed three commanded cycles under the approved test” describes a verification observation. “Work order closed” is a governance state that says the declared closure requirements were met and the remaining record is ready to become history.

The smallest truthful statement is often narrower than the desired status. Preserve that narrow statement. Do not use an optimistic status to make the queue look clean.

Eight states that should not collapse

The names can vary by system, but the operating meanings should remain distinct.

1. Reported

Someone or something says a condition may exist. The record needs the facility, asset or area, time, reporter or source, observed symptom, and immediate consequence if known.

A report is not a diagnosis. “Door will not open” does not establish whether the cause is mechanical, electrical, software, credential-related, schedule-related, or user error.

2. Qualified

The operation confirms that the record belongs to the correct facility and asset, removes obvious duplicates, assigns a consequence band, identifies immediate controls, and decides what kind of response is needed.

Qualification can also reject or redirect a record. A duplicate may link to the governing work order. A customer-account problem may leave the maintenance queue. A life-safety concern may follow an emergency process rather than normal prioritization.

3. Authorized

The appropriate authority approves the scope, access, method, vendor, spending limit, or operating window required for the next action.

Authorization is not execution. A purchase approval does not prove a part was ordered. A vendor dispatch approval does not prove anyone arrived.

4. Assigned and accepted

The task has a named owner, and that owner or provider has accepted it with a response expectation. Assignment without acceptance can create an invisible gap: the central team thinks the site owns it; the site thinks the vendor owns it; the vendor never received it.

Record assignment and acceptance separately when the distinction matters.

5. Executed

The approved work was attempted or performed. The record should identify the executor, time, scope, materials or configuration affected, deviations, and execution evidence appropriate to the work.

Execution may end in completed_as_planned, partially_completed, unable_to_reproduce, blocked, temporary_control_applied, follow_up_required, or another bounded state. It does not have to end in success.

6. Verified

An authorized verifier checks the result against a declared acceptance condition. The verifier may be different from the executor when consequence, policy, or practicality requires independent readback.

Verification should answer a concrete question. “Looks good” is weak. “Approved functional test completed; observed state matched the expected result; no exception was recorded” is clearer, provided the test itself is defined and appropriate.

7. Reconciled

The operation checks downstream consequences:

• Is the asset or facility state updated in the governing system?
• Are temporary controls still needed?
• Is a child task, invoice, part return, warranty item, customer follow-up, or vendor issue open?
• Did the work change a schedule, instruction, access rule, inspection date, or source-of-truth record?
• Is the record linked to any incident, repeat issue, or change review?

A physical repair can be complete while administrative, customer, financial, or evidence work remains open. Reconciliation makes that visible.

8. Closed

Closure is a controlled transition. It means the declared closure contract passed, the final disposition is named, required evidence is attached or linked, open dependencies are resolved or transferred to named records, and the result can be reconstructed later.

Closure is not deletion. It is not proof that the problem will never recur. It is not proof that the repair was optimal. It does not erase uncertainty.

“Complete” and “closed” can be different product states

Current IBM Maximo Manage documentation provides a useful product-specific example. It distinguishes COMP, where the physical work is completed, from CLOSE, where the work order is finalized, unused inventory reservations are removed, and the record becomes history. IBM also notes that workflow configuration can influence status behavior.

That documentation does not define a universal maintenance process and does not imply that modSTORAGE uses Maximo. It demonstrates a narrower point: mature work-order systems may intentionally distinguish physical completion from administrative closure.

Do not copy another product’s status labels without understanding their effects. In some systems, a status change may trigger inventory, cost, notification, history, or integration behavior. A friendly label in the interface can carry consequences beyond the screen.

The same IBM documentation says a work-order status indicates its position in a processing cycle and determines which actions can be performed. Its status-bar documentation describes a visible history and future steps before closure. Again, these are product behaviors, not evidence of any self-storage deployment.

The seven-part closure contract

Before a work order can close, require seven answers.

1. Exact identity

• Which facility?
• Which asset, unit, area, or system?
• Which original report and any duplicate records?
• Which work-order version?

If identity is uncertain, stop. Evidence from one gate, unit, camera, or controller cannot close another record because the descriptions look similar.

2. Declared scope

• What condition was the work intended to evaluate or change?
• What was explicitly outside scope?
• What acceptance condition was approved before execution?

Scope prevents a minor adjustment from being presented as a complete repair to a larger problem.

3. Execution evidence

• Who performed or attempted the work?
• When?
• Under what authorization?
• What exactly changed?
• What blocked, deviated, or remained temporary?

An invoice, text message, or vendor portal status may support this block. None automatically proves the operating result.

4. Verification evidence

• Who verified?
• What test or observation was used?
• What was expected?
• What was observed?
• Was the verifier sufficiently independent for the consequence?
• What uncertainty remains?

Verification is decision-specific. A visual check may be sufficient for one cosmetic item and inadequate for a consequential access-control change.

5. Dependency disposition

• Are child tasks, parts, invoices, permits, warranties, customer follow-ups, or vendor claims still open?
• If transferred, what is the new record ID and owner?
• Are temporary controls removed, extended, or replaced?

“Handled elsewhere” is not a disposition unless the elsewhere has an identity.

6. Final state and reason

Use bounded closure reasons such as:

• verified_resolved;
• duplicate_linked_to_governing_record;
• no_condition_found_after_approved_test;
• scope_transferred_to_follow_up_record;
• canceled_before_execution_by_authorized_owner;
• asset_retired_under_governing_record.

Avoid one generic closed reason. It makes resolved, canceled, duplicate, unable-to-reproduce, and transferred records indistinguishable.

7. Reopen path

Define who can reopen, which facts trigger review, how the new observation links to the prior closure, and whether a new work order or a new version is required.

Reopening is not failure by itself. A well-governed reopen path protects history and makes recurrence measurable.

Express closure as a testable predicate

A closure contract becomes operational when a system or reviewer can evaluate it without guessing. For a normal, low-consequence work order, the rule might be expressed as:

eligible_to_close =
  exact_identity_confirmed
  AND authorized_scope_recorded
  AND execution_disposition_recorded
  AND verification_contract_passed
  AND dependencies_resolved_or_transferred
  AND final_reason_selected
  AND closure_authority_confirmed
  AND reopen_path_defined

That is not a universal formula. Each organization must define its own fields, roles, evidence, and consequence bands. Its value is that every term can return pass, fail, not_applicable, or unknown. A missing photo does not automatically fail every job. A photo that is required by the approved verification contract does. An unknown dependency state does not become pass because the record is old.

The predicate also prevents one impressive artifact from overpowering the rest of the packet. A detailed invoice cannot compensate for uncertain asset identity. A perfect test result cannot prove that a temporary control was removed. A senior person’s confidence cannot replace the declared authorization when the process requires it.

Record which contract version was evaluated. If the organization changes its closure rule next month, it should still be possible to determine which requirements governed today’s decision. Do not silently re-score history under a new rule and present the changed result as if it existed at the original close time.

Give consequential work a slower lane

Not every work order deserves the same review burden. A damaged sign and a change to an access-control schedule have different potential consequences. The answer is not to make every ticket slow. It is to define consequence bands before the queue is under pressure.

A simple pattern is:

• routine: one authorized person may execute and verify when the closure contract permits it;
• controlled: execution and verification require distinct recorded steps, even if one person performs both under policy;
• consequential: independent verification, explicit dependency review, and named closure authority are required;
• emergency: the emergency process governs immediate action, followed by a documented normalization and closure review.

The band must change requirements, not merely color a label. It should determine who may authorize, whether executor and verifier can be the same, which evidence is required, how long a temporary condition may remain, and who can waive a gate. A waiver should identify the missing condition, reason, authority, expiration, and follow-up record. It is not a hidden pass.

This lets a portfolio keep routine work moving while slowing the decisions that can lock out customers, disable protections, change operating schedules, or create an unresolved dependency across systems.

Five things that should never close a work order by themselves

A new note

The note can advance the record only to the state its evidence supports.

A vendor says “done”

That may be execution evidence. Apply the declared verification and reconciliation gates.

A bill arrives

The bill may support financial processing. It does not independently prove execution quality, operating state, or closure.

The symptom disappears

The operation may record unable_to_reproduce or an approved observation period. It should not invent a diagnosis or repair.

An automation changes the status

An automation can apply a policy. It cannot create missing evidence. If the rule cannot identify the source, version, authority, acceptance condition, and readback that justified closure, it should not close consequential work.

What an AI assistant may and may not do

An AI assistant can help organize the record. It may:

• extract candidate fields from notes;
• identify missing closure elements;
• suggest bounded reason codes;
• find possible duplicate work orders;
• draft a verification checklist from an approved template;
• summarize open dependencies;
• prepare a review packet for the authorized owner.

It should not promote a record merely because a note sounds confident. It should not infer that an attachment depicts the correct asset. It should not treat a vendor statement as independent readback. It should not invent a test, diagnosis, credential, completion time, or causal explanation.

For consequential closure, the safest AI role is often evidence assembler, not status authority.

The record should preserve which source text the assistant used, what it extracted, which model or rule version generated the draft, what the human changed, and who authorized the transition. W3C PROV-O provides general vocabulary for connecting entities, activities, and agents and for describing generation, use, derivation, and invalidation. It does not define this work-order method or prove that an assertion is correct.

Treat closure as a controlled state transition

NIST SP 800-53 Rev. 5 includes a controlled-maintenance control, MA-2, that calls for scheduling, documenting, and reviewing maintenance and repair records and for producing current, accurate, complete records of actions requested, scheduled, in process, and completed. The publication concerns information-system security and privacy controls, not self-storage facility maintenance. The official publication page currently identifies Release 5.2.0, issued August 27, 2025; its listed changes do not modify MA-2. The bounded lesson is that requested, scheduled, in-process, and completed actions deserve explicit records.

NIST CSF 2.0 similarly separates incident analysis, response, and recovery outcomes. Its RS.AN-06 and RS.AN-07 outcomes address recording investigative actions and preserving the integrity and provenance of records, data, and metadata. Final NIST SP 800-61 Rev. 3, published in April 2025, provides incident-response recommendations for those outcomes. Both documents concern cybersecurity, not facility work-order closure. The useful operating analogy is that response, restoration, evidence, and closure should not collapse into one label.

The closure transition should therefore record:

• prior state;
• requested state;
• transition time;
• actor and authority;
• decision rule or checklist version;
• evidence references;
• unmet or waived conditions;
• waiver authority and expiration;
• resulting state;
• linked notifications and downstream actions.

If a required condition is waived, the record should not pretend the condition passed.

A fictional ten-minute review

At fictional Site Alder, a manager reviews three items.

WO-101 — Hallway light out
A technician note says the lamp was replaced. The manager can see the correct fixture identity, executed-at time, and a verification photo, but the photo has no asset reference and was uploaded to two work orders. Result: review, not close, until identity is resolved.

WO-102 — Gate intermittently stops
A vendor says the gate cycled normally during the visit. No condition was reproduced and no repair was performed. The approved plan requires an observation window and a follow-up test. Result: executed_unable_to_reproduce; verification remains open.

WO-103 — Damaged unit latch
The approved replacement was performed, the named verifier observed the defined functional check, temporary signage was removed, and no child task remains. Result: verified_resolved, then reconciled, then closed with linked evidence.

The review does not reward the shortest note. It advances each record only as far as the evidence allows.

Metrics that expose queue truth

Useful measures include:

• count of records by operating state and age;
• assigned but unaccepted work;
• executed but unverified work;
• verified but unreconciled work;
• records closed with each reason code;
• closure packets missing required evidence;
• temporary controls with expired review dates;
• reopened records by reason;
• duplicate records without a governing link;
• provider receipts awaiting operational readback;
• status changes reversed after audit;
• work whose current owner is unknown.

Always publish the numerator, denominator, period, population, source, exclusions, and limitations for a rate. A lower open count is not automatically a better result. It can reflect completed work, transferred work, canceled work, or premature closure.

Do not use the checklist to manufacture a closure-rate target. First use it to learn whether the queue’s states are truthful.

The beginner exercise

Choose five recently closed work orders. For each one, find:

1. the exact reported condition;
2. the governing facility and asset identity;
3. the authorized scope;
4. assignment acceptance;
5. execution evidence;
6. verification evidence;
7. open or transferred dependencies;
8. final reason code;
9. transition authority;
10. the reopen path.

Do not change the old record during the first pass. Record what is present, missing, ambiguous, or contradictory. Then select one low-consequence workflow and define a closure contract for future records.

Use the companion maintenance closure packet template to capture the evidence and the work-order closure readiness suite to test a workflow from beginner through architect level. The state-machine diagram gives a one-page view of the controlled transitions. Every example row is fictional and must be adapted before operational use.

Close the evidence gap before the work order

Maintenance work happens in the physical world. The operating record is a representation of that work. Good governance keeps the two connected without pretending they are the same thing.

A note can report. A status can route. A receipt can confirm acceptance. A verifier can observe a result. A reconciliation can clear dependencies. A controlled transition can close the record.

When those states remain separate, managers gain something more valuable than a tidy queue: a maintenance history they can actually trust.

Sources

• Work order statuses, IBM Maximo Manage documentation, checked August 22, 2026.
• Status bar, IBM Maximo Manage documentation, checked August 22, 2026.
• NIST SP 800-53 Rev. 5, National Institute of Standards and Technology, September 2020 with current Release 5.2.0 status noted on the publication page.
• NIST Releases Revision to SP 800-53 Security and Privacy Controls, National Institute of Standards and Technology, August 27, 2025.
• The NIST Cybersecurity Framework 2.0, National Institute of Standards and Technology, February 26, 2024.
• Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, National Institute of Standards and Technology, April 2025.
• PROV-O: The PROV Ontology, W3C Recommendation, April 30, 2013.
• Constraints of the PROV Data Model, W3C Recommendation, April 30, 2013.