Service Evidence

A service has a name, owner, criticality and operating status. Assets, incidents, changes, problems and requests all refer to it. That shared reference lets the service manager ask whether a database issue affects an active service, which asset hosts the database and which operational records need attention. When an asset is in maintenance, its status adds context to a change or incident without changing the status of the service itself.

A problem record captures a recurring or unresolved cause under a service. It has a number, statement, root cause, opening time, status and owner. The owner can keep an investigation visible after an incident has been resolved. Known error is a distinct problem state, useful when the team understands the cause but still needs to manage its effect. The service manager should keep the statement and root-cause explanation specific enough for another responder to use.

• Service ownership. The service owner and criticality establish who reviews operational impact.
• Problem work. A numbered problem tracks investigation and known-error status under the service.
• Event receipt. A receipt stores provider, external event identity, receipt time, payload hash and processing outcome.

Confirm each service name and owner before importing assets and active work. Agree when a service should be active, in maintenance or retired, and who may make that change. Choose the owner responsible for problem statements and root causes. A problem can be opened during a series of incidents, but each incident keeps its own assignee, priority and timestamps.

For external events, identify the provider and its event identifier. The receipt status distinguishes an event received from one applied, rejected or failed. Decide who reviews failed and rejected receipts and where the originating system’s full event detail remains available. The receipt record supports reconciliation by event identity and hash; it should not be treated as proof that every external action succeeded.

Start with a service whose database host is in maintenance. Check that the asset links to the intended service and that its status describes the host accurately. If incidents recur against that service, open a problem with an owner and a clear statement. The owner records investigation and root cause as they become known, while incident responders continue to handle each incident’s immediate work.

Now consider a provider event about the same service. Record its receipt number, provider, external event identity and receipt time. A service manager reviews whether it was applied or needs follow-up. If it failed, leave that outcome visible in the receipts screen while the team investigates. Do not use a receipt status to close an incident or approve a change; those decisions belong to their own records.

• Open Problems — Unresolved service problems with owner, status and root-cause context.
• Integration Receipts — Incoming provider events that need processing or review.
• Open Incidents — Active service issues tied to an asset and responder.

See service context and incident handling.