Asset maintenance example: connect tasks, observations and evidence

The projector has a green “ready” badge. Its lamp-hours display says 1980. A service note mentions an advisory interval of 2000 hours. Which statement should decide what happens before Repair Day?

They answer different questions. The badge describes a recorded workflow state. The display reading is an observation about a physical projector. The service note supplies documentary context. A maintenance task records work to review or perform. A useful model keeps all four visible instead of squeezing them into a status field.

Lantern's ASSET-P17 connects this job to the purchase and Repair Day demonstrations. All people, records and readings are invented. The advisory 2000-hour interval is illustrative scheduling context, not a manufacturer's instruction, safety threshold or prediction of failure.

Follow the physical projector

ASSET-P17 identifies the asset Lantern tracks. It is the individual projector supplied through SHIP-104, rather than the general product description on PO-104. Its identity lets later observations and work records concern the same unit as its location or custodian changes.

A model description can apply to many projectors. An asset history applies to this unit. Confusing those meanings would attach ASSET-P17's 1980-hour reading to every projector of that model. A product code helps describe what the unit is, but it does not distinguish one physical unit from another.

The purchased setup service also remains distinct. A service describes work or provision; a task tracks a particular piece of work in this scenario. Connecting them can be useful without treating their meanings as interchangeable.

Put the work in context

PROJ-READY is the project for preparing equipment for Repair Day. TASK-LAMP is the task to review lamp-hours context and plan appropriate maintenance. TEAM-AV supports the project, with PERSON-MAYA coordinating the example work.

The project supplies a shared objective. The task gives one bounded work item an identity. A project may contain several tasks, but this demonstration does not prescribe a hierarchy, dependency engine or complete workflow implementation.

An application might mark a task planned, assigned, in progress or complete. Those labels do not establish a physical result. “Complete” needs a stated meaning and evidence appropriate to the work. Reviewing a reading and scheduling later work differs from replacing a component.

Here the task is review and planning. No replacement, successful inspection or return to service is asserted. That scope keeps the model honest: preparing a maintenance decision is useful work even before someone reaches for a screwdriver.

Record the observation precisely

OBS-LAMP is an observation of ASSET-P17's displayed lamp hours. Its value is 1980 and its unit is hours. Its subject, observation time, description and observer belong beside the result. The example method is a manual display reading, not a claim that a calibrated instrument measured component condition.

W3C's Semantic Sensor Network and SOSA specification describes observations with observed properties, results, features of interest and procedures. It is a useful reference for separating a reading from the object it concerns. This demonstration uses that conceptual distinction without claiming complete SSN conformance.

The result is a reading, not a diagnosis. It does not alone prove brightness, remaining useful life, electrical condition or suitability for the event. If an application needs those answers, it must obtain the appropriate evidence rather than rename this number “health.”

A later reading should retain its own time context and history. Overwriting 1980 with a new value makes it harder to understand the earlier decision. Observation time and entry time can also differ, so label them when that difference matters. A remembered reading entered tomorrow should not silently become a reading taken tomorrow.

Keep the document revision

DOC-SERVICE identifies the document consulted for TASK-LAMP. Revision A contains the illustrative advisory interval of 2000 lamp hours. The revision matters because content can change while a familiar document title stays the same.

The task uses DOC-SERVICE revision A as context and OBS-LAMP as evidence of the recorded reading. Neither should overwrite the other: a recommended interval is not a measured value, and a measurement is not an instruction.

The difference between 2000 and 1980 is 20 hours. That arithmetic supplies scheduling context, not a countdown to failure. It does not establish that another 20 operating hours is safe, that maintenance becomes mandatory at exactly 2000, or that elapsed calendar time consumes lamp hours.

If a later revision changes the advice, retain which revision supported the earlier decision. A link that always opens the latest document may show a reviewer different content from what Maya consulted. An evidence reference needs enough context to reconstruct the actual decision.

Read the connected record set

The following conceptual properties make the relationships inspectable. They are example meanings, not an executable schema enforcing scalar types, required fields or fixed cardinalities.

• ASSET-P17: asset identifier, name, product, custodian and place; supplied through SHIP-104 and involved in EVT-REPAIR-DAY.
• PROJ-READY: project name and equipment-readiness objective; team TEAM-AV; event EVT-REPAIR-DAY.
• TASK-LAMP: task name, project PROJ-READY, assignee PERSON-MAYA, asset ASSET-P17, observation OBS-LAMP and evidence document DOC-SERVICE.
• OBS-LAMP: subject ASSET-P17, observed-at context, description “displayed lamp hours,” value 1980, unit hours and observer PERSON-MAYA.
• DOC-SERVICE: document title and reference, revision A, subject ASSET-P17 and media-type context when available.

Now the team can ask, “What did we know when we planned this task?” The answer points to a unit, an observation and a document revision. A green badge alone cannot explain that chain.

Is a status an observation?

A status and an observation can be related without being equivalent. A completed task describes the work item's recorded state. OBS-LAMP describes a result concerning the projector. Preserve both meanings.

Does this reading require immediate maintenance?

The invented numbers do not establish that conclusion. TASK-LAMP exists to review context and plan action. Actual equipment decisions require applicable instructions and competent assessment.

What connects all three demonstrations?

PO-104 requests the projector, SHIP-104 supplies ASSET-P17, EVT-REPAIR-DAY plans its use, and TASK-LAMP reviews evidence concerning that same unit. Shared identities connect the story; distinct records keep it explainable.

Explore the connected records

Download all three connected example journeys, or inspect the versioned source and its validation checks. The JSON is an illustrative set of records, not an interchange standard or a complete application schema.