Approach

A shared, software-readable description of the objects your organisation runs on, the actions taken against them and the models that improve those actions. Every MetaTeam division builds against it.

Adaptive layerWhat learns?Kinetic layerWhat happens?Semantic layerWhat exists?Foundation layercloud · on-premises · pipelines

Why a model

Three layers

What exists?

Semantic layer

Objects, their properties and the links between them, unified from every source into a single resolved representation with history. Customers, accounts, assets, vehicles, orders, campaigns, content, segments.

  • Object types and properties
  • Links and cardinality
  • Identity resolution
  • History and lineage
What happens?

Kinetic layer

The actions that change object state and the systems that carry them out: applications, integrations, autonomous processes, campaigns and lifecycle programmes. Every action is defined, permissioned and logged.

  • Actions and permissions
  • Workflows and processes
  • Integrations and APIs
  • Audit and write-back
What learns?

Adaptive layer

Models, measurement and experimentation that read outcomes and improve the next decision: prediction, optimisation, attribution, anomaly detection, with monitoring so improvement is verified rather than assumed.

  • Predictive and generative models
  • Metrics and attribution
  • Experiments and holdouts
  • Monitoring and feedback

Foundation layer

Beneath the three layers sits the infrastructure that hosts them: public, private, hybrid or on-premises environments and the pipelines that move data between them. The model is environment-agnostic; the foundation is chosen to meet your residency, latency and cost constraints.

Anatomy of an object

  • PropertiesThe attributes that describe it, with source, type and freshness known.
  • LinksIts relationships to other objects, so context is one traversal away.
  • ActionsWhat can be done to it, by whom, through which system.
  • SignalsThe measures and model outputs attached to it, updated as events arrive.
objectVehiclePropertiesRegistrationFleetLast positionOdometerLinksDriverRouteDepotMaintenance contractActionsAssign routeSchedule serviceFlag exceptionRetireSignalsUtilisationFailure probabilityFuel efficiencyGeofence status

Method

Decision inventory

  1. 01

    Decision inventory

    We start with the decisions that matter most and work backwards to the objects, actions and signals they need. Weeks, not months.

  2. 02

    Object definition

    Workshops with domain owners define each object once, with source systems, properties, links and permitted actions written down.

  3. 03

    Implementation

    Pipelines, services, interfaces and models are built against the definitions. The model itself lives in version control alongside the code.

  4. 04

    Stewardship

    A named owner for each object, a change process and monitoring keep the model accurate as the organisation changes.

Principles

  1. 01

    Define once, use everywhere

    An object has one definition. Systems adapt to it, not the reverse.

  2. 02

    Every action is explainable

    Automated or manual, each state change records who, what, why and through which system.

  3. 03

    Measurement is part of delivery

    Nothing ships without the signals that show whether it is working.

  4. 04

    Your data stays yours

    Models and measurement run inside your environment on your data, independent of any platform's reporting.

  5. 05

    Smallest sufficient system

    We choose the simplest architecture that meets the requirement, then earn complexity with evidence.

Contact

A decision inventory takes two weeks and produces a first draft of the model.

info@metateam.devReply within two working days.