Skip to content

InsightsTechnical report

The operating record: a data model for how a company runs

One line per event, written by agents and people, kept beside the ERP, and traceable to the message, call, document or person it came from.

Authors
Qantara Research
Published
Reading time
19 min
Topics
Data model, Event logs, Provenance, Agents

Abstract

Agents that work inside a company's operations need a record of how it actually runs, and the systems most companies have do not keep one. ERP tables are reliable but incomplete, data warehouses inherit their gaps, and many decisions that move goods in the Gulf are taken on a call and corrected on WhatsApp. This technical report asks what data model should sit under every agent. We review event sourcing, process mining and its object-centric event log standard, W3C provenance, knowledge graphs and bitemporal databases, and compare five models on five properties: capturing decisions made off-system, keeping provenance, separating valid time from record time, being readable by agents, and being exportable. We then specify the operating record: an append-only log of one line per event, written by agents and people, kept beside the ERP, with eleven fields in Arabic and English and two times per line. No prior model we reviewed has all five properties; OCEL 2.0 comes closest and is our export target. This is a design report and reports no deployment results.

Key findings

  1. The process mining manifesto rates ERP tables as trustworthy but not necessarily complete, and events recorded by hand, where off-system decisions live, as the lowest of its five quality levels.
  2. Of the five data models we compare, only the operating record is designed to have all five properties an agent needs; this is a property of the design, not a measured result.
  3. OCEL 2.0 is the closest open model, but it gives each event one timestamp and has no field for who wrote a line or who approved it.
  4. Provenance and time belong inside the line: a knowledge graph needs reification, named graphs or edge attributes to express them, so the record stays a flat log.
  5. Compounding is a property of the data model: a second agent starts from the lines the first wrote.

1Introduction

On a Sunday morning a caterer's buyer in Sohar confirms the weekly order on WhatsApp: ghee, and fifty cartons of oil. On Monday the sales manager of the distributor's Dammam branch agrees a discount with a contractor by phone. On Tuesday the buyer writes again: the oil should have been forty cartons. In many companies none of these decisions reaches the ERP as it was taken. The discount surfaces weeks later as a lower price with no reason attached; the correction is typed over the original quantity, and what the warehouse was told on Monday is gone. These events are an illustrative example, written by us, and recur through this report.

This matters more once software acts. An agent that confirms orders or chases payments reads some record of the company before it acts and writes something after. If it reads only the ERP, it acts on the part of the operation that was keyed in. If what it writes cannot be traced to the message it acted on and the person who approved it, nobody can check it. What sits under the agents decides what they can know and what can be audited.

The Gulf sharpens the problem. Operations often run partly outside their software: a delivery note is signed on a tailgate and photographed into a WhatsApp group, terms are agreed on a call in Arabic, and a spreadsheet beside the ERP holds what the ERP has no field for. An order may arrive in Arabic and be invoiced in English, and a distributor with branches in Oman and Saudi Arabia works in two currencies and two time zones. A data model for agents here must hold both scripts, every channel and the reason behind each event, and say where each line came from.

This report makes four contributions:

  1. A comparison of five data models against five properties that a record read and written by agents needs (section 3).
  2. A specification of the record line: eleven fields, two times and two scripts, with an illustrative example (section 4).
  3. A mapping of each field to OCEL 2.0 and W3C PROV, for reading with open tools and for export (sections 4, 6 and 9).
  4. An account of how a second agent starts from what the first wrote, which is what we mean by compounding (section 8).

2Background and related work

What the ERP and the warehouse keep

The manifesto of the IEEE Task Force on Process Mining, published in 2012, grades event logs on five levels [1]. Tables in ERP systems sit at three stars of five: recorded automatically and trustworthy, in that a payment the ERP records actually exists, but not necessarily complete. One level down, people can bypass the system, so events may be missing. At the lowest level, events are recorded by hand and may neither match reality nor be complete; the manifesto's examples are trails left in paper documents. A decision taken on a call or corrected on WhatsApp sits below even that: unless someone writes it down, it is not recorded at all.

The data warehouse cannot repair this, because it is built from the same systems. In Kimball's dimensional method the grainWhat one row of a fact table stands for: one scan at a till, one invoice line, one shipment. Kimball's method fixes it before anything else in the design. of a transaction fact table is a measurement event at a point in space and time [2], and those events are the ones the source systems captured. The warehouse can also lose what the source kept: a type 1 change overwrites the old value, which, the method's documentation notes, destroys history [3]. Both designs keep accounts and report on them well. Neither was built to keep the reasons, channels and people behind each event.

Information systems research has studied the gap between the process as designed and the process as run. Alter's theory of workarounds, which covers most situations in which workarounds occur in operational systems, describes how and why they are created and helps explain compliance and noncompliance with management mandates [4]. A record of the designed process misses the adaptations an agent most needs to know.

Event sourcing and the append-only log

Event sourcingA way of building software in which every change is stored as an event, in order, and the current state is computed from the events rather than overwritten in place., as Fowler described it in 2005, captures every change to an application's state as a sequence of events, so the state at any past moment can be rebuilt by replaying them [5]. Helland takes the idea down to the database, where transaction logs record every change and tables hold only the latest values; his analogy is the ledger, corrected by adding entries, never by erasing [6].

The truth is the log. The database is a cache of a subset of the log.

Pat Helland, Immutability Changes Everything, CIDR 2015 [6]

The operating record applies the same stance to the business rather than the software.

Process mining and the object-centric event log

Process mining discovers, monitors and improves real processes, not assumed ones, from event logs [1]. Its classic input gives each event a case identifier, an activity and a timestamp; its exchange format, XES, has been an IEEE standard since 2016, revised in 2023 [7]. One case is often not enough: an order may ship in several deliveries, and one delivery may carry lines of several orders [1]. Van der Aalst named the failures that follow from forcing such data into single cases: one event related to several cases (convergence) and repeated activities within one case (divergence) [8].

The answer was the object-centric event log. OCEL 1.0, introduced in 2020, related each event to objects of several types. OCEL 2.0Object-centric event log, version 2.0: an open format from the process-mining community in which each event can relate to many objects, such as an order, its items and a delivery, rather than to a single case., specified in 2024, added qualified relations between objects, qualifiers naming the role an object plays in an event, and object attributes that change over time, in three exchange formats: SQLite, XML and JSON [9]. Its site also lists CSV and a bundled CSV and Parquet format, as read on 14 October 2026 [10]. Of the open models we reviewed, OCEL 2.0 is the closest to what an operating record needs.

Provenance

The W3C PROV family, published on 30 April 2013, defines provenanceThe record of where a piece of data came from: who or what produced it, from what, and how, so that someone else can judge whether to trust it. as information about the entities, activities and people involved in producing a piece of data or thing, used to judge its quality, reliability or trustworthiness [11]. Its data model, PROV-DM, has three types: an entity is a thing with some fixed aspects, an activity occurs over time and acts upon or with entities, and an agent bears some responsibility for an activity [12]. An entity is attributed to an agent, an activity is associated with an agent in a role, and one entity is derived from, or is a revision of, another. PROV-O encodes the model for the semantic web [11]. The record borrows PROV's first distinction: the agent who did a thing and the agent a line is attributed to are not always the same.

Knowledge graphs

Hogan and colleagues' survey sets out how knowledge graphs represent data, schema, identity and context [13]. Context is the part that matters here. Many facts hold only from a date, in a place or according to a source. To attach a date or a source to one edge, a graph must turn the relation into a node, or use reificationMaking a statement about a statement: turning one edge of a graph into a node of its own, so that a date, a source or an approver can be attached to it., named graphs, property-graph edge attributes or RDF-star; and a reified edge does not assert the edge it reifies. Graphs are also commonly read under an open-world assumptionThe rule that a fact missing from the data is unknown rather than false. Its opposite, the closed-world assumption, treats what is not recorded as not true.. Both suit joining knowledge across many sources. Both are costs for a record whose questions are closed: was this order delivered in full, and who approved the discount?

Two times

Snodgrass and Ahn named the two times in 1985: valid time, when a fact holds in reality, and transaction time, when it was stored; a database that keeps both shows what was believed at one moment about another, retroactive changes included [14]. SQL:2011 standardised both, as application-time period tables and system-versioned tables, which one table may combine [15]. Fowler calls them actual history and record history, and works through a pay rise recorded late and then corrected [16]. We say valid time and record time.

Memory for agents

Agent research reached a similar structure from another side. Park and colleagues' generative agents store a complete record of each agent's experiences in natural language and retrieve from it to plan [17]. A longer prompt is no substitute: language models use information at the start or end of a long input better than in the middle [18]. An agent should read the slice of the record its task needs.

Figure 1. Every part of the record is older than the agents that write to it

Read top to bottom: each item is a published model or standard that the operating record draws on, with the month or year it appeared.

  1. May 1985Valid time and transaction time namedSnodgrass and Ahn, SIGMOD 1985: keep both, and see what was known when.
  2. Dec 2005Event sourcing describedFowler: every change to state captured as a sequence of events.
  3. Dec 2011Temporal tables in SQL:2011Application-time and system-versioned tables enter the SQL standard.
  4. 2012Process mining manifestoERP tables at three stars of five; events recorded by hand at one.
  5. Apr 2013W3C PROV publishedEntities, activities and agents, and how each was derived and attributed.
  6. Jan 2015Immutability changes everythingHelland, CIDR 2015: correct by appending, never by erasing.
  7. 2016XES becomes IEEE 1849The exchange format for single-case event logs; revised in 2023.
  8. 2019Object-centric process miningVan der Aalst: one case notion causes convergence and divergence.
  9. 2021Knowledge graphs surveyedHogan and colleagues, ACM Computing Surveys: context on an edge needs reification, named graphs or edge attributes.
  10. Mar 2024OCEL 2.0 specifiedQualified object relations and changing object attributes, in SQLite, XML and JSON.
Sources: Snodgrass and Ahn [14]; Fowler [5]; Kulkarni and Michels [15]; the process mining manifesto [1]; W3C PROV [12]; Helland [6]; IEEE 1849 [7]; van der Aalst [8]; Hogan and colleagues [13]; Berti and colleagues [9]. Compiled by Qantara, 14 October 2026.

3What an agent needs from a record

We take five properties from the gaps above. Each is a question that an owner, an auditor or the next agent will ask of a line.

  • Captures decisions made off-system. There is a place for an event that reached no system, such as a call, a WhatsApp message or a signed note, with the channel it came on.
  • Keeps provenance. Every line names its source document, who did the thing, who wrote the line and who approved it.
  • Separates valid time from record time. A correction is a new line, and the record answers both what happened and what was known at a given moment.
  • Readable by agents. An agent can pull the lines for one order, customer or week, in a form a language model reads without first learning a schema.
  • Exportable. The whole record can leave in open formats that other tools already read.
Figure 2. Five data models against five properties

Each row is a data model and each column a property; a filled mark means the model has a place for the property by design, a half mark that it can be made to hold it with extra work, an empty mark that it does not.

ItemCaptures off-system decisionsKeeps provenanceValid and record timeReadable by agentsExportable
ERP No Partial Partial Partial Partial
Data warehouse No Partial Partial Yes Yes
Knowledge graph Partial Partial Partial Partial Yes
Event log (OCEL 2.0) No Partial No Yes Yes
Operating record Yes Yes Yes YesDesign goal
Qantara's assessment, 14 October 2026, from the sources discussed in section 2: the process mining manifesto [1], Kimball [2, 3], Hogan and colleagues [13] and the OCEL 2.0 specification [9]. The operating record's row describes its design, not a measured deployment; its export is a design goal.

The ERP records what was keyed in, and the manifesto places hand-recorded events, where off-system decisions live, at its lowest level [1]. An ERP typically records which user entered a transaction, not the message it came from; its documents carry business dates and many systems keep change logs, but master data is commonly updated in place; and its tables, which the manifesto counts in the thousands for an ERP such as SAP, are hard for an agent to read without a guide.

The warehouse is readable and exports easily, but its rows are the events the source systems captured [2], and whether it keeps history depends on the modeller's choice of change type [3]. The knowledge graph can represent provenance and time, but only through the context mechanisms above [13]. The OCEL 2.0 log is flat, readable and exportable, and its attributes can name who performed an event; but each event has one timestamp, nothing records when or by whom the event was logged, and the log is filled by extraction from information systems, not from calls and messages [9].

4The record line

One line per event

The unit of the operating record is the line: one event in the operation, such as an order confirmed, a delivery moved, a discount given or a carton found short. Following OCEL 2.0 [9], a line links to the objects the event concerns, each link carrying a qualifierIn OCEL 2.0, a short label on a link between an event and an object that says what role the object played, such as the customer, the approver or the source.: the order, its products, the delivery, the customer. Objects carry attributes that change over time and relate to one another, as an invoice to a delivery and a delivery to an order. Lines are appended, never edited, and an order's current state is what its lines add up to.

Two kinds of line share one shape. Operational lines say what happened in the business; log lines say what an agent did: what it read, proposed and wrote, and what it asked a person. So "what did the collections agent read before that reminder?" is answered by the same kind of query as "what happened to this order?".

The record sits beside the ERP, which remains where the accounts are kept. When an agent writes to the ERP it also writes a line to the record, with the ERP's document number as its source, and an event that reaches the ERP by another route can be written from the ERP entry. The record adds what the ERP does not hold: the channel, the reason, the writer, the approval and the events that never reached the ERP.

The fields

A line has eleven content fields, the questions an owner asks of any event, and two that keep time and corrections. The table defines each, with its nearest place in OCEL 2.0 and W3C PROV, which governs export.

Table 1. The fields of a record line, with their nearest equivalents in OCEL 2.0 [9] and PROV-DM [12]. The first eleven are the line's content; the last two keep time and corrections. The mappings are ours.
FieldWhat it holdsIn OCEL 2.0In W3C PROV
WhoThe person, agent or party who did what the line records, which may differ from who wrote itAn object linked with a qualifier such as actorAn agent associated with the activity
WhatThe type of event, from a short list agreed for each workflow, with a one-line description in both scriptsThe event typeThe activity
WhereThe site: branch, warehouse, port or customer's premisesAn event attribute, or an object of type siteThe prov:location attribute
WhenValid time: when it happened in the operation, with the place's offset from UTCThe event timestampThe activity's start or end time
For whomThe party the event serves: customer, supplier or branchAn object linked with a qualifier such as customerAn agent associated with the activity, with a prov:role
ChannelHow it reached the record: WhatsApp, email, call note, ERP entry, photo or paperAn event attributeAn attribute of the source entity
DocumentA pointer to the original, kept as it came: a message identifier, a file, an ERP document number, a call noteAn object of type document, linked with a qualifier such as sourceThe entity the line was derived from
CostAmount and currency, where the event has oneAn event attributeNot modelled; an attribute
WhyThe reason given, in the words of the person or message that gave itAn event attributeNot modelled; an attribute
Written byThe agent or person who wrote the line, under credentials of their ownNot modelled; an event attributeAttribution of the line to an agent
Approved byThe person who approved it above a threshold and the rule that applied, or the rule under which no approval was neededNot modelled; a separate eventA separate approval activity that informed this one
Recorded atRecord time: when the line was writtenNot modelledThe line's generation time
SupersedesThe line this one corrects, if anyNot modelledA revision of the earlier line

Each line also has an identifier and a list of the objects it links to. Who, for whom and where point to objects (people, parties, sites) rather than holding free text.

Two scripts on one line

Every value a person reads is kept in Arabic and in English under the same field names, so the agent that writes a line and the person who checks it see the same thing. The source's value is kept as written, and the other script is marked as a rendering. Names of people, places and products link to their objects rather than being re-spelt in each line, so a customer whose name is written three ways in Latin script stays one customer. Mixed-direction text is stored in logical order and displayed by the Unicode Bidirectional Algorithm [19]. Times carry the local offset from UTC, as RFC 3339 allows [20], so lines from Sohar and Dammam sort correctly. Amounts carry their currency, and a Hijri date on a document is kept as written beside its Gregorian equivalent.

An illustrative line

Below is an illustrative example of one operational line, written by us: Sunday's order as an orders agent would write it from the buyer's WhatsApp message. The document reference follows the shape of the identifier the WhatsApp Cloud API gives each incoming message, which arrives with its own timestamp [21]. JSON exchanged between systems must be UTF-8 [22], so the Arabic travels intact.

{
  "id": "line-000318",
  "what": {
    "type": "order.confirmed",
    "en": "Order confirmed: ghee and oil",
    "ar": "تأكيد الطلب: سمن وزيت"
  },
  "who": { "type": "person", "id": "person-0291", "role": "buyer", "of": "customer-0412" },
  "where": { "type": "site", "id": "site-sohar", "en": "Sohar branch", "ar": "فرع صحار" },
  "when": "2026-10-11T08:40:00+04:00",
  "for_whom": { "type": "customer", "id": "customer-0412", "en": "A caterer", "ar": "شركة تموين" },
  "objects": [
    { "type": "order", "id": "order-55120", "qualifier": "confirmed" },
    { "type": "product", "id": "ghee-tin", "qualifier": "ordered", "quantity": 20 },
    { "type": "product", "id": "oil-carton", "qualifier": "ordered", "quantity": 50 }
  ],
  "channel": "whatsapp",
  "document": { "type": "whatsapp_message", "ref": "wamid.illustrative-0001", "language": "ar" },
  "cost": { "amount": 412.5, "currency": "OMR" },
  "why": { "en": "Their weekly order", "ar": "طلبهم الأسبوعي" },
  "written_by": { "type": "agent", "id": "orders-agent", "deployment": "deployment-01" },
  "approved_by": { "status": "not_needed", "rule": "Order within the customer's credit limit" },
  "recorded_at": "2026-10-11T08:41:12+04:00",
  "supersedes": null
}
An illustrative record line, written by us. Identifiers, quantities and the amount are invented; the Arabic values are renderings for the example.
Figure 3. What a record line joins

Follow the arrows into the line from the left, and out of it to the right: a channel delivers a document, an actor does the thing, a person may approve it, and the line links the objects it concerns and is read by the next agent.

sourceapproveslinksread byChannelWhatsApp, email, call, ERPDocumentThe original, as it cameActorWho did it; who wrote itThresholdSet by the customerApprovalA person decides above itRecord lineOne event, appendedObjectsOrder, delivery, invoiceThe next agentReads before it acts
Qantara's design of the operating record, 14 October 2026. The entities follow OCEL 2.0 for events and objects [9] and PROV-DM for actors, documents and attribution [12].

5Valid time and record time

Every line carries two times, which makes the record bitemporalKeeping two times for every fact: when it was true in the world, and when the record learned it. Corrections then add to the history instead of overwriting it.. When is valid time, the moment the event happened in the operation; recorded at is record time, the moment the line was written. In operations they often differ: a call note is written hours after the call, a photograph of a signed delivery note reaches the WhatsApp group the next morning, and a correction about Sunday's order arrives on Tuesday.

Corrections never edit a line. A correction is a new line with the same valid time as the line it corrects, a later record time and a pointer to the line it supersedes. The table follows the introduction's week.

Table 2. Three lines from the introduction's week, an illustrative example. Line 327 corrects line 318: the same valid time, a later record time. Times are local to each branch.
LineWhatWhen (valid time)Recorded atWritten bySupersedes
318Order confirmed: ghee, and 50 cartons of oilSun 08:40, SoharSun 08:41Orders agent, from the buyer's WhatsApp messageNone
322Discount given: repeat buyerMon 14:10, DammamMon 16:30Sales manager, from their note of the call; approved by the sales manager, above the agent's limitNone
327Order corrected: 40 cartons of oil, not 50Sun 08:40, SoharTue 09:05Orders agent, from the buyer's WhatsApp message318

Two questions now have two honest answers. Asked on Monday evening, what had the caterer ordered? Fifty cartons: that is what the warehouse was told, and if a van was loaded with fifty on Monday, the record shows why. Asked today, what did the caterer order on Sunday? Forty. A system that overwrites the quantity gives only the second answer. The bitemporal record gives both, which is what an auditor, a dispute over a short delivery or the next agent needs [14, 16].

Whether Tuesday's message corrects Sunday's order or amends it is a business question. A correction changes what was true on Sunday; an amendment is a new event on Tuesday. The engineers settle the rule for each workflow with the team that runs it, and the line's type carries the distinction, so no agent has to guess.

6Provenance and approval

Four fields carry the trace, channel, document, written by and approved by: where a line came from, what it was read from, who put it in the record and who allowed it. Who and written by are kept apart because they often differ: the buyer confirmed the order and the orders agent wrote the line; the sales manager gave the discount and wrote the line from their own note. In W3C PROV terms, the event is an activity associated with the buyer, the line is an entity attributed to the agent that wrote it, and the message is the entity it was derived from [12].

Approval is a line of its own. Above a threshold the customer has set, the agent prepares the case and a person decides; the decision is written as a line with the approver, the rule that sent the case to them and the time, and the approved line points to it. Below the threshold, the field names the rule under which no approval was needed. Either way the record shows what the approver saw, because what the agent read before asking is in the log lines.

Agents write under their own names. Each signs in with credentials of its own, scoped to one deployment and revocable, so written by names one agent in one deployment, never a shared account, and every read and write it makes is a line in the log. In our design, an agent that cannot attribute an event to a source does not write the line; it raises the event to a person.

7Why the record is not a knowledge graph

A knowledge graph could hold all of this. We keep the record simpler, for three reasons.

  • Context is the common case. Every line needs a time, a source and a writer, and many need an approver. A graph attaches that context through reification, named graphs or edge attributes [13]; the record makes it a field. A line is already the node a graph would create to carry its context.
  • The questions are closed. Was the order delivered in full? Who approved the discount? These want definite answers, and absence is information: no approval line means no approval. The open-world reading that suits joining knowledge across sources is the wrong default for operations.
  • People and agents both read it. A line of named fields in two scripts can be read by the person who checks it and by a language model, with no query language or schema to learn.

The record keeps a graph's best idea, objects related to one another, through the qualified object-to-object relations of OCEL 2.0 [9]. A graph can be built from the record later. The reverse, recovering when a fact was learned and from which message, cannot be done once it was never written down.

8How the next agent starts

Compounding, as we use the word, is a property of the data model. Nobody tells the collections agent an invoice went out: it reads the line the orders agent wrote when the invoice was issued, on the day the customer's terms say, and writes its own line when it sends a reminder in Arabic. Later the supplier follow-ups agent reads the delivery lines both depend on. Each workflow added starts from what earlier ones wrote: customers, terms, and the reasons behind past exceptions.

Three choices make this work:

  1. Shared objects. Agents refer to the same order, customer and invoice by the same identifiers, so one agent's line is found by another.
  2. Narrow reads. An agent pulls the lines for one object, event type or window of time, in order of valid time, not the whole record, because language models use long inputs unevenly [18].
  3. Reasons as data. The why field shows the next agent that a price was lowered for a repeat buyer, with approval, before it flags the invoice as wrong.

This resembles the memory stream of generative agents [17], with two differences: the record is shared by many agents and people rather than private to one, and every entry carries its source, writer and approver, because in operations the question is not only what an agent remembers but whether anyone can check it.

9Export in open formats

A record that only one vendor's software can read is a risk for the company that relies on it. We therefore treat export as a design goal of the data model: the record should be able to leave at any time in standard, readable formats. This report states the goal; it is not a contractual commitment, and the formats a deployment exports are agreed in writing.

The mapping is direct. Lines become OCEL 2.0 events, objects become OCEL 2.0 objects with changing attributes, and qualifiers carry roles [9], written in the standard's JSON, XML or SQLite formats for process-mining tools. The fields OCEL 2.0 does not model, record time, written by and approved by, travel as event attributes, and the full trace can be written in W3C PROV [12]. UTF-8 JSON keeps the Arabic as written [22].

Export loses one thing, and we say so: a process-mining tool sees one timestamp per event, so it sees the record as it stands now, not as it was known at a past moment. That history stays in the export's attributes, but standard tools will not use it unaided.

10Implications for deployment

For a Gulf company putting agents into its operations, the data model is the decision that is hardest to change later. Four practical points follow.

  • Start the record with one process. The first workflow defines the first objects and event types; later ones reuse them. Our engineers work on site, write down how the work really runs, including the calls and WhatsApp groups, and record a baseline before any agent acts.
  • Write off-system events on purpose. A call leaves no record unless someone writes one. The record has a channel for call notes and a field for the reason; the habit of using them is built with the team.
  • Decide where it lives before it fills. The record and its log are kept in the customer's country, and for each workflow we state in writing which model reads what, and where it runs. Each agent is run on the customer's past cases before it goes live, with their team marking what good looks like, and acts alone only within the customer's thresholds.
  • Ask any vendor the same questions. For a given line: which message did it come from, who wrote it, who approved it, when was it known, and can it leave in an open format? A data model that cannot answer will not improve with more agents on top.

The record keeps Arabic and English on the same line because the same order, message and call are in both. That is in the fields from the first line, not a translation step added at the end.

11Limitations

This is a design report. It describes a data model and compares it with prior work; it reports no deployment, measurement or customer result. Figure 2 is our assessment from the cited sources, not a benchmark, and other readers could grade some cells differently.

  • Capture depends on people. The record has a place for a decision taken on a call, filled only if someone writes the note or an agent is party to the conversation. We have no evidence yet on how complete the record becomes in practice.
  • The why field is only as good as its source. A reason given in a message may be partial or wrong; the record keeps what was said and by whom, not what was true.
  • Event types drift. Two workflows can name one event differently, and a shared list of types needs upkeep, as any schema does.
  • Personal data. Lines name people and carry their messages. Data protection law differs across the Gulf states, and the data model does not settle what may be kept, for how long or where; that is agreed country by country and workflow by workflow.
  • The mappings are incomplete. OCEL 2.0 does not model record time, writer or approver, and PROV-DM has no term for cost or reason; both travel as attributes that standard tools may ignore.
  • Scale is untested. We have not measured the record at a large distributor's volume, or how quickly agents can query it.

One development would change the conclusion: if an open standard for object-centric event logs added record time and per-line provenance, most of the reason for a separate model would go, and we would adopt that standard as the record's native form.

12Conclusion

The systems a Gulf company already runs record what was keyed into them. Many decisions that move its goods are taken elsewhere: on a call, in a WhatsApp group, on a delivery note signed on a tailgate. An agent that reads only the ERP acts on part of the operation, and one whose writes cannot be traced cannot be trusted with more.

The operating record is our answer: one line per event, eleven fields in two scripts, two times, and a trace from every line to the message, call, document or person it came from and the person who approved it. Little in it is new; event sourcing, object-centric event logs, W3C PROV and bitemporal databases supplied nearly every part. What we add is the combination, written by agents and people as the work happens, kept beside the ERP, and read by the next agent before it acts.

References

  1. [1]van der Aalst, W., Adriansyah, A., Alves de Medeiros, A. K., et al. (2012). Process Mining Manifesto. BPM 2011 Workshops, Part I, Lecture Notes in Business Information Processing 99, pp. 169-194, Springer.
  2. [2]Kimball Group (n.d.). Transaction Fact Tables. Kimball Dimensional Modeling Techniques, kimballgroup.com. Accessed 14 October 2026.
  3. [3]Kimball Group (n.d.). Type 1: Overwrite. Kimball Dimensional Modeling Techniques, kimballgroup.com. Accessed 14 October 2026.
  4. [4]Alter, S. (2014). Theory of Workarounds. Communications of the Association for Information Systems 34, Article 55.
  5. [5]Fowler, M. (2005). Event Sourcing. martinfowler.com, 12 December 2005. Accessed 14 October 2026.
  6. [6]Helland, P. (2015). Immutability Changes Everything. Proceedings of CIDR 2015, the 7th Biennial Conference on Innovative Data Systems Research.
  7. [7]Institute of Electrical and Electronics Engineers (2023). IEEE Standard for eXtensible Event Stream (XES) for Achieving Interoperability in Event Logs and Event Streams (IEEE 1849-2023). IEEE Standards Association, published 8 September 2023, superseding IEEE 1849-2016. Accessed 14 October 2026.
  8. [8]van der Aalst, W. M. P. (2019). Object-Centric Process Mining: Dealing with Divergence and Convergence in Event Data. Software Engineering and Formal Methods (SEFM 2019), Springer.
  9. [9]Berti, A., Koren, I., Adams, J. N., et al. (2024). OCEL (Object-Centric Event Log) 2.0 Specification. arXiv:2403.01975.
  10. [10]OCEL 2.0 (Chair of Process and Data Science, RWTH Aachen University) (2026). OCEL 2.0: Formats. ocel-standard.org. Accessed 14 October 2026.
  11. [11]Groth, P. and Moreau, L. (eds.) (2013). PROV-Overview: An Overview of the PROV Family of Documents (W3C Working Group Note). W3C Working Group Note, 30 April 2013.
  12. [12]Moreau, L. and Missier, P. (eds.) (2013). PROV-DM: The PROV Data Model (W3C Recommendation). W3C Recommendation, 30 April 2013.
  13. [13]Hogan, A., Blomqvist, E., Cochez, M., et al. (2021). Knowledge Graphs. ACM Computing Surveys 54(4), Article 71 (arXiv:2003.02320).
  14. [14]Snodgrass, R. and Ahn, I. (1985). A Taxonomy of Time in Databases. Proceedings of ACM SIGMOD 1985, pp. 236-246.
  15. [15]Kulkarni, K. and Michels, J.-E. (2012). Temporal Features in SQL:2011. ACM SIGMOD Record 41(3), pp. 34-43.
  16. [16]Fowler, M. (2021). Bitemporal History. martinfowler.com, 7 April 2021. Accessed 14 October 2026.
  17. [17]Park, J. S., O'Brien, J. C., Cai, C. J., et al. (2023). Generative Agents: Interactive Simulacra of Human Behavior. arXiv:2304.03442.
  18. [18]Liu, N. F., Lin, K., Hewitt, J., et al. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics 12, pp. 157-173.
  19. [19]Goregaokar, M. and Leroy, R. (eds.) (2026). Unicode Standard Annex #9: Unicode Bidirectional Algorithm. Unicode 18.0.0, revision 52, Unicode Consortium. Accessed 14 October 2026.
  20. [20]Klyne, G. and Newman, C. (2002). Date and Time on the Internet: Timestamps. RFC 3339, Internet Engineering Task Force.
  21. [21]Meta (n.d.). Messages webhook reference. WhatsApp Cloud API documentation, Meta for Developers. Accessed 14 October 2026.
  22. [22]Bray, T. (ed.) (2017). The JavaScript Object Notation (JSON) Data Interchange Format. RFC 8259, Internet Engineering Task Force.

Cite this paper

Qantara Research (2026). The operating record: a data model for how a company runs. Qantara, 14 October 2026. https://qantara.systems/insights/operating-record

@techreport{qantara2026operatingrecord,
  title       = {The operating record: a data model for how a company runs},
  author      = {Qantara Research},
  institution = {Qantara},
  year        = {2026},
  month       = {oct},
  url         = {https://qantara.systems/insights/operating-record}
}

Disclosure

Every source is cited by number and was opened on or before 14 October 2026; dated web pages carry the date they were read. The comparison in figure 2, the field definitions and their mappings to OCEL 2.0 and PROV-DM, and the design of the operating record are Qantara's. The Sunday order, the Monday discount, the Tuesday correction, the record line in JSON and the table of three lines are illustrative examples written by us: names, identifiers, quantities and amounts are invented. Export in standard formats is described as a design goal, not a commitment.

Read next

Tell us where to start.

Write to our team about the work you would fix first, or about anything in the research.

Talk to the teamAll insights