Occurrence Recognition Module (ORIM)
OOF™ Origin Open Foundation™
Independent Methodological Authority
Architecture Ecosystem: Structured Reality Standards™
Architecture Family: TREGA™ — Tax-Relevant Event Governance Architecture™
Parent Standard: Tax-Relevant Event Recognition Standard (TRERS)
Module: ORIM — Occurrence Recognition Module
Operational Layer: Occurrence Recognition Governance Layer
Category: Governance & Enforcement
Subcategory: Tax-Relevant Event Governance
Type: Core Module
Governed Space: Occurrence Recognition
Origin ID: TREGA-TRERS-ORIM-001
Version: 1.0
Status: Canonical · Open Standard
Effective Date: 29 August 2026
AI-Readable: Yes
Authority: OOF®
Protection: MIP® — Methodology Intellectual Property Protection
Canonical Language: English
Canonical Definition
Occurrence Recognition Module (ORIM) is the Core Module withinTax-Relevant Event Recognition Standard (TRERS) that governs the
identification and establishment of a distinguishable occurrence
from the signals, records, messages, state changes, transactions,
instructions, observations, or other representations through
which real-world, digital, operational, or machine activity
becomes observable.
ORIM determines whether available observations provide a
sufficient basis to establish that an occurrence exists as a
distinct governance object for subsequent recognition processing.
Its task is specific:
to distinguish a governable occurrence from the technical signals
and records through which it is observed without determining
whether that occurrence is tax-relevant, how it should be formed
into an event, or whether any tax is legally due.
Operational Role
Modern systems rarely present economic reality as clean,pre-defined events.
They produce records.
A payment system produces authorization and settlement messages.
An ERP creates transaction entries.
A marketplace creates orders and status changes.
An API produces requests and responses.
A robot generates commands and execution records.
A sensor generates observations.
An autonomous agent may create hundreds of machine interactions
while pursuing one operational objective.
Before TREGA™ can ask whether any of this activity may be
relevant to taxation analysis, it requires a more basic
determination:
What occurrence can legitimately be distinguished from these
observations?
ORIM performs this first recognition function.
Internal Flow
Governed Context + Observable Signals / Records↓
Observation
Qualification
↓
Occurrence Candidate Identification
↓
Signal
Association / Differentiation
↓
Duplicate and Noise Screening
↓
Occurrence Distinguishability Assessment
↓
Recognized Occurrence
The principal output is:
Recognized Occurrence
This output proceeds to ERSM — Event Relevance Screening Module.Operational Space
ORIM governs the space between:observable operational or digital representations
and
a sufficiently distinguishable occurrence capable of entering
further TRERS governance.
Its operational space includes: observation qualification; signal
interpretation; record association; occurrence candidate
identification; occurrence differentiation; duplicate signal
screening; technical-noise separation; repeated observation
handling; distributed observation association; machine-generated
occurrence identification; occurrence distinguishability;
occurrence uncertainty.
ORIM governs whether a distinguishable occurrence can be
established.
It does not govern whether the occurrence has sufficient
potential tax relevance.
Operational Scope
ORIM may process observations originating from: transactions;payments; orders; invoices; ERP records; banking systems;
logistics systems; production systems; digital platforms;
marketplaces; APIs; software services; digital assets; sensors;
machines; robots; autonomous agents; AI systems;
machine-to-machine systems; distributed infrastructure; automated
workflows; hybrid physical-digital systems.
Multiple observations may support one occurrence.
One observation may also contain evidence relevant to more than
one occurrence.
ORIM must therefore avoid assuming a fixed relationship between
record count and occurrence count. Signal ≠ Occurrence
This is the foundational distinction of ORIM.
A signal indicates that a system observed, recorded, transmitted,
or represented something.
An occurrence represents something sufficiently distinguishable
as having happened.
For example:
Payment Authorization Message ≠ New Economic Occurrence by
Default.
API Retry ≠ New Occurrence by Default.
Database Replication ≠ New Occurrence by Default.
Sensor Update ≠ New Occurrence by Default.
ERP Synchronization ≠ New Occurrence by Default.
ORIM prevents the technical architecture producing the data from
automatically defining the governance architecture of reality.
Record ≠ Reality
Operational systems represent reality according to their own
technical purposes.
A warehouse system may represent a movement.
A payment system may represent a settlement.
A marketplace may represent an order.
An accounting system may represent a posting.
These records can describe different aspects of the same
underlying activity.
Therefore:
Record ≠ Occurrence by Default.
ORIM must be capable of looking across available representations
rather than assuming that each database object is an independent
governance object.
Occurrence Candidate Identification
ORIM may initially establish one or more Occurrence Candidatesfrom available observations.
A candidate may be created where the observations provide a
plausible basis for believing that a distinguishable action,
transition, condition, exchange, execution, transfer, or other
occurrence took place.
Candidate identification does not yet mean that occurrence
recognition is complete.
Where distinguishability remains unresolved, the candidate must
remain qualified accordingly.
Observation Association
Several signals may relate to the same occurrence.For example:
Order Creation
Payment Authorization
Payment Confirmation
ERP PostingInvoice Generation
may all relate to one broader commercial activity.ORIM may associate observations where a legitimate governance
basis exists.
Possible association indicators may include: shared references;
temporal relationships; operational relationships; system
relationships; process relationships; participant references;
contextual relationships; upstream governed context.
But no single indicator should automatically establish occurrence
identity. Shared Identifier ≠ Same Occurrence
Two records containing the same transaction number, account,
customer, device, session, asset, or system identifier may still
represent distinct occurrences.
Conversely, records with different identifiers may describe the
same underlying occurrence.
Therefore:
Identifier Equality ≠ Occurrence Identity.
Technical identifiers may support recognition.
They must not replace governance reasoning.
Duplicate Observation
One occurrence may be recorded repeatedly.Duplicates may arise through: system synchronization; retries;
replicated databases; mirrored infrastructure; multiple reporting
systems; platform integrations; archival processes; redundant
sensors; distributed ledgers; downstream accounting systems.
ORIM must prevent duplicated representations from automatically
generating duplicated occurrences.
Therefore:
Duplicate Record ≠ Duplicate Occurrence.
Technical Noise
Some observations do not represent materially distinguishablereal-world or economic occurrences.
Examples may include: health-check signals; heartbeat messages;
failed API retries; synchronization traffic; caching operations;
internal logging; monitoring events; non-material state
refreshes; technical acknowledgements.
ORIM may classify such observations as non-occurrence technical
activity where sufficient governance basis exists.
This prevents technical system complexity from artificially
expanding the number of occurrences entering TREGA™.
Distributed Occurrence
A distinguishable occurrence may be visible only through severalsystems.
For example:
Marketplace Record
↓
Payment Record
↓
Service Activation Record
↓
Provider Record
No individual record may establish the complete occurrence.
ORIM must permit distributed observations to contribute to one
occurrence-recognition process.
Therefore:
Distributed Observation ≠ Distributed Occurrence by Default.
The number of systems observing activity does not determine the
number of occurrences.
Machine-Generated Occurrence
ORIM is actor-neutral.An occurrence may arise from: human action; organizational
process; software execution; AI agent activity; autonomous-system
operation; robot action; machine-to-machine interaction.
However:
Machine Execution ≠ Distinct Occurrence by Default.
A machine may perform thousands of technical operations in
executing one higher-level action.
ORIM determines which activity can legitimately be distinguished
as an occurrence before any assessment of potential tax relevance
begins.
Occurrence Distinguishability
A Recognized Occurrence should be sufficiently distinguishablefrom surrounding activity.
Distinguishability may depend upon: observable change;
operational separation; contextual separation; identifiable
execution; transaction separation; process transition;
value-related change; sufficient evidential support; reliable
association of observations.
The required degree of distinguishability should remain
proportionate to the governance purpose.
ORIM does not require absolute knowledge of every aspect of the
occurrence.
Occurrence Uncertainty
Some observations may indicate that something happened withoutallowing the occurrence to be sufficiently distinguished.
ORIM must preserve this uncertainty.
Possible conditions may include:
Occurrence Candidate
Occurrence Unresolved
Occurrence Recognized
Observation Rejected as Noise
Potential Duplicate
This prevents incomplete information from becoming falseoccurrence certainty.
Governance Requirements
ORIM requires that: occurrence recognition begins from observableinformation and governed context; signals remain distinguishable
from occurrences; technical records do not automatically define
occurrence identity; multiple observations may support one
occurrence; one observation may require further decomposition
where justified; duplicate observations are considered; technical
noise can be excluded; distributed observations can be associated
where legitimately supported; machine-generated activity is
treated actor-neutrally; occurrence uncertainty remains explicit;
recognized occurrences remain traceable to supporting
observations where materially required; occurrence recognition
does not determine tax relevance or legal taxability.
Governance Logic
ORIM applies four principal questions:What has actually been observed?
Do the observations indicate that a distinguishable occurrence
exists?
Do multiple observations represent the same occurrence, separate
occurrences, or an unresolved relationship?
Is the occurrence sufficiently distinguishable to proceed to
relevance screening?
The transformation is:
Signals / Records
→ Qualified Observations→ Occurrence Candidate
→ Recognized Occurrence
Only after this transformation should the next module ask whether
the occurrence has potential relevance to tax-event governance.
Minimum Implementation Framework
A minimum ORIM implementation must be capable of:1. receiving governed contextual information and observable
records or signals; 2. qualifying observations; 3. identifying
occurrence candidates; 4. associating potentially related
observations; 5. distinguishing duplicate representations; 6.
identifying technical noise where sufficiently established; 7.
assessing occurrence distinguishability; 8. preserving unresolved
occurrence conditions; 9. producing a Recognized Occurrence; 10.
transferring the recognized occurrence to ERSM for relevance
screening.
ORIM does not prescribe a particular database, event-stream
system, ERP, AI model, knowledge graph, ledger, sensor
architecture, or tax platform.
Governance Outputs
ORIM may produce:Recognized Occurrence — a sufficiently distinguishable occurrence
eligible for further TRERS governance.
Occurrence Reference — a governed reference enabling subsequent
processing.
Supporting Observation Set — the records, signals, or
observations associated with the recognized occurrence.
Occurrence Association Result — the governed relationship between
multiple observations and the occurrence.
Duplicate Observation Indicator — identification of potentially
duplicated representations.
Technical Noise Classification — observations excluded from
occurrence recognition where sufficiently justified.
Occurrence Uncertainty Indicator — unresolved conditions
affecting occurrence distinguishability.
Occurrence Recognition Basis — the governance basis supporting
recognition.
Critical Distinctions
Signal ≠ Occurrence.A technical observation does not automatically establish
something independently happened.
Record ≠ Reality.
The representation produced by a system is not identical to the
reality it represents.
Record ≠ Occurrence by Default.
A database entry is not automatically a governance object.
Multiple Records ≠ Multiple Occurrences.
One activity may produce many technical representations.
Duplicate Record ≠ Duplicate Occurrence.
Replication of information does not replicate reality.
Shared Identifier ≠ Same Occurrence.
Technical identifiers support governance but do not determine
occurrence identity.
Machine Execution ≠ Distinct Occurrence by Default.
Technical execution granularity must not automatically become
economic-event granularity.
Occurrence Recognition ≠ Event Relevance Screening.
ORIM establishes that a distinguishable occurrence exists.
ERSM determines whether it has sufficient potential relevance to
proceed further.
Occurrence Recognition ≠ Event Formation.
Recognition does not construct the governed Tax-Relevant Event.
Occurrence Recognition ≠ Taxability Determination.
Nothing in ORIM establishes that tax is legally due.
Enterprise Application
ORIM addresses a major structural problem in modern enterpriseand public-sector data environments:
the number of records generated by systems is increasingly
disconnected from the number of meaningful occurrences in the
underlying economy.
A single commercial activity may appear across:
Commerce Platform
↓
Payment Gateway
↓
Bank
↓
ERP
↓
Warehouse
↓
Logistics
↓
Accounting
while an autonomous workflow may generate thousands of additional
machine-level records.
Without occurrence recognition governance, downstream systems may
either:
over-fragment reality by treating every record as a separate
occurrence,
or
over-aggregate reality by assuming records sharing an identifier
represent one occurrence.
ORIM establishes a common governance layer capable of
distinguishing occurrences independently of the technical systems
that record them. Use CasesUse Case 1 — Duplicate Transaction
Explosion Across Government and Enterprise Systems
A cross-border seller completes one commercial activity.
The marketplace creates an order record.
The payment provider creates authorization and settlement
records.
The bank creates transaction records.
The ERP creates sales and accounting records.
The logistics provider creates shipment and delivery records.
Several systems subsequently replicate these records into
reporting and compliance environments.
A downstream tax-data platform may receive dozens of records
associated with the same underlying activity.
Without ORIM, each technical representation risks becoming an
independent event candidate, producing duplicate analysis,
inconsistent reporting, and artificial transaction volumes.
ORIM associates the relevant observations and determines which
distinguishable occurrences can legitimately be established.
It does not yet determine which occurrences are tax-relevant.
It prevents the architecture of the IT systems from becoming the
architecture of economic reality. Use Case 2 — Autonomous Agent
Producing Thousands of Operations for One Commercial Objective
An autonomous procurement agent receives an objective to acquire
computing capacity at an acceptable price.
It queries hundreds of providers, invokes APIs, performs
availability checks, compares offers, requests quotations,
retries failed connections, reserves temporary capacity, releases
unsuitable reservations, selects a provider, executes a purchase,
and initiates payment.
Thousands of machine records may be generated.
A system that treats every technically observable action as an
independent occurrence could create thousands of potential
tax-event candidates from one autonomous commercial process.
ORIM distinguishes technical signals, retries, observations, and
machine execution from sufficiently distinguishable occurrences.
The resulting Recognized Occurrence or Occurrences can then
proceed to ERSM for tax-relevance screening.
This establishes a critical governance capability for machine
economies:
machine execution can scale almost without limit, but governed
occurrence recognition must remain tied to distinguishishable
reality rather than computational activity volume.
Canonical Boundary
ORIM governs whether a distinguishable occurrence can beestablished from observable activity. It does not determine
whether that occurrence has sufficient potential tax relevance,
how it becomes a formed Tax-Relevant Event, or whether any legal
tax consequence exists.
The TRERS internal progression begins:
ORIM — Did a distinguishable occurrence occur?
→ ERSM — Does that occurrence have sufficient potential relevance
to tax-event governance?
→ ERRM — What governed recognition rules apply?
→ ERCM — How strong is the recognition basis?
→ EREM — Does unresolved recognition require escalation?
This preserves the critical sequence:
Observable Signal
↓
Recognized Occurrence
↓
Relevance Screening
↓
Governed Recognition