Time, Events and History

Status: settled semantic contract, 2026-09-11. Physical storage, event dispatch and reconstruction are implementation mechanisms, not claims of working functionality.

Owns: Event meaning and responsibility, current/historical state, temporal context, version/event/audit distinctions, causal explanation and history decision boundaries. Core object model and authority defines the cross-cutting identity, derived-state and non-destructive history invariants. Workflows and automation owns triggers, schedules, jobs and execution semantics; identity and governance owns audit obligations and access.

Lineage: source 02 sections 1, 5, 6, 8, 9 and 11; source 01's institutional memory and versionable ownership; source 03's enquiry, knowledge and improvement workflows; corresponding source 00 sections. See the source ledger.

Temporal Foundations

Business operation needs both current information and enough historical context to explain what happened. A current customer assignment, price, policy or workflow definition does not necessarily describe the context of an earlier action.

History applies across the universal object model: business objects, relationships, type definitions, configuration, workflows and nodes, permissions, knowledge, content, integration definitions, policies, goals and decisions. It is not a marketing-only activity feed or an AI conversation archive.

Historical identity must remain distinguishable from current presentation. Renaming a person, changing a policy or reconfiguring a view must not silently rewrite the explanation for previously recorded business work.

Required evidence for a consequential operation must remain historically identifiable and explainable. This does not claim that an implementation can already reconstruct every past state or that every raw input must be retained forever.

Event

An Event is an addressable representation of a business occurrence or change that happened, expressed through the universal id + type + value model. Its typed value and/or relationships carry the payload, timestamps, provenance and related objects needed to interpret that occurrence.

An event is not an instruction, prediction, schedule or proof of every downstream side effect. A planned service visit is not a completed occurrence, and a recorded request to send email is not proof of delivery.

The source event examples are customer.created, enquiry.received, quote.accepted, order.created, payment.received, task.completed, document.uploaded and knowledge.updated. These names illustrate business meaning, not an approved event taxonomy or identifier encoding.

An event can be relevant to more than one responsibility. For example, an enquiry occurrence can inform a workflow, operational metrics and contextual history without each capability inventing its own customer or event foundation.

An imported event represents the occurrence as reported by its source. Record source/provenance so a remote assertion is not silently treated as independently verified platform fact.

Events, Versions, Activity, Audit and Notifications

| Concept | What it represents | What it does not prove | |---|---|---| | Current state | The state presented as current under the selected lifecycle and temporal rules. | Everything previously true or the reason for each transition. | | Object version | An identifiable revision or state of an object/configuration relevant to change and historical reference. | That a business event occurred or that an action was authorized. | | Event | A contextualized occurrence or change. | A complete state snapshot, an execution command or guaranteed delivery to all consumers. | | Activity entry | A user-facing description or projection of relevant activity. | Complete audit coverage or authoritative execution evidence merely because it is displayed. | | Audit evidence | Accountability context about access, decisions or operations required by governance. | Every business fact, or permission for every user to inspect the evidence. | | Notification | A communication intended to inform a recipient about something. | That its subject action succeeded, or that the recipient received/read it. |

These meanings can be linked, but should not be collapsed into one undifferentiated log. A version can be associated with an event and audit evidence; a notification can point to them while retaining its own delivery history under communication and integrations.

Workflow definition, Workflow execution, Trigger, Schedule, Job, Automation, Action and Outcome are defined by workflows and automation. Their distinction from an Event must survive both storage choices and UI presentation.

Event Responsibility

The Event responsibility makes relevant business occurrences available with coherent identity and context so other responsibilities can react without hard-coded cross-capability coupling. It is not a mandate for a broker, separate service or event-sourced database.

| Contract aspect | Required concern | |---|---| | Inputs | A supported occurrence/change, its type and payload, subject references, source/provenance, actor or execution context and relevant time information. | | Validation | Check typed payload and reference validity, authorized source/context and selected publication rules before treating an event as authoritative platform data. | | Recording | Represent the occurrence as an addressable object with enough context for explanation and authorized consumption. | | Consumption | Expose relevant occurrences to permitted workflows, analytics and other responsibilities without granting wider access to the subjects. | | Outcomes | Make the accepted occurrence or failure identifiable; distinguish acceptance of an event from processing success in each consumer. | | Failures | Surface malformed data, inaccessible subjects, unauthorized publication, ambiguous source identity and processing failures according to the approved contracts. |

Duplicate transport delivery is not a new semantic operation. Consumers follow the settled Command and retry contract; the word "event" does not promise universal exactly-once external effects. Required event/history recording commits coherently with its state change. Dispatch to consumers is separate from that durable record and retains explicit processing outcomes.

A business event is not itself an authority token. A workflow reacting to it must still validate and authorize actions under governance. Retries and recovery must not silently turn a received event into repeated externally visible actions; execution controls belong to the workflow and integration owners.

Recorded, Effective and Occurrence Time

Recorded time identifies when information was recorded by the platform. Effective time identifies when a fact, relationship or definition is intended to apply to the business. Occurrence time identifies when an event is reported to have happened; it can differ from ingestion/recording time.

Temporal meaning, correction and reconstruction boundary

The governing distinction is:

recorded_at != occurred_at != business-effective time

These meanings must not be collapsed into a universal effective_at field. Business-effective time is domain-specific; an effective interval is used only where the relevant domain contract defines one. A late-arriving fact retains its platform recording time separately from any known occurrence or effective time, and an unknown effective time remains unknown.

Retained object revisions reconstruct retained recorded history. Where the existing evidence model records them, consequential operations retain the exact definitions, policies, workflows, Operations and their revisions, actors, authority context and inputs used. Corrections are attributable new information and must not silently overwrite historical assertions. Supersession changes current standing or operative use; it is not deletion.

Future capabilities must declare the temporal and reconstruction guarantee they require. The platform does not promise universal bitemporal storage, event sourcing, automatic replay or complete reconstruction of every derived historical state. Replay, recalculation and action execution remain distinct concerns under the applicable workflow and implementation contracts.

For example, a service inspection completed on Monday may be entered on Tuesday. The completion occurrence and the time the platform learned of it answer different questions. A policy uploaded today may state that it takes effect next week.

The model makes those distinctions where relevant instead of using an unexplained updated_at value for every meaning. Concrete precision, timezone encoding and interval representation belong to implementation architecture, not a new temporal primitive.

Late information, backdated changes and corrections can change what the platform knows about an earlier period. "What applied then?" and "What did we know then?" are distinct questions; whether both are reconstructable for every object is a decision, not an implied bitemporal implementation.

Recurrence, daylight-saving changes, missed schedules and scheduling timezones belong to workflows and automation. This document supplies temporal meaning rather than selecting a scheduler.

Versions and Historical References

Initialization retains the exact applicable Definition and Workflow Definition revisions in its Workflow Execution evidence. Constituent creation or update produces ordinary object revisions and governed Command/Attempt/Outcome/Event/Provenance evidence. Repeating an initialization requirement does not erase an earlier Attempt or rewrite the prior definition binding.

Versions identify the relevant form of mutable information: a policy, workflow definition, type, relationship, content item or configuration can change while its business identity remains meaningful.

Historical references distinguish what was consulted or applied from what is current. Actions record relevant workflow definition, Policy, input and approval versions. Current-state checks before commit do not rewrite these references; a changed dependency requires an explicit re-evaluation under the execution contract.

Assignment history must preserve the distinction between a retained reference and a resolved value. A retained reference remains dynamically dependent on its authoritative source relationship. A resolved assignment evaluates that source at assignment time and retains the resulting value instead of the source relationship. Where supported by the existing provenance model, the resolved value retains causal evidence for the source object, event or execution, actor/authority and relevant Definition or revision. That evidence explains origin without making the current value dynamically dependent on the source, and either form may later be replaced through normal governed Data, Workflow or Logic mutation.

Changing a definition must not be presented as if a prior action used that new definition. Conversely, merely keeping version numbers does not guarantee that historical dependencies, referenced knowledge or permission context remain available.

Ordinary removal of a current value is not destruction of the object. The object identity, applicable revisions and required provenance/history remain available to authorized readers unless a separate governed retirement or destruction operation applies. Dependent objects and relationships are not silently cascade-deleted merely because current data was removed.

Derived State is recalculated from the actual object condition and applicable definitions, constituents, values and relationships. When that condition changes, the platform records an addressable transition occurrence where required. A causal explanation may therefore connect the underlying value or constituent change to its Command, Attempt, Outcome, revision, derived-state transition, Event, workflow response and later effects. Correlation alone is not enough to establish that chain.

The history design must consider changes to identities and authority as well as business values. Explain who or what acted at the time without assuming their current role or membership describes their former authority.

This does not choose immutable versions, snapshots, full copies, change deltas or event sourcing. Implementation architecture must demonstrate how its approved mechanism meets the required explanatory guarantees.

Causality, Correlation and Provenance

Causality links something to an identified cause, such as a workflow action taken because a particular enquiry event satisfied a condition. Correlation groups related activity, such as the enquiry, opportunity, task and confirmation belonging to one business process; correlation alone does not prove causation.

Provenance identifies origin and derivation: the submitting form, authenticated actor, imported source, workflow execution or AI proposal that supplied information. These distinctions are represented as typed values or relationships within the shared model, not a separate provenance foundation.

An explanation of a consequential action should be able to identify, as applicable:

• The subject objects and relevant event, request or scheduled context.
• The acting User and any authorized delegation or automation context. Automation acts under authority delegated by a User; the technical executor is execution provenance only (see [delegated authority for automation](identity-and-governance.md#delegated-authority-for-automation)).
• The conditions, policy/constraint and workflow/configuration references used.
• The approval or recorded decision, distinct from the proposal it considered.
• The attempted action, observed result, failure or externally reported outcome.
• Relevant recorded/effective/occurrence time and uncertainty about imported information.

Required audit coverage is owned by identity and governance. Storage and retrieval of this context must themselves respect permissions; an explanation must not reveal hidden knowledge, credentials or another tenant's data.

Historical Scenarios

Pricing Policy Changes

A business uploads a pricing-policy PDF, represented as a Document with associated Knowledge and Policy context. Source and provenance identify where the interpretation came from; the policy's effective date need not equal upload time.

A quote or workflow decision refers to the policy context actually used. When a replacement arrives, the former knowledge/policy must remain historically identifiable to the agreed depth, rather than the old decision appearing to rely on today's document.

Knowledge owns source and authority distinctions, semantics owns policy meaning and governance owns approval. This example does not declare that extraction alone can install an executable policy or that documents must be kept forever.

Enquiry and Improvement History

For the enquiry demonstration, distinguish enquiry.received, customer matching, the workflow run, the assigned task, the confirmation attempt and the confirmed delivery result. Their links explain a business process without pretending they are one transaction.

For an improvement, connect the observed repeated work, proposal, review decision, configuration change and measured result. A rejected suggestion remains a different outcome from a failed approved change; neither should be recorded as a successful optimisation.

Human operation and deterministic observation must preserve these explanations without AI. Optional AI summaries are derived descriptions with provenance, not substitutes for the underlying historical evidence.

Correction, Retention and Replay

Correction distinguishes inaccurate information, late information and a genuinely new business state. Challenge, rejection, resolution or supersession preserves the original Assertion and its provenance rather than silently overwriting it. A reversal or compensating Action is another occurrence, not erasure of the original effect. Retirement preserves authorised historical resolution where retention permits.

Retention must account for business need, privacy, security and applicable obligations, but this direction specifies no retention law, universal duration or requirement to keep every item indefinitely. Requirements must be established for the relevant data and operating context.

Replay has multiple meanings: reconstructing a view, recalculating a metric or executing an action again are not equivalent. Reprocessing an event must not be assumed safe for email, publication, payments or other external effects.

Event sourcing, an immutable event store, bitemporal persistence, complete reconstruction and automatic replay are not selected. An implementation may use approved history mechanisms, but must not advertise guarantees it cannot demonstrate.

Durable History and Transition Occurrences

Required state change and required historical record commit coherently across the authoritative durable commit boundary. A successful state mutation without its required history is not a successful commit. Before this boundary, an attempt can fail, be rejected or become stale; afterwards, the committed occurrence and effects remain historical facts. This does not make every assertion within an occurrence independently true.

Each lifecycle change is an addressable state-transition occurrence, identifying its subject, before/after State definitions, relevant versions, actor, authority, Command/Action context, cause and time. Those State references preserve the identity and definition/version context used at the time, not only primitive labels. Objects and types owns State identity and type declarations own allowed transitions; this document owns their occurrence/history meaning.

Workflow migration and re-entry preserve earlier execution bindings, step visits, Attempts and outcomes. A later binding or continuation must not replace the historical version under which an earlier occurrence happened. Workflows and automation owns those governed operations; their history follows the same coherent recording and non-destructive rules.

Commands, Action Executions and Attempts retain separate identities and links. Failed Attempts and unknown outcomes remain inspectable; later reconciliation adds evidence and a determination instead of deleting the attempt. If durable recording is unavailable, the runtime cannot claim successful audited admission or perform an unrecorded consequential external operation.

Required local commit evidence is recorded within the commit, not as a best-effort task afterwards. A remote result learned later is recorded subsequently with its own evidence. Local atomicity never proves that a remote system committed successfully.

Materialised determinations have addressable lifecycle changes under AI. Their invalidation or supersession preserves the earlier determination and committed Actions that relied on it. Active dependent work is re-evaluated; historical reliance is not rewritten.

Conformance and Implementation

Conforming: a past quote can identify its policy context; a late service entry distinguishes occurrence from recording; an event consumer reports failure without rewriting the occurrence as nonexistent; a notification exposes only authorized context.

Nonconforming: a current policy silently replaces historical reasoning, an activity feed is asserted to prove complete audit coverage, an emitted event is treated as guaranteed action success, or replay automatically resends external communications without governed execution controls.

The settled decisions govern these requirements. Implementation architecture specifies retained revisions, transaction writes and recovery; security and operations specifies access and retention controls. Development requires rollback-on-history-failure, addressable transitions, retained failed attempts and historical assertion tests. No history runtime is claimed as built.