Event Formation Root Module (EFRM)
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 Formation Standard (TREFS)
Module: EFRM — Event Formation Root Module
Operational Layer: Event Formation Root Governance Layer
Category: Governance & Enforcement
Subcategory: Tax-Relevant Event Governance
Type: Core Module
Governed Space: Event Formation Root Association
Origin ID: TREGA-TREFS-EFRM-004
Version: 1.0
Status: Canonical · Open Standard
Effective Date: 30 August 2026
AI-Readable: Yes
Authority: OOF®
Protection: MIP® — Methodology Intellectual Property Protection
Canonical Language: English
Canonical Definition
Event Formation Root Module (EFRM) governs how the operationalroot association of a developing Event Formation is identified,
differentiated, qualified, related, and preserved so that the
formation can be anchored to the materially relevant operational
basis from which its structure originates or becomes meaningfully
organized.
EFRM establishes the governed relationship between a formed event
structure and the operational occurrence, condition, transition,
action, interaction, or state change that provides the most
relevant structural anchor for understanding how that formation
came into being.
Its task is specific:
to establish the governed operational root association of Event
Formation without converting that root into identity origin,
provenance, legal causality, legal tax point, Event Boundary, or
jurisdiction-specific tax determination.
Operational Role
EFCM establishes:which elements qualify as Event Formation Components.
EFAM establishes:
how those components are assembled into a coherent formation
structure.
EFDM establishes:
what that formation materially depends upon.
EFRM then determines:
what operational basis most appropriately anchors the formation
as its Event Formation Root.
This distinction is necessary because a formation may contain
multiple components and depend on multiple prior conditions while
still requiring a coherent operational anchor.
For example:
a payment formation may be rooted in execution of a transfer
instruction.
A service formation may be rooted in commencement or activation
of the governed service interaction.
A production formation may be rooted in a materially relevant
production initiation.
An autonomous transaction may be rooted in an autonomous
execution action.
A machine-to-machine formation may be rooted in a governed
machine interaction or operational state transition.
The Event Formation Root provides structural orientation.
It does not determine legal origin, ownership, identity
provenance, responsibility, or taxation.
Therefore:
Event Formation Root ≠ Identity Origin.
Event Formation Root ≠ Legal Tax Point.
Internal Flow
Governed Event Formation Assembly + Governed Event FormationDependency Structure
↓
Root Candidate Identification
↓
Operational Root Relevance Assessment
↓
Root Candidate
Differentiation
↓
Root Qualification / Exclusion
↓
Root
Association Establishment
↓
Root Conflict / Uncertainty Handling
↓
Governed Event Formation Root Association
The principal output is:
Governed Event Formation Root Association
This output proceeds to:EFIM — Event Formation Integrity Module
Operational Space
EFRM governs the space between:an assembled Event Formation with governed material dependencies
and
an Event Formation whose operational root association is
sufficiently established for Formation Integrity governance.
Its operational space includes: root candidate identification;
operational root relevance; root differentiation; root
qualification; root exclusion; direct root association; indirect
root association; composite root association; distributed root
association; machine-generated roots; autonomous roots; root
ambiguity; root conflict; root uncertainty; root traceability;
root reconsideration.
EFRM governs the operational anchor of Event Formation.
It does not determine who originally created an identity, who
owns an asset, who possesses authority, who is responsible, where
legal causation begins, when tax legally arises, or what belongs
inside the final Event Boundary.
Operational Scope
EFRM may govern Event Formation Roots associated with: commercialtransactions; payments; financial operations; transfers;
production; supply chains; fulfilment; logistics; service
delivery; digital services; subscriptions; platforms;
marketplaces; banking systems; enterprise systems; APIs; software
interactions; digital assets; infrastructure operations; AI
agents; autonomous systems; robots; machine-to-machine
transactions; automated marketplaces; distributed systems; hybrid
physical-digital environments; future machine economies.
An Event Formation Root may arise from human, organizational,
transactional, digital, operational, machine-generated, or
autonomous activity.
EFRM remains actor-neutral and technology-neutral.
Event Formation Root Principle
Complex formations frequently contain many plausible startingpoints.
The first technical record is not necessarily the operational
root.
The earliest timestamp is not necessarily the operational root.
The first participant action is not necessarily the operational
root.
The oldest dependency is not necessarily the operational root.
The Event Formation Root must instead represent the operational
basis that materially anchors the formation being governed.
Therefore:
Earliest Record ≠ Event Formation Root by Default.
First Technical Action ≠ Event Formation Root by Default.
Oldest Dependency ≠ Event Formation Root by Default.
Root Candidate
A Root Candidate is an operational occurrence, action,interaction, transition, or state that may provide the materially
relevant structural anchor for Event Formation.
Possible Root Candidates may include: transaction initiation;
execution instruction; service activation; resource commitment;
production initiation; asset transfer initiation; machine
execution; autonomous action; platform interaction; state
transition; governed system trigger; coordinated multi-system
initiation.
Candidate status does not establish the root.
Therefore:
Root Candidate ≠ Qualified Event Formation Root.
Operational Root Relevance
A Root Candidate should be qualified only where it materiallyexplains the structural emergence or organization of the
formation.
Relevant considerations may include whether the candidate:
materially initiates the formation; creates the operational
condition around which components assemble; establishes the
principal structural transition represented by the formation;
provides a coherent anchor for associated components;
distinguishes the formation from surrounding activity; remains
consistent with governed dependencies; can be sufficiently traced
to the recognized occurrence.
Root qualification must not be based solely on technical
convenience. Technical Origin ≠ Operational Root
Digital and enterprise systems often create several technical
origins for the same activity.
A transaction may produce: API requests; database entries;
message-queue events; accounting records; audit logs; settlement
instructions; system notifications.
The earliest technical artifact does not automatically define the
Event Formation Root.
Therefore:
Technical Origin ≠ Operational Root.
EFRM must preserve the distinction between the system artifact
that first records activity and the operational basis that
materially anchors the event formation. Dependency ≠ Root
EFDM may establish several material dependencies supporting the
formation.
EFRM must not automatically select one of those dependencies as
the Event Formation Root.
For example:
an autonomous purchase may depend on prior delegation.
The delegation may be essential.
But the purchase formation may be operationally rooted in the
autonomous execution of the purchase rather than the earlier
delegation.
Therefore:
Formation Dependency ≠ Event Formation
Root by Default. Trigger ≠ Root
A technical or operational trigger may initiate a process withoutconstituting the Event Formation Root.
For example:
a scheduled timer may trigger an autonomous system.
A sensor may trigger a machine workflow.
A notification may trigger an API call.
A price threshold may trigger an algorithm.
The trigger may explain why execution began.
The root must explain what operational basis anchors the
formation itself.
Therefore:
Trigger ≠ Event Formation Root by Default.
Event Root ≠ Identity Origin
EFRM does not determine where an actor, organization, machine,account, asset, agent, or digital identity originated.
Identity origin belongs to the architecture governing identity
and origin.
Within the OOF architecture ecosystem, this space is governed
principally through OBIDENITY® where applicable.
EFRM may consume identity references where necessary.
It does not redefine them.
Therefore:
Event Root ≠ Identity Origin.
Root Association ≠ Provenance Governance.
Event Root ≠ Ownership Origin
The operational root of an event does not determine ownership.A transfer formation may be rooted in execution of a transfer.
That does not determine who legally owned the transferred object
before or after that execution.
Therefore:
Event Formation Root ≠ Ownership Determination. Event Root ≠
Authority Origin
An event may be executed under delegated or inherited authority.
The existence of that authority may be a dependency.
The operational root may nevertheless be the execution itself.
EFRM does not determine where the authority originated or whether
it was legally valid.
Therefore:
Event Formation Root ≠ Authority Origin.
Event Root ≠ Legal Causality
The operational root provides a structural anchor.It does not establish legal causation.
The operational point from which an event formation is organized
may differ from the point considered legally causal under
contract, tort, regulatory, tax, or other law.
Therefore:
Operational Root ≠ Legal Cause. Event
Formation Root ≠ Legal Tax Point
A particularly important TREGA™ boundary concerns taxation.EFRM may determine that a particular operational action or
transition provides the most appropriate root for Event
Formation.
It must not determine that tax legally arises at that point.
Tax legislation may establish a legally relevant tax point using
rules concerning: supply; delivery; invoicing; payment; transfer;
realization; recognition; residence; permanent establishment;
jurisdiction-specific timing rules.
Those determinations remain outside EFRM.
Therefore:
Event Formation Root ≠ Legal Tax Point.
Root ≠ Event Start Time
The Event Formation Root may be associated with a particularoperational moment.
That does not make EFRM the owner of Event Timing.
TRETS later governs Event Timing.
Therefore:
Event Formation Root ≠ Event Start Time Determination.
EFRM may preserve relevant temporal references without
determining the governed Event Start, Completion, Duration, or
Temporal Order. Root ≠ Event Location
An operational root may occur through a particular system,
facility, machine, platform, or geographic environment.
EFRM does not determine governed Event Location.
TRELS owns that space.
Therefore:
Root Association ≠ Event Location Determination.
Single Root Formation
Some formations have one sufficiently clear operational root.For example:
Transfer Execution
↓
Governed Transfer Formation
Where evidence and structure support one materially dominant
operational anchor, EFRM may establish a Single Root Association.
However, a single root should not be imposed merely for
simplicity.
Composite Root Formation
Some event formations may emerge from several operational actionsthat jointly provide the structural basis of the formation.
EFRM must therefore permit Composite Root Association where no
single operational element legitimately represents the formation.
Therefore:
Multiple Root Elements ≠ Multiple Events by Default.
A composite root does not itself determine whether one or
multiple final events exist.
Distributed Root Formation
In distributed systems, no single technical system may containthe complete operational root.
A cross-platform transaction may emerge through coordinated
actions across: marketplace; payment network; service provider;
autonomous agent; infrastructure; distributed ledger; external
API.
EFRM must permit a root to be represented across multiple
operational sources where necessary.
Therefore:
Distributed Root Representation ≠ Multiple Event Roots by
Default.
Machine-Generated Root
A machine-generated formation may possess a legitimateoperational root even where no human initiates the immediate
action.
Possible examples include: automated resource purchase;
machine-triggered replenishment; algorithmic settlement; robotic
service execution; autonomous infrastructure allocation.
Therefore:
Human Initiation Is Not Required for Event Formation Root.
However:
Machine Execution ≠ Independent Event Root by Default.
Material operational relevance remains required.
Autonomous Event Formation Root
Autonomous agents may create formations through independentlyexecuted operational decisions.
EFRM may establish an autonomous execution as the Event Formation
Root where it materially anchors the formation.
This does not establish: autonomous legal personality; taxpayer
status; legal responsibility; ownership; authority; tax
liability.
Therefore:
Autonomous Event Root ≠ Autonomous Legal Responsibility.
Root Conflict
Different systems or evidence sources may identify differentplausible operational roots.
For example:
a marketplace may identify order acceptance as the root.
A payment system may identify payment authorization.
A supplier system may identify service activation.
EFRM must not silently collapse materially different
representations.
Possible states may include:
Root Candidate
Root Qualified
Root Excluded
Composite Root
Root Conflict
Root Unresolved Root Uncertainty
Where the operational root cannot be sufficiently established,EFRM must preserve uncertainty.
A root must not be invented merely because downstream systems
require one.
Therefore:
Required Data Field ≠ Legitimately Established Root.
Where necessary, the formation may remain:
Root Unresolved
until sufficient governance basis becomes available.Root Reconsideration
New information may materially alter the basis on which the EventFormation Root was established.
EFRM must permit governed reconsideration.
Reconsideration must preserve: previous root association;
previous basis; reason for reconsideration; new information;
revised root association; temporal sequence of changes.
Therefore:
Root Reconsideration ≠ Historical Erasure.
Root Traceability
A governed Event Formation Root should remain traceable to itsbasis.
Where materially required, traceability may preserve: root
identifier; root candidate references; qualification basis;
associated formation; relevant dependencies; source references;
uncertainty; conflict; composite-root structure; revision
history; reconsideration history.
Traceability enables subsequent governance to understand why a
particular operational root was associated with the formation.
Root Independence from Event Boundary
EFRM operates before TREBS determines final Event Boundary.The operational root may help subsequent Boundary governance
understand the formation.
It does not establish which elements ultimately belong inside or
outside the event.
Therefore:
Event Formation Root ≠ Event Boundary.
A root may anchor an event without defining its complete extent.
Root Independence from Event Determination
EFRM does not determine that a Tax-Relevant Event formallyexists.
TREDS later owns Governed Event Determination.
EFRM establishes only one structural dimension required for
formation.
Therefore:
Root Established ≠ Event Determined.
Root Independence from Tax Rules
Event Formation Root should remain governed independently ofjurisdiction-specific tax interpretation.
A subsequent change in tax law should not automatically require
the operational root of the historical event to be rewritten.
Therefore:
Tax Rule Change ≠ Event Root Change by Default.
The same governed Event Formation Root may support multiple
downstream jurisdictional evaluations.
Governance Requirements
EFRM requires that: Root Candidates are evaluated against thegoverned Event Formation; root qualification is based on material
operational relevance; the earliest record is not automatically
treated as the root; technical origin is distinguished from
operational root; dependencies are not automatically converted
into roots; triggers are not automatically converted into roots;
Event Root remains distinct from Identity Origin; Root
Association remains distinct from provenance; Event Root remains
distinct from ownership and authority origin; Event Root remains
distinct from legal causality; Event Root remains distinct from
legal tax point; Event Root does not determine Event Timing;
Event Root does not determine Event Location; single, composite,
and distributed roots may be represented where appropriate;
machine and autonomous roots may be governed without requiring
human initiation; root conflict remains visible; unresolved roots
remain explicitly unresolved; root reconsideration preserves
history; root decisions remain traceable; root establishment does
not determine Event Boundary; root establishment does not
determine legal taxability.
Governance Logic
EFRM applies focused root-association logic:What operational occurrence, action, interaction, transition, or
state most materially anchors this Event Formation?
Is the candidate an operational root or merely a dependency,
trigger, technical record, or surrounding condition?
Can one root be legitimately established, or is a composite or
distributed root required?
Are competing root representations materially conflicting?
Is the root sufficiently established to proceed into Formation
Integrity governance?
The transformation is:
Governed Event Formation + Governed
Dependency Structure
→ Root Candidates→ Operational Relevance
→ Root Qualification / Exclusion
→ Root Association
→ Governed Event Formation Root Association
Minimum Implementation Framework
A minimum EFRM implementation must be capable of:1. receiving the Governed Event Formation Assembly and Governed
Event Formation Dependency Structure; 2. identifying Root
Candidates; 3. assessing operational root relevance; 4.
distinguishing Root Candidates from dependencies; 5.
distinguishing operational roots from technical origins and
triggers; 6. qualifying or excluding Root Candidates; 7.
establishing Single, Composite, or Distributed Root Associations
where justified; 8. supporting machine-generated and autonomous
Event Formation Roots; 9. identifying Root Conflict and Root
Uncertainty; 10. preserving unresolved root states; 11.
preserving root traceability; 12. supporting governed root
reconsideration; 13. preventing root association from becoming
Identity Origin, provenance, ownership, authority, legal
causality, Event Timing, Event Location, Event Boundary, or legal
tax point determination; 14. producing a Governed Event Formation
Root Association; 15. transferring the governed formation,
dependencies, and root association to EFIM for Event Formation
Integrity governance.
EFRM does not prescribe a particular transaction model, event
schema, database structure, ERP architecture, AI model,
distributed ledger, autonomous-system design, identity system,
tax engine, legal causality model, or jurisdiction-specific
taxation methodology.
Governance Outputs
EFRM may produce:Governed Event Formation Root Association — the principal Module
output.
Qualified Event Formation Root — a sufficiently established
operational root.
Excluded Root Candidate — a candidate determined not to represent
the operational root.
Composite Root Association — multiple operational elements
jointly establishing the root.
Distributed Root Association — a root represented across multiple
operational sources or systems.
Unresolved Event Formation Root — a materially relevant root
question that remains unresolved.
Root Conflict Indicator — materially incompatible root
representations.
Root Qualification Record — the governed basis for qualification
or exclusion.
Root Reconsideration Record — preserved history of a materially
revised root.
Root Traceability Reference — linkage between the root
association and its governed basis.
Critical Distinctions
Root Candidate ≠ Qualified Event Formation Root.Candidate identification precedes qualification.
Earliest Record ≠ Event Formation Root by Default.
Chronological precedence does not establish operational root.
Technical Origin ≠ Operational Root.
System representation and operational formation are different
layers.
Formation Dependency ≠ Event Formation Root by Default.
What an event depends upon is not necessarily where its formation
is rooted.
Trigger ≠ Event Formation Root by Default.
A trigger may initiate execution without structurally anchoring
the event.
Event Root ≠ Identity Origin.
EFRM does not govern identity origin.
Root Association ≠ Provenance Governance.
Operational association does not replace provenance governance.
Event Formation Root ≠ Ownership Determination.
Operational root does not determine ownership.
Event Formation Root ≠ Authority Origin.
Operational root does not determine authority.
Operational Root ≠ Legal Cause.
EFRM does not determine legal causality.
Event Formation Root ≠ Legal Tax Point.
Tax law owns legal tax timing.
Event Formation Root ≠ Event Start Time Determination.
TRETS owns Event Timing.
Root Association ≠ Event Location Determination.
TRELS owns Event Location.
Multiple Root Elements ≠ Multiple Events by Default.
Composite formation may still represent one event.
Distributed Root Representation ≠ Multiple Event Roots by
Default.
Distributed technical representation does not determine event
multiplicity.
Human Initiation Is Not Required for Event Formation Root.
Machine economies remain governable.
Autonomous Event Root ≠ Autonomous Legal Responsibility.
Operational autonomy does not determine legal status.
Required Data Field ≠ Legitimately Established Root.
System requirements cannot manufacture governance certainty.
Root Reconsideration ≠ Historical Erasure.
Governance history must remain preserved.
Event Formation Root ≠ Event Boundary.
TREBS owns final Event Boundary.
Root Established ≠ Event Determined.
TREDS owns Governed Event Determination.
Tax Rule Change ≠ Event Root Change by Default.
Operational reality remains independently governed.
Enterprise Application
EFRM addresses a recurring problem in enterprise, platform,financial, autonomous, and distributed systems:
different systems often define the “origin” of the same event
according to whichever technical record they control.
A marketplace may use order creation.
A payment system may use authorization.
An ERP may use invoice creation.
A logistics system may use dispatch.
A cloud platform may use service activation.
An autonomous system may use machine execution.
A tax engine may later use a legally defined tax point.
These are not automatically the same thing.
EFRM establishes a separate governed concept:
the Event Formation Root.
This creates an operational anchor that can remain stable even
when different systems, jurisdictions, accounting methods, or tax
rules subsequently interpret the event differently. Use CasesUse
Case 1 — Cross-Border Digital Transaction Has Five Competing
“Origins”
A global digital platform provides a service involving: customer
order creation in Country A; payment authorization through
infrastructure in Country B; automated service activation in
Country C; cloud execution across several regions; invoicing from
an entity in Country D.
Each system records a different apparent starting point.
A tax engine may additionally apply jurisdiction-specific rules
to determine a legally relevant tax point.
Without EFRM, the operational event may be reconstructed
differently depending on which system or jurisdiction examines
it.
EFRM evaluates the formation independently of those downstream
legal rules.
It may determine that service activation provides the materially
relevant operational root for the governed Event Formation while
preserving order creation and payment authorization as separate
components or dependencies where appropriate.
That determination does not establish: tax jurisdiction; tax
point; taxpayer; tax liability.
The result is one stable operational Event Formation Root that
multiple jurisdictional systems may subsequently evaluate under
their own laws.
One Governed Operational Root
↓
Multiple Possible Jurisdictional
Interpretations. Use Case 2 — Autonomous AI Agent Creates
Transaction Without Direct Human Initiation
An enterprise AI agent continuously manages computational
infrastructure.
Based on operational demand, it autonomously: detects additional
capacity requirements; selects a provider; negotiates within
delegated parameters; reserves resources; activates
infrastructure; initiates machine settlement.
Multiple possible roots exist: the original human delegation; the
AI's capacity decision; the provider selection; the reservation;
infrastructure activation; settlement initiation.
EFDM may identify the earlier delegation as a material
dependency.
EFRM must determine what operationally anchors the specific
infrastructure acquisition formation.
It may establish the autonomous resource commitment or
infrastructure activation as the Event Formation Root without
converting the earlier human delegation into the root merely
because the autonomous action depended upon it.
The result preserves a critical distinction:
the authority that enabled autonomous action is not automatically
the operational root of every event the agent subsequently
creates.
EFRM establishes the operational root.
OBIDENITY® / ASGA™ may govern authority and autonomous execution.
AGA™ may govern accountability.
TRETS later governs timing.
TRELS later governs location.
Jurisdiction-specific tax systems determine legal tax
consequences.
Canonical Boundary
EFRM governs the identification, differentiation, qualification,association, uncertainty, conflict, reconsideration, and
traceability of the operational root of Event Formation. It does
not identify original Formation Components, assemble those
components, establish Formation Dependencies, determine complete
Formation Integrity, determine Event Boundary, govern Identity
Origin, provenance, ownership, authority, legal causality, Event
Timing, Event Location, accountability, legal tax point, taxpayer
status, Tax Jurisdiction, or jurisdiction-specific tax
consequences.
The handoff is:
EFDM — Governed Event Formation Dependency
Structure
→ EFRM — Governed Event Formation Root Association→ EFIM — Event Formation Integrity Module