Event Formation Assembly Module (EFAM)
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: EFAM — Event Formation Assembly Module
Operational Layer: Event Formation Assembly Governance Layer
Category: Governance & Enforcement
Subcategory: Tax-Relevant Event Governance
Type: Core Module
Governed Space: Event Formation Assembly
Origin ID: TREGA-TREFS-EFAM-002
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 Assembly Module (EFAM) governs how qualifiedEvent Formation Components are structurally organized, related,
grouped, ordered, and assembled into a coherent Event Formation
Candidate.
EFAM determines whether qualified components can legitimately
operate together as one structurally meaningful formation,
whether alternative assembly structures must remain visible, and
whether the available component set supports coherent progression
through TREFS.
Its task is specific:
to assemble qualified Event Formation Components into a governed
event structure without determining final Event Boundary,
Formation Dependencies, Event Formation Root, Formation
Integrity, or legal tax consequences.
Operational Role
EFCM establishes:which elements qualify as Event Formation Components.
EFAM then determines:
how those qualified components fit together structurally.
This distinction is necessary because a valid component set does
not automatically produce a valid event structure.
Several legitimate components may: belong to one coherent
formation; belong to different formation candidates; represent
parallel parts of one activity; represent sequential stages;
represent alternative structural interpretations; require further
differentiation before assembly.
Therefore:
Qualified Components ≠ Coherent Event Structure by Default.
EFAM creates the governed structural arrangement required before
Formation Dependencies and the Event Formation Root can be
established.
Internal Flow
Governed Event Formation Component Set↓
Assembly Relationship
Identification
↓
Structural Grouping
↓
Assembly Pattern
Determination
↓
Assembly Coherence Assessment
↓
Alternative /
Conflicting Assembly Handling
↓
Governed Event Formation Assembly
The principal output is:
Governed Event Formation Assembly
This output proceeds to:EFDM — Event Formation Dependency Module
Operational Space
EFAM governs the space between:a governed set of qualified Event Formation Components
and
a coherent structural assembly capable of supporting further
Event Formation governance.
Its operational space includes: component relationship
identification; structural grouping; ordering where materially
relevant; parallel assembly; sequential assembly; composite
assembly; distributed assembly; autonomous assembly;
machine-generated assembly; assembly coherence; assembly
ambiguity; assembly conflict; alternative formation structures;
over-aggregation risk; over-fragmentation risk; assembly
traceability.
EFAM governs how qualified components are structurally brought
together.
It does not determine whether every surrounding dependency
belongs to the event.
Operational Scope
EFAM may assemble formation components originating from:commercial transactions; financial operations; payments;
transfers; production; fulfilment; logistics; service delivery;
platform activity; digital services; enterprise systems; banking
infrastructure; software systems; APIs; autonomous agents; AI
systems; robots; machine-to-machine exchanges; automated
marketplaces; distributed systems; hybrid physical-digital
activity.
The assembly may involve: human actions; organizational actions;
digital actions; machine actions; autonomous actions; distributed
actions.
EFAM remains actor-neutral and technology-neutral.
Assembly Relationship
Qualified components require a legitimate structural basis forbeing assembled together.
Possible assembly relationships may include: sequential;
parallel; conditional; composite; coordinated; distributed;
hierarchical; mutually supporting.
These relationships describe structural formation.
They do not yet establish the broader relationship between
separate governed events.
Therefore:
Assembly Relationship ≠ Event Relationship Governance.
Relationships among governed events are later governed by TRERLS
— Tax-Relevant Event Relationship Standard.
Structural Grouping
EFAM may group components where their combined structurematerially represents one formation candidate.
Grouping should be based on governed structural relevance.
Components should not be grouped solely because they: share an
identifier; appear in the same ERP workflow; involve the same
participant; occur close together in time; are processed by the
same platform; share a payment reference; belong to the same
database record.
Therefore:
Technical Grouping ≠ Event Assembly. Shared Identifier ≠ One
Assembly by Default
A shared identifier can support assembly analysis.
It cannot determine assembly by itself.
One order identifier may include: several deliveries; several
settlements; several service executions; several reversals;
several materially distinct operational actions.
Conversely, one event formation may span several identifiers
across different systems.
Therefore:
Shared Identifier ≠ Common Event Assembly by Default.
Assembly Coherence
A governed assembly should represent a structurallyunderstandable event candidate.
Assembly coherence may consider whether: components materially
relate to the same formation; their arrangement is structurally
consistent; no material contradiction prevents assembly; the
assembly does not depend only on technical proximity; the
structure does not artificially collapse distinct activity; the
structure does not unnecessarily fragment one coherent activity.
EFAM must protect against both over-aggregation and
over-fragmentation.
Over-Aggregation Risk
Over-aggregation occurs when distinct activity is incorrectlycombined into one Event Formation Assembly.
For example:
a marketplace may place:
Order + Refund + Later Replacement Order
under one customer reference.That does not establish that all three belong to one formation.
Therefore:
Common Process ≠ One Assembly by Default.
Over-Fragmentation Risk
Over-fragmentation occurs when one coherent event structure isdivided merely because several technical systems or operational
records are involved.
For example:
Authorization
↓
Activation
↓
Delivery
↓
Settlement
may be represented across four systems.
The existence of four system records does not itself justify four
formation assemblies.
Therefore:
Multiple Systems ≠ Multiple Assemblies by Default.
Sequential Assembly
Some Event Formation Components may form a meaningful sequence.For example:
Commitment
↓
Execution
↓
Fulfilment
The sequence may support structural understanding.
However:
Assembly Sequence ≠ Event Timing Determination.
EFAM may represent structural order without determining the
legally or operationally definitive Event Time.
Event Timing belongs to TRETS.
Parallel Assembly
Some components may occur in parallel while contributing to thesame event formation.
For example:
an autonomous platform may simultaneously allocate: computing
capacity; energy; storage; network resources.
Parallel execution does not automatically imply separate events.
EFAM determines whether these components can legitimately
participate in one formation candidate.
Composite Assembly
A composite assembly may contain several materially differentcomponents that collectively form one coherent structure.
For example:
Service Activation + Resource Allocation +
Delivery Confirmation
may participate in one formation candidate.But:
Composite Assembly ≠ Final Event Boundary.
TREBS later determines the final extent of the event.
Distributed Assembly
An event structure may need to be assembled from components heldacross several systems.
For example:
Marketplace Component
→ Payment Component→ Service Provider Component
→ Enterprise Component
EFAM permits distributed assembly where sufficient governed
linkage exists.
Therefore:
Distributed Components ≠ Separate Assemblies by Default.
Machine and Autonomous Assembly
Autonomous systems may generate complex chains of qualifiedcomponents.
EFAM must assemble those components according to structural
reality rather than machine-process topology.
For example, one autonomous objective may produce:
Negotiation
↓
Reservation
↓
Allocation
↓
Consumption
↓
Settlement
Some elements may form one structure.
Others may later become separate formations.
Therefore:
One Autonomous Objective ≠ One Assembly by Default.
And:
Many Machine Actions ≠ Many Assemblies by Default.
Assembly Ambiguity
The same qualified component set may support more than oneplausible assembly.
For example:
three related service actions may represent: one composite
formation; two connected formations; three independent
formations.
Where the available information does not justify one structure,
EFAM must preserve assembly ambiguity.
Possible states may include:
Assembly Candidate
Assembly Established
Assembly Ambiguous
Assembly Conflict
Assembly Unresolved Alternative Assembly
Structures
EFAM may preserve several alternative assembly candidates whereeach has material support.
The system should not select one simply because it is
operationally convenient.
Alternative assemblies may later be clarified through: additional
dependency analysis; root analysis; integrity assessment; new
evidence; later boundary governance.
Therefore:
Preferred System Structure ≠ Governed Assembly by Default.
Assembly Conflict
An Assembly Conflict exists where qualified components supportmaterially incompatible formation structures.
For example:
one system indicates one composite event;
another indicates two materially separate operational outcomes.
EFAM should preserve the conflict rather than silently resolving
it through system precedence.
Assembly Traceability
A Governed Event Formation Assembly should remain traceable to:the component set received from EFCM; the structural relationship
basis; grouping decisions; exclusions from a particular assembly;
alternative assembly structures; unresolved ambiguity; material
assembly revisions.
This permits later modules to understand how the formation
structure was constructed.
Governance Requirements
EFAM requires that: only governed Event Formation Componentsenter assembly; structural relationships are identified before
grouping; assembly is not determined by technical records alone;
shared identifiers do not automatically create one assembly;
multiple systems do not automatically create multiple assemblies;
over-aggregation risk is controlled; over-fragmentation risk is
controlled; distributed components may be assembled where
justified; autonomous and machine-generated structures remain
actor-neutral; assembly ambiguity remains visible; conflicting
structures are preserved where unresolved; assembly decisions
remain traceable; EFAM does not determine final Event Boundary;
EFAM does not determine Formation Dependencies; EFAM does not
determine Event Formation Root; EFAM does not determine legal
taxability.
Governance Logic
EFAM applies a focused structural logic:How do the qualified Event Formation Components materially relate
to one another?
Which components can legitimately be grouped within the same
formation structure?
Does the proposed assembly avoid both artificial aggregation and
artificial fragmentation?
Are alternative or conflicting assembly structures materially
plausible?
What Governed Event Formation Assembly can legitimately proceed
into dependency governance?
The transformation is:
Governed Component Set
→ Structural Relationships→ Grouping
→ Assembly
→ Coherence Assessment
→ Governed Event Formation Assembly
Minimum Implementation Framework
A minimum EFAM implementation must be capable of:1. receiving the Governed Event Formation Component Set from
EFCM; 2. identifying material structural relationships among
qualified components; 3. grouping components on a governed basis;
4. representing sequential, parallel, composite, or distributed
assembly where relevant; 5. preventing technical identifiers from
automatically defining assembly; 6. detecting over-aggregation
risk; 7. detecting over-fragmentation risk; 8. preserving
alternative assembly candidates where materially justified; 9.
representing Assembly Ambiguity or Assembly Conflict; 10.
preserving assembly traceability; 11. producing a Governed Event
Formation Assembly; 12. transferring that assembly to EFDM for
Formation Dependency governance; 13. preventing assembly from
determining Event Boundary or jurisdiction-specific tax
consequences.
EFAM does not prescribe a specific graph model, workflow engine,
ERP structure, event-stream format, database schema, AI model,
tax engine, or transaction architecture.
Governance Outputs
EFAM may produce:Governed Event Formation Assembly — the principal Module output.
Assembly Relationship Structure — governed representation of how
components relate structurally.
Component Grouping Result — the governed grouping used in
formation.
Composite Assembly Candidate — a multi-component formation
structure.
Alternative Assembly Candidate — a materially plausible
alternative structure.
Assembly Ambiguity Indicator — unresolved uncertainty concerning
assembly.
Assembly Conflict Record — materially incompatible assembly
structures.
Over-Aggregation Indicator — risk that distinct activity has been
combined.
Over-Fragmentation Indicator — risk that one coherent activity
has been unnecessarily divided.
Assembly Traceability Record — the basis through which the
assembly was established.
Critical Distinctions
Qualified Components ≠ Coherent Event Structure by Default.Component qualification does not determine assembly.
Technical Grouping ≠ Event Assembly.
System structure does not establish governed event structure.
Shared Identifier ≠ Common Event Assembly by Default.
Technical identifiers are supporting signals, not structural
proof.
Multiple Systems ≠ Multiple Assemblies by Default.
Distributed representation does not establish event multiplicity.
Common Process ≠ One Assembly by Default.
One operational workflow may contain several event formations.
Assembly Relationship ≠ Event Relationship Governance.
TRERLS later governs relationships among formed events.
Assembly Sequence ≠ Event Timing Determination.
TRETS owns Event Timing.
Composite Assembly ≠ Final Event Boundary.
TREBS owns final event extent.
One Autonomous Objective ≠ One Assembly by Default.
Autonomous purpose does not establish event granularity.
Assembly Conflict ≠ Assembly Failure.
Conflicting structures may remain governed and unresolved.
Preferred System Structure ≠ Governed Assembly by Default.
Operational convenience does not establish methodological
legitimacy.
Event Assembly ≠ Taxability Determination.
EFAM does not determine tax law.
Enterprise Application
EFAM addresses a common problem in complex systems:different systems group the same operational reality differently.
A marketplace may group activity by order.
A bank may group by settlement.
An ERP may group by invoice.
A logistics system may group by shipment.
An autonomous platform may group by machine objective.
Each grouping may be valid internally.
None automatically defines the governed Event Formation Assembly.
EFAM creates a neutral structural layer capable of assembling
qualified components according to event formation logic rather
than the data model of any single system. Use CasesUse Case 1 —
One Marketplace Order Contains Three Deliveries, Two Settlements,
and a Partial Refund
A global marketplace uses one order identifier for a customer
purchase.
The order results in: three separate deliveries; two payment
settlements; one partial refund; multiple ERP records; several
provider fulfilment actions.
EFCM has already qualified the relevant formation components.
If EFAM simply groups everything under the order identifier, the
architecture may create one oversized formation that hides
materially distinct activity.
If every delivery and settlement is separated automatically, the
architecture may create unnecessary fragmentation.
EFAM evaluates the structural relationships among the qualified
components and creates one or more legitimate Assembly Candidates
while preserving ambiguity where required.
The key principle is:
the commercial identifier must not decide the event structure.
Use Case 2 — Autonomous Cloud Marketplace Executes One Objective
Across Hundreds of Parallel Resource Operations
An AI agent purchases computing capacity for a complex workload.
The workload is distributed across multiple providers and creates
hundreds of qualified operational components involving: compute
allocation; storage allocation; network reservation; execution;
release; settlement.
The underlying autonomous objective is one workload, but the
operational components may support several event structures.
EFAM determines whether particular components form coherent
composite assemblies, whether separate provider operations
require distinct assembly candidates, and whether any structure
remains ambiguous.
It prevents both extremes:
one autonomous objective becoming one artificial mega-event
and
every machine-level resource allocation becoming a separate event
formation.
Canonical Boundary
EFAM governs the structural relationship, grouping, arrangement,ambiguity, conflict, and coherent assembly of qualified Event
Formation Components into a Governed Event Formation Assembly. It
does not identify the original components, determine Formation
Dependencies, establish the Event Formation Root, assess complete
Formation Integrity, determine the final Event Boundary, govern
relationships among completed events, or determine any
jurisdiction-specific tax consequence.
The handoff is:
EFCM — Governed Event Formation Component
Set
→ EFAM — Governed Event Formation Assembly→ EFDM — Event Formation Dependency Module