Workflows

Choose a first workflow#

For North Yard, start with a simple question: what happened around Gate B before the reported access issue? The first useful result is a view that connects the gate, its observing camera, the incident, and the inspection task, with the sources behind each record.

Keep the first evaluation read-only. A useful connected view can be evaluated before an integration is authorized to move a robot or control an access point.

flowchart TD
  Q[Choose a site question] --> M[Define objects and relationships]
  M --> S[Connect an authorized source]
  S --> V[Validate records and evidence]
  V --> A[Explore the application view]
  A -. Optional, separately authorized .-> X[Evaluate an action workflow]

Prepare the site context#

Define the model in Studio#

Studio is intended to let a team define its model before depending on it in an application. Begin with the accepted domain types and add only the properties and relationships needed for the workflow. Defining a type and creating an instance are separate activities.

1. Use Site for North Yard and Place for East Entrance.
2. Represent Gate B and Camera 12 as separate Asset objects, each with its own identity.
3. Connect Gate B to East Entrance with LOCATED_AT and to Camera 12 with OBSERVED_BY.
4. Represent the access issue as an Incident affecting Gate B. Link the inspection Task to its assigned Agent.
5. Review names, property meanings, and relationship directions with the people who know the site.

Do not add a property merely because it exists in a vendor payload. Decide what it means to the application, what units it uses, and whether it describes a current value, an observation, or a forecast.

Connect and validate one source#

Choose a cloud connector or optional local Edge deployment based on access and processing needs. Confirm permissions before inspecting source data. Discovery cannot supply authorization or credentials.

1. Confirm the source identity and which operations the account may perform.
2. Map source identifiers to the intended objects. Leave uncertain matches unresolved for review.
3. Check timestamps, time zones, units, and source freshness against representative records.
4. Open a permitted evidence reference and confirm it supports the observation being shown.
5. Disconnect or delay the source during an approved test and verify that stale information is clearly marked.

A connection being healthy does not prove the mapping is correct. Review the same real-world example in the source system and the application, within the evaluation’s permitted scope.

Explore the model and its history#

In the intended exploration workflow, an operator starts with Gate B and follows relationships to the camera and the incident. History adds the earlier observations and decisions. Evidence gives the operator a way to assess the source rather than relying on a combined summary alone.

Evaluate actions separately#

Once the connected view is useful, an approved evaluation can consider an inspection request. First confirm that an available integration supports the required operation, the requesting actor has permission, and the operating constraints are satisfied.

Keep the request, command acknowledgment, reported execution, and evidence of the outcome distinct. An operator should be able to tell which stage has been reached and whether the Task’s completion criteria are met.

• Workflow examples

  Follow an investigation, an inspection request, and a prediction review.

• Functions and operations

  See conceptual functions, inputs, and results for application developers.

Use these as application patterns#

A workflow begins with a question and ends with a useful result for the user. It should also make missing context, uncertainty, and permission limits visible. Each example below identifies what the application reads, what it asks the user to decide, and how to assess the result.

Investigate activity around Gate B#

An operator opens an incident reporting unusual access activity. The application needs to show where it happened, the relevant time window, related observations, and the evidence the operator is permitted to inspect.

sequenceDiagram
  actor Operator
  participant App as Application
  participant Ontology
  participant Evidence as Evidence system
  Operator->>App: Open the Gate B incident
  App->>Ontology: Read permitted incident and related objects
  Ontology-->>App: Site context and evidence references
  App->>Ontology: Read events in the review window
  Ontology-->>App: Events with source times
  App-->>Operator: Show context and uncertainty
  Operator->>App: Open supporting evidence
  App->>Evidence: Request authorized evidence access
  Evidence-->>Operator: Permitted image or clip

incident = ontology.getObject({ object: selectedIncident })
affected = ontology.getRelationships({
  object: incident.reference,
  relationship: "AFFECTS",
  direction: "outgoing"
})
context = ontology.getEvents({
  location: incident.location,
  from: reviewWindow.start,
  to: reviewWindow.end
})

showInvestigation(incident, affected, context)
// Keep sources and uncertainty visible for the operator's review.

• Start with the selected incident, not a guessed person or vehicle identity.
• Show why each observation is relevant, including its time and location.
• Treat a suggested association as a claim to review, not proof of identity or wrongdoing.
• Keep the operator’s conclusion distinct from the original observation and retain its evidence context.

A useful result is an understandable investigation with reviewable sources. The existence of a person and vehicle in the same time window alone does not establish that the person owns the vehicle or caused the incident.

Request an inspection and follow the result#

After reviewing Gate B, the operator decides that the entrance needs inspection. A Task describes the work and its completion criteria. An action request asks an available, permitted agent to carry out a specific operation.

sequenceDiagram
  actor Operator
  participant App as Application
  participant API as Ontology service
  participant Connector as Integration
  Operator->>App: Request Gate B inspection
  App->>API: Submit action intent and task context
  API->>API: Check permission and operating constraints
  alt Request is rejected
    API-->>App: Rejection with permitted explanation
  else Request is accepted
    API->>Connector: Route permitted operation
    Connector-->>API: Command acknowledgment
    API-->>App: Request progress
    Connector-->>API: Result or follow-up observation
    API-->>App: Outcome and available evidence
    App-->>Operator: Review task completion criteria
  end

1. Read the Task and establish its purpose, target, and completion criteria.
2. Review available capabilities and constraints for the intended agent.
3. Request the action through the common service boundary with the required approvals.
4. Track the request rather than assuming it completed when accepted.
5. Inspect the result and evidence before treating the Task as complete.

If the connection drops after dispatch, the outcome may be unknown. The application should preserve that uncertainty and give the operator a review path. Repeating a command without understanding its effects can duplicate physical work.

Give the next shift the context#

The next operator should be able to understand the original observation, the decision made about it, and the work that followed. A handover view can use incident and task records with their related events rather than relying on an isolated message.

flowchart TD
  O[Source observation] --> I[Incident review]
  I --> T[Inspection task]
  T --> A[Permitted action request]
  A --> R[Result and supporting evidence]
  R --> H[Next shift reviews the linked record]

Do not erase an earlier uncertain report when a later inspection resolves it. The application should distinguish what was originally reported from what was subsequently learned. Exact history and retention behavior requires a deployment-specific contract.

Use a prediction as decision support#

A predictive view could help a team review a forecasted condition at East Entrance. Show the forecast horizon, uncertainty, and provenance alongside the observations available now. The forecast should remain visually and semantically separate from historical facts.

1. Identify the operational question and forecast horizon.
2. Read the permitted forecast, if supported for the use case.
3. Show observed conditions and predicted conditions separately.
4. Let the team evaluate whether preventive work is justified.
5. Any resulting action follows the same permission and outcome-review path as other work.

This public guide describes how an application consumes a prediction. It does not describe proprietary prediction methods, models, features, or tuning.

• Functions and operations

  Review the proposed operations used in these examples.

• Permissions and evidence

  Apply the same access boundaries throughout a workflow.