Core concepts

Definitions and real-world instances#

A type definition describes a category and its allowed properties or relationships. An object instance represents one particular thing. Asset is a type; Gate B is an instance. A Gate subtype could specialize Asset, but North Yard is a specific Site object, not a parent type for Gate B.

Containment is a relationship. North Yard contains the East Entrance, and Gate B is located at that entrance. This does not make Gate B a subtype of North Yard.

Objects and properties#

An object has a stable identity and descriptive properties. Gate B might have a name, a location, an operating status, and an owner. Properties can change without creating a different gate.

A source identifier is not necessarily the ontology identity. Camera 12 may have one identifier in its management platform and another in an equipment register. Mapping those identifiers to one object requires evidence and reconciliation, not just matching display names.

Keep unknown values distinct from negative values. If the last gate observation is stale, its current position is uncertain. A missing signal does not prove that the gate is closed.

Relationships connect the records#

flowchart TD
  Site[North Yard · Site] -->|CONTAINS| Place[East Entrance · Place]
  Gate[Gate B · Asset] -->|LOCATED_AT| Place
  Gate -->|OBSERVED_BY| Camera[Camera 12 · Asset]
  Incident[Access issue · Incident] -->|AFFECTS| Gate
  Task[Inspect Gate B · Task] -->|ASSIGNED_TO| Agent[Agent 104 · Agent]

Relationship names have direction and meaning. The model can express an inverse relationship when defined, but applications should not infer that every link is symmetric. Relationships can also change over time, such as the agent assigned to an inspection.

Capabilities include constraints#

A capability describes something an object can do, such as observe, move, or capture an image. An application can ask for an agent capable of inspecting East Entrance rather than requesting a particular manufacturer’s robot.

Matching a label is only a first filter. Camera 12 and Agent 104 might both capture images, but they differ in viewpoint, reach, image quality, availability, and the conditions in which they can operate. A fixed camera cannot navigate to an obstructed gate.

• Check the required capability and its parameters.
• Check operating constraints such as permitted areas, reach, environmental conditions, and device limits.
• Check current health, availability, and freshness of capability information.
• Check the requesting actor’s permissions and any required approval.

Adapters describe vendor-specific behavior below this boundary. A capability declaration does not itself authorize execution or guarantee that an action is currently possible.

Observations, events, and incidents#

An observation is information received about the world. At 17:42, Camera 12’s model output might indicate that Gate B appears open. The record should preserve its source, observation time, location, confidence where meaningful, and evidence reference.

An event records a reported occurrence, such as a gate-open signal or an inspection completion. Events can be derived from observations and rules or reported directly by another system. Preserve the distinction between a source report and a verified outcome.

An incident is the operational case used to investigate an issue. The gate observation, an access-system event, and an operator’s note might contribute to one incident. None needs to be collapsed into an unsupported conclusion.

A detected person or vehicle is not automatically a resolved identity. Connecting sightings or associating a vehicle with a person requires supporting evidence and appropriate review. Confidence is not certainty, and scores from different sources may not be comparable.

Tasks describe work; actions execute steps#

Inspect Gate B is a Task. It has an owner or assignee, a purpose, and completion criteria. Navigate to East Entrance and capture an image are actions that might help carry it out.

An action request must be evaluated against permissions, capability constraints, and current conditions before routing to an integration. Its execution record should distinguish a request, acknowledgment, progress, and outcome.

Past state, current state, and predictions#

Record when something happened separately from when it arrived. A late observation may add to the history without replacing a newer current-state reading. Corrections should preserve the origin of the earlier claim and make the revised interpretation clear.

Evidence, provenance, and permissions#

Evidence is the material behind a claim: a video clip, image, source message, or human report. Provenance explains how the claim was produced, including the originating source, time, processing steps, and model version where relevant.

Structured records can reference externally stored evidence. Access to the Gate B object does not automatically grant access to every linked video or person record. Permissions must apply to relationships, queries, live updates, actions, and evidence access.

This lets an application answer both ‘What do we know?’ and ‘How do we know it?’ without treating access to the model as unrestricted access to its sources.

Three distinct access boundaries#

All three matter. Broad source access does not mean every application user should receive the same information. A user’s ability to read an ontology object also does not prove that a connector can execute a requested action.

Scope reads and live updates#

Applications should operate within the actor’s permitted sites and objects. Related records, search results, counts, history, and update streams can all reveal information, so authorization must apply beyond the first object lookup.

• Request only the properties and relationships needed by the view.
• Do not infer unrestricted access from an object reference or a successful earlier query.
• Distinguish empty visible results from evidence that an event did not occur.
• Handle changes in access during a session, including subscriptions and already-displayed information.
• Avoid exposing protected details in error messages or client-side diagnostics.

For North Yard, permission to read Gate B might allow its operating status without allowing every associated Person record or an incident from another site. An application should describe unavailable context without revealing the protected details themselves.

Open evidence through its own access path#

flowchart TD
  A[Authorized ontology query] --> R[Record with evidence reference]
  R --> E[Separate evidence access request]
  E --> C{Access allowed and file available?}
  C -->|Yes| V[Show permitted evidence]
  C -->|No| U[Show unavailable evidence]

A reference allows the application to associate a record with supporting material. It does not require the ontology to hold the media file or continuously ingest every video stream. The evidence may remain in an authorized external system.

Evidence can expire, be deleted, or become inaccessible while the structured record remains. The application should indicate that limitation rather than silently substituting an unrelated file or implying that the source was reviewed.

Separate visibility from authority to act#

Reading an agent’s location does not authorize dispatch. Seeing a gate’s state does not authorize opening it. Requests must be assessed for the actor, operation, target, required approvals, and current operating constraints.

Plan records and retention#

Decide which information is needed for the workflow, who may review it, and how long structured records and evidence should remain available. Those decisions depend on the customer-authorized deployment and source systems.

Operational review needs to distinguish the source report, a later interpretation, the actor’s decision, and the action outcome. That requirement does not imply a particular internal storage design or a tamper-evidence certification.

• Agree on the data and evidence permitted for the evaluation.
• Define who reviews uncertain associations and corrects source mappings.
• Establish what happens when evidence expires or a source is removed.
• Confirm deletion, export, and retention behavior for the actual deployment instead of assuming it from the conceptual model.

• Connecting existing systems

  Check source authorization and compatibility before onboarding.

• Developer model

  Apply permission boundaries to queries, subscriptions, and action requests.