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: EFCM — Event Formation Component Module
Operational Layer: Event Formation Component Governance Layer
Category: Governance & Enforcement
Subcategory: Tax-Relevant Event Governance
Type: Core Module
Governed Space: Event Formation Components
Origin ID: TREGA-TREFS-EFCM-001
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 Component Module (EFCM) governs how materially
relevant elements of a Governed Recognized Occurrence are
identified, differentiated, qualified, and prepared as legitimate
components for subsequent Event Formation.

EFCM determines which observable or governed elements may
participate in the formation of the event structure and which
elements should remain outside the formation-component set
because they represent technical noise, duplicate representation,
background activity, contextual information, or non-forming
dependencies.

Its task is specific:

to establish the governed set of materially relevant Event
Formation Components without assembling those components into the
final event structure or determining the Event Boundary.

Operational Role

TREFS begins after TRERS has established that an occurrence
legitimately warrants Event Formation.

But a recognized occurrence may still contain many different
elements: operational actions; transaction stages; technical
records; system messages; machine operations; value-affecting
actions; supporting activities; duplicated representations;
contextual information; dependencies.

EFCM separates the elements that may legitimately participate in
Event Formation from those that should not automatically become
formation components.

It therefore creates the first structural input to TREFS.

The distinction is fundamental:

Recognized Information ≠ Formation Component by Default.

Internal Flow

Governed Recognized Occurrence

↓

Candidate Formation Element
Identification

↓

Element Differentiation

↓

Formation Relevance
Assessment

↓

Component Qualification / Exclusion

↓

Duplicate and
Technical-Noise Screening

↓

Governed Event Formation Component
Set

The principal output is:

Governed Event Formation Component Set

This output proceeds to:

EFAM — Event Formation Assembly Module
Operational Space

EFCM governs the space between:

a recognized occurrence containing potentially relevant
structural elements

and

a governed set of qualified Event Formation Components ready for
assembly.

Its operational space includes: candidate component
identification; component differentiation; structural relevance;
formation materiality; component qualification; component
exclusion; duplicate component risk; technical-record filtering;
machine-operation filtering; distributed component
identification; autonomous activity component identification;
component uncertainty; component traceability.

EFCM governs what may become part of Event Formation.

It does not govern how those components are assembled.

Operational Scope

EFCM may identify formation components originating from:
commercial transactions; financial operations; payments;
transfers; production; fulfilment; delivery; service execution;
platform activity; digital services; software systems; APIs;
banking infrastructure; enterprise systems; digital assets; AI
agents; autonomous systems; robots; machine-to-machine activity;
automated marketplaces; distributed systems; hybrid
physical-digital processes.

A formation component may represent a human, organizational,
digital, machine-generated, or autonomous operational element.

EFCM remains actor-neutral and technology-neutral.

Candidate Formation Elements

A recognized occurrence may contain more observable information
than Event Formation requires.

Candidate elements may include: initiating actions; operational
state changes; transfer actions; fulfilment actions; service
executions; resource consumption; resource provision; machine
instructions with material operational significance; settlement
actions; digital activations; delivery actions; materially
relevant autonomous actions.

Candidate status means only that the element requires formation
assessment.

Therefore:

Candidate Element ≠ Qualified Formation Component.

Formation Relevance

An element should become a formation component only where it
materially contributes to the structure of the event being
formed.

Formation relevance may arise where the element helps establish:
what operational action occurred; what materially changed; what
was executed; what was transferred; what was delivered; what
service was performed; what operational stage is structurally
necessary; what activity materially contributes to event
formation.

An element should not become a formation component merely because
it exists in the technical record. Technical Record ≠ Formation
Component

Modern systems may produce many records for the same underlying
activity.

Examples include: synchronization records; API retries; database
replication; monitoring messages; internal status updates;
duplicate ledger representations; audit logs; telemetry.

These records may be useful evidence or context.

They do not automatically become Event Formation Components.

Therefore:

Technical Record ≠ Formation Component by Default.

This distinction prevents system architecture from defining event
architecture. Component ≠ Independent Event

A qualified formation component may be materially important
without independently constituting a separate event.

For example:

Authorization

Service Activation

Delivery

Settlement

may each contribute to a broader event formation.

Whether any of these should later become separate events is not
determined by EFCM.

Therefore:

Formation Component ≠ Independent Event by Default.

Component Materiality

EFCM should apply a materiality principle.

A component is materially relevant where removing it would
materially weaken, distort, or misrepresent the structural
understanding of the event formation.

Materiality should not be confused with legal tax materiality.

Therefore:

Formation Materiality ≠ Tax Materiality.

EFCM asks whether the element matters to event structure.

It does not determine whether the element affects tax liability.

Duplicate Component Risk

One operational action may appear several times across systems.

For example:

Payment Gateway Record

→ Bank Record

→ ERP Record

→ Reporting Database

These may represent one underlying operational element.

EFCM must avoid treating each representation as a separate
formation component merely because each exists independently in a
system.

Therefore:

Multiple Records ≠ Multiple Formation Components.

At the same time:

Shared Identifier ≠ Same Component by Default.

Distinct actions may legitimately share identifiers.

Distributed Formation Components

A legitimate component may be visible only through distributed
information.

For example:

one system may record authorization;

another execution;

another confirmation.

EFCM may use governed distributed information to establish a
component where no single system contains a complete
representation.

Therefore:

Distributed Evidence ≠ Multiple Components by Default.

Machine-Generated Components

Machine environments create a particular risk of structural
over-fragmentation.

An automated process may generate thousands of instructions while
only a few materially contribute to Event Formation.

EFCM must distinguish:

technical execution

from

structurally relevant operational action.

Therefore:

Machine Instruction ≠ Formation Component by Default.

Only machine activity materially contributing to the event
structure should enter the component set.

Autonomous Components

Autonomous agents may create legitimate Event Formation
Components without direct human initiation.

For example, an AI agent may: commit to a service; initiate a
transfer; allocate a resource; activate a contractually governed
service; trigger settlement; release an asset.

EFCM may qualify those actions where structurally relevant.

It does not determine legal personhood, responsibility, taxpayer
status, authority, or liability of the autonomous actor.

Component Uncertainty

Where it is unclear whether an element materially belongs in
Event Formation, EFCM should preserve the uncertainty.

Possible states may include:

Component Candidate

Component Qualified

Component Excluded

Component Unresolved

A component should not be included solely because the system
requires a binary decision.

Component Traceability

A qualified component should remain traceable to the basis on
which it entered Event Formation.

Where materially required, traceability may preserve: source
reference; recognized occurrence reference; component type;
qualification basis; materiality basis; duplicate-resolution
basis; uncertainty state; exclusion reason where relevant.

This allows EFAM and later TREGA™ stages to understand why the
element entered the formation structure.

Governance Requirements

EFCM requires that: components originate from a Governed
Recognized Occurrence; technical records do not automatically
become components; candidate elements are differentiated before
qualification; structural relevance is established; formation
materiality is considered; duplicate representations are
controlled; distributed information may support component
identification; machine activity is filtered for structural
relevance; autonomous activity may qualify without human
initiation; component uncertainty remains visible; component
qualification remains traceable; component status does not
determine independent event status; component inclusion does not
determine the final Event Boundary; component qualification does
not determine taxability.

Governance Logic

EFCM applies a simple structural logic:

What materially relevant elements are present within the Governed
Recognized Occurrence?

Which of those elements contribute to Event Formation rather than
merely represent technical, contextual, duplicate, or background
information?

Which elements can be qualified as legitimate Event Formation
Components?

Which elements must be excluded or remain unresolved?

The transformation is:

Recognized Occurrence

→ Candidate Elements

→ Formation Relevance

→ Qualification / Exclusion

→ Governed Event Formation Component Set

Minimum Implementation Framework

A minimum EFCM implementation must be capable of:

1. receiving the Governed Recognized Occurrence from TRERS; 2.
identifying candidate formation elements; 3. distinguishing
operational elements from technical representations; 4. assessing
structural formation relevance; 5. applying formation
materiality; 6. identifying and controlling duplicate component
representations; 7. qualifying legitimate Event Formation
Components; 8. excluding non-forming technical or background
elements; 9. representing unresolved component status where
necessary; 10. preserving source and qualification traceability;
11. producing a Governed Event Formation Component Set; 12.
transferring that set to EFAM for Event Formation Assembly; 13.
preventing component qualification from becoming Event Boundary
or tax determination.

EFCM does not prescribe a specific ERP schema, transaction model,
data format, AI model, rules engine, database, event-stream
implementation, or tax platform.

Governance Outputs

EFCM may produce:

Governed Event Formation Component Set — the principal output of
the Module.

Qualified Formation Component — an element accepted for
subsequent assembly.

Excluded Formation Element — an element determined not to
participate in Event Formation.

Unresolved Formation Component Candidate — an element whose
formation relevance remains unresolved.

Component Qualification Record — the basis for inclusion or
exclusion.

Duplicate Component Indicator — indication that several records
may represent one underlying component.

Component Traceability Reference — linkage between the component
and its governed basis.

Critical Distinctions

Recognized Information ≠ Formation Component by Default.

Recognition does not automatically establish event structure.

Candidate Element ≠ Qualified Formation Component.

Identification precedes qualification.

Technical Record ≠ Formation Component by Default.

System observability does not define structural relevance.

Formation Component ≠ Independent Event by Default.

Event multiplicity is not determined by component count.

Formation Materiality ≠ Tax Materiality.

Structural relevance is not tax-law significance.

Multiple Records ≠ Multiple Formation Components.

Duplicate representation must not create artificial structure.

Shared Identifier ≠ Same Component by Default.

Technical linking is not proof of structural identity.

Machine Instruction ≠ Formation Component by Default.

Technical granularity must not become event granularity.

Component Qualification ≠ Event Assembly.

EFAM owns assembly.

Component Inclusion ≠ Event Boundary.

TREBS later determines final event extent.

Component Qualification ≠ Taxability Determination.

EFCM does not apply tax law.

Enterprise Application

EFCM addresses a common structural problem in enterprise and
public-sector systems:

the data available for an event is usually much larger than the
event structure itself.

A modern platform may expose:

Order Record

↓

API Records

↓

Payment Records

↓

ERP Records

↓

Fulfilment Records

↓

Analytics Records

↓

Tax Interface Records

Without EFCM, every technically available record may be carried
forward as if it contributes equally to formation.

This produces oversized, duplicated, and unstable event
structures.

EFCM creates the first structural filter inside TREFS.

It identifies the operational elements that genuinely matter to
Event Formation and separates them from technical representation.
Use CasesUse Case 1 — One Global Transaction Produces Twenty
Records Across Six Systems

A multinational digital platform processes one service
transaction.

The activity produces: an order record; three API messages; a
payment authorization; a payment confirmation; two ERP postings;
a service activation; a usage record; an invoice; reporting
copies; replicated warehouse records; tax-interface records.

TRERS has already recognized the underlying occurrence.

Without EFCM, all records could be forwarded into Event Formation
and treated as structural elements.

EFCM identifies which records represent materially relevant
operational elements and which are duplicates, technical copies,
or supporting records.

The resulting component set may contain only:

Order Commitment

Service Activation

Service Delivery

Settlement

while preserving traceability to the broader evidence base.

This prevents the event structure from being defined by system
record volume. Use Case 2 — Autonomous Factory Generates 50,000
Machine Actions Around One Commercial Production Cycle

An autonomous factory executes a customer production order.

Robots, sensors, production software, inventory systems,
autonomous transport, and energy-management systems generate more
than 50,000 technical actions.

TRERS recognizes the economically relevant production occurrence.

EFCM then determines which actions materially contribute to Event
Formation.

Machine telemetry, synchronization signals, internal retries, and
control-loop instructions remain outside the formation component
set.

Material production completion, resource transformation, transfer
to finished inventory, and delivery release may qualify as
formation components.

The key result is:

machine execution volume no longer determines event structure.

Canonical Boundary

EFCM governs the identification, differentiation, qualification,
exclusion, uncertainty, and traceability of materially relevant
Event Formation Components within a Governed Recognized
Occurrence. It does not assemble those components into the event
structure, determine formation dependencies, establish the Event
Formation Root, assess complete Formation Integrity, determine
the final Event Boundary, or determine any jurisdiction-specific
tax consequence.

The handoff is:

Governed Recognized Occurrence

→ EFCM — Governed Event Formation Component Set

→ EFAM — Event Formation Assembly Module

Canonical Closing Statement

Event Formation Component Module establishes the first structural
layer of Tax-Relevant Event Formation by determining which
materially relevant elements of a Governed Recognized Occurrence
may legitimately participate in the formation of the event. By
separating operationally meaningful components from technical
records, duplicate representations, machine noise, background
activity, and unresolved elements, EFCM prevents system
granularity from becoming event granularity and ensures that
subsequent Event Formation begins from a governed component set
rather than an uncontrolled collection of data. EFCM therefore
establishes what may enter Event Formation while preserving the
boundaries between component qualification, Event Assembly, Event
Boundary, and jurisdiction-specific tax determination.