Core Operations Data Ontology¶

This page is the small starting point. It defines the minimum ontology that connects product thinking to operational data.

BetterFleet's core problem is matching fleet work to available energy through time. The minimum ontology is work, fleet, vehicle, energy requirement, energy system, and charging.

work is the top-level demand signal.
work generates energy requirement: the energy needed to complete assigned work with policy margin.
fleet is the operational set of vehicles that dispatch and schedules act on.
vehicle is the atomic delivery asset within the fleet.
energy system is the supply side: energy sources, energy resources, power limits, and live power state.
charging is the coupling point where energy requirement meets energy availability.
vehicle activity, vehicle_state_timeline, and trip_observation are projections and feeds, not ontology roots.

Core Ontology¶

Concept	Meaning	Includes
`work`	The demand placed on the fleet	routes, schedules, blocks, duties, dispatch assignments
`fleet`	The operational set of vehicles managed together to perform work	readiness pool, depot fleet, tenant fleet, route-serving fleet
`vehicle`	The physical asset that performs work and consumes energy	vehicle identity, model, capability profile
`energy requirement`	The required energy outcome implied by work and policy	route energy need, readiness target, reserve margin, charge deadline
`energy system`	The sources, resources, and constraints that can provide or limit power	grid connection, site, microgrid, chargers, storage, generation, site load, operating envelopes, live power state
`charging`	The mechanism that allocates energy from the energy system to vehicles	charging intent, charging session, charging control, charging outcome

Relationship Map¶

flowchart LR
  Work["Work"]
  Requirement["Energy Requirement"]
  Fleet["Fleet"]
  Vehicle["Vehicle"]
  Energy["Energy System"]
  Charging["Charging"]
  Delivery["Fleet Delivery"]

  Work --> Requirement
  Work --> Fleet
  Fleet --> Vehicle
  Requirement --> Charging
  Energy --> Charging
  Charging --> Vehicle
  Vehicle --> Delivery
  Work --> Delivery

The strategic logic is:

work is the top-level demand signal
work creates energy requirement
fleet and its vehicle are the delivery assets assigned to satisfy work
the energy system describes what energy and power can actually be supplied
charging is the matching mechanism between energy requirement and energy system
successful fleet delivery depends on both vehicle execution and energy allocation

Product Ontology Mapping¶

Product domain	Primary ontology focus	Why
Smart Charging	`energy requirement`, `energy system`, `charging`	decides how available power is allocated to meet vehicle and fleet needs
Energy & Cost Management	`energy requirement`, `energy system`, `charging`	decides where energy comes from, what it costs, and how to optimise its use
Operations & Dispatch	`work`, `fleet`, `vehicle`, `energy requirement`	decides what work must be done, which vehicles do it, and whether the energy position is sufficient
Roaming & Shared Charging	`charging`, `energy system`, `fleet`	governs access, entitlement, allocation, and commercial meaning of charging outside the home context
Incidents & Notifications	cross-cuts all concepts via operational state and failure signals	explains what is broken in work execution, vehicles, charging, or energy availability
Reporting & Insights	cross-cuts all concepts via history and derived metrics	explains performance, utilisation, cost, carbon, and reliability over time
Resilience & Security	cross-cuts all concepts via trust, access, and control integrity	ensures the operational model is safe, governable, and auditable

Projections And Feeds¶

Different data sources should project onto the core concepts rather than define them.

Projection	What it is really showing
`vehicle activity`	the operational projection of how a vehicle is moving, assigned, charging, available, and failing through time
`vehicle_state_timeline`	a state-stream feed into `vehicle activity`
`trip_observation`	an episode feed into `vehicle activity` and `work` execution
`charging_session`	an episode feed into `charging`
`site_power_state`	a live state view of the `energy system`

This keeps the ontology aligned to the domain rather than to source-system boundaries.

Ownership By Core Concept¶

Concept	Evidence	Knowledge graph role	Control
`work`	scheduling and dispatch systems	resolves work relationships, dependencies, and execution history	operations and dispatch
`fleet`	fleet and asset-management systems	resolves fleet membership and cross-system identity	fleet operations
`vehicle`	asset registry and identity systems	resolves identity, capability references, and historical joins	fleet operations
`energy requirement`	derived from work, policy, and vehicle facts rather than directly captured in one source	computes and publishes the requirement projection with lineage to its inputs	dispatch and charging orchestration use it for decisions
`vehicle activity`	telematics, trip, charging, and incident sources each own their own evidence	resolves them into one time-valid operational vehicle view	operations, dispatch, and charging read it; none should overwrite it directly
`energy system`	microgrid, charger, metering, and control systems own their respective evidence	resolves them into one supply-side operational view	energy orchestration and charging control
`charging`	charging transactions, status, and control records	resolves charging history and joins it to work, vehicles, and energy state	charging orchestration

Vehicle Activity Projection¶

vehicle activity is the operational projection that tells us what a vehicle is doing and whether it is capable of doing the next piece of work.

Its internal ontology should be:

Sub-concept	Meaning	Typical evidence feeds
`mobility state`	where the vehicle is, whether it is moving, and what movement episode it is in	telematics location and motion data, trip records
`assignment state`	what work the vehicle is assigned to now or next	schedules, blocks, duties, dispatch assignments
`energy state`	how much usable energy the vehicle currently has and what margin remains	SoC telemetry, battery metadata, charging history, prediction outputs
`charging state`	whether the vehicle is charging, waiting, blocked, or complete	charging sessions, charger status, control events
`readiness state`	whether the vehicle can satisfy the next work obligation under policy	derived from assignment, energy, charging, and fault state
`health state`	whether faults, incidents, or degraded conditions affect operation	incidents, diagnostic events, telematics anomalies

In practice it should combine:

movement and location state
assignment and work state
battery and energy state
charging state
availability and readiness state
fault and incident state

Its major feeds are:

vehicle_state_timeline
trip_observation
charging_session
incident and fault events

The knowledge graph role is to:

preserve lineage back to the evidence that supports each aspect of vehicle activity
resolve conflicting or overlapping evidence in time
publish one operational vehicle view without claiming to own the raw evidence

Vehicle Activity Data And Source Relation¶

Layer	Role
Actual data	raw telemetry, trip records, charging records, assignment records, incidents, and control history
Source systems	the systems that capture and own those records
Knowledge graph	the semantic layer that joins those records into `vehicle activity` and exposes time-valid relationships
Operational consumers	dispatch, charging, incident handling, reporting, and prediction flows that read the projection

Energy System Internal Ontology¶

energy system is a first-class ontology concept because it is the supply side of the operating model.

Its internal ontology should be:

Sub-concept	Meaning	Typical evidence feeds
`energy source`	where energy originates	grid connection state, generation telemetry, storage discharge state, market import/export state
`energy resource`	which physical assets can convert, move, store, or allocate energy	chargers, storage systems, generation assets, controllable site assets
`topology state`	how the energy system is physically structured	microgrid topology, node and circuit mappings
`power state`	what power is flowing, available, committed, or curtailed right now	meter telemetry, charger telemetry, site load telemetry
`energy state`	what stored energy exists and what usable energy remains in stationary assets	storage SoC, storage capacity, forecast reserve state
`constraint state`	what limits apply now	operating envelopes, node limits, charger limits, safety limits, policy limits
`allocation state`	what supply has already been committed to which vehicles or services	charging plans, active sessions, reserved capacity, control setpoints
`quality state`	whether the energy system can be trusted operationally	outages, telemetry freshness, deratings, control-path failures

In practice it should include:

energy sources: grid supply, local generation, stored energy
energy resources: chargers, storage assets, controllable site assets
power state: live load, available capacity, committed capacity, fallback limits
operating constraints: envelopes, topology limits, charger limits, site policies
quality and fault state: outages, degradation, deratings, telemetry loss

Its major projections and feeds are:

site_power_state
charger and connector status
meter and circuit telemetry
operating envelopes and control status

The knowledge graph role is to:

resolve one supply-side operational view from multiple evidence owners
distinguish source, resource, constraint, and allocation semantics cleanly
keep lineage from derived supply state back to raw metering, control, and topology evidence

Energy System Data And Source Relation¶

Layer	Role
Actual data	meter readings, charger status, topology state, operating envelopes, storage telemetry, generation telemetry, control history
Source systems	microgrid control, charger/connectivity services, metering systems, external constraint providers
Knowledge graph	the semantic layer that joins those records into the `energy system` view and the `energy requirement -> charging -> supply` relationship
Operational consumers	smart charging, energy optimisation, dispatch confidence, incident handling, reporting

Strategic Uses¶

Problem	Core concepts involved
dispatch feasibility	`work`, `fleet`, `vehicle`, `energy requirement`, `vehicle activity`
schedule confidence	`work`, `fleet`, `vehicle`, `energy requirement`, `vehicle activity`
smart charging	`energy requirement`, `energy system`, `charging`, `vehicle activity`
energy optimisation	`work`, `energy requirement`, `energy system`, `charging`
incident diagnosis	`vehicle activity`, `energy system`, `charging`
prediction and planning	all of the above, over time

Growth Rules¶

When this ontology grows, keep it disciplined:

add a new concept only when it introduces a new real-world noun or decision boundary
prefer top-down operating concepts over source-system concepts
treat new data feeds as projections onto existing concepts until proven otherwise
keep joins time-valid and UTC-safe
keep the model centred on operational truth, not on repo boundaries or report structures