Event Formation Dependency Module (EFDM)
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: EFDM — Event Formation Dependency Module
Operational Layer: Event Formation Dependency Governance Layer
Category: Governance & Enforcement
Subcategory: Tax-Relevant Event Governance
Type: Core Module
Governed Space: Event Formation Dependencies
Origin ID: TREGA-TREFS-EFDM-003
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 Dependency Module (EFDM) governs how materialdependencies supporting, enabling, conditioning, constraining, or
otherwise affecting a Governed Event Formation Assembly are
identified, differentiated, qualified, related, and preserved
without automatically incorporating those dependencies into the
formed event itself.
EFDM determines which external or surrounding conditions,
actions, structures, systems, permissions, resources, prior
activities, or operational states are materially necessary to
understand how the event formation became possible or
structurally coherent.
Its task is specific:
to establish the governed dependency structure supporting Event
Formation without treating dependency as automatic Event
Membership, legal causality, Event Root, or final Event Boundary.
Operational Role
EFCM establishes:which elements qualify as Event Formation Components.
EFAM establishes:
how those components are assembled into a coherent formation
structure.
EFDM then determines:
what that formation materially depends upon.
This distinction is necessary because an event may depend on
surrounding activity that does not belong inside the event
itself.
For example:
a payment may depend on an existing account.
A digital service may depend on prior authentication.
An autonomous transaction may depend on delegated authority.
A production event may depend on infrastructure availability.
A machine-to-machine exchange may depend on a previously
established protocol or resource allocation.
Those conditions may be essential to understanding Event
Formation.
They do not automatically become Event Formation Components.
Therefore:
Formation Dependency ≠ Formation Component.
And more importantly:
Formation Dependency ≠ Event Membership.
Internal Flow
Governed Event Formation Assembly↓
Dependency Candidate
Identification
↓
Dependency Relevance Assessment
↓
Dependency
Type Differentiation
↓
Dependency Qualification / Exclusion
↓
Dependency Relationship Establishment
↓
Dependency Conflict /
Uncertainty Handling
↓
Governed Event Formation Dependency
Structure
The principal output is:
Governed Event Formation Dependency
Structure
This output proceeds to:EFRM — Event Formation Root Module
Operational Space
EFDM governs the space between:a Governed Event Formation Assembly
and
a formation structure whose material dependencies are
sufficiently identified and governed for Event Formation Root
analysis.
Its operational space includes: dependency candidate
identification; dependency relevance; enabling dependencies;
conditional dependencies; structural dependencies; resource
dependencies; system dependencies; authorization-related
dependencies; prior-activity dependencies; infrastructure
dependencies; distributed dependencies; machine dependencies;
autonomous-system dependencies; dependency qualification;
dependency exclusion; dependency relationships; dependency
chains; dependency uncertainty; dependency conflict; dependency
traceability.
EFDM governs what the Event Formation materially depends upon.
It does not determine the operational root of the event or
whether a dependency ultimately belongs inside the final Event
Boundary.
Operational Scope
EFDM may govern dependencies associated with: commercialtransactions; financial operations; payments; transfers;
production; supply chains; fulfilment; logistics; service
delivery; digital platforms; marketplaces; banking
infrastructure; enterprise systems; APIs; software services;
digital assets; infrastructure; AI agents; autonomous systems;
robots; machine-to-machine exchanges; automated marketplaces;
distributed systems; hybrid physical-digital environments.
Dependencies may originate from human, organizational,
contractual, digital, infrastructural, machine-generated, or
autonomous environments.
EFDM remains actor-neutral and technology-neutral.
Formation Dependency Principle
An event does not exist in isolation.Its formation may rely on surrounding conditions or prior
activity.
But dependency must remain distinct from structural membership.
For example:
Account Creation
↓
Payment
The payment may depend on the account.
That does not mean account creation becomes part of every later
payment event.
Similarly:
Delegated Authority
↓
Autonomous Purchase
The purchase may depend on valid delegation.
That does not automatically make the delegation itself part of
the purchase event.
Therefore:
Necessary for Formation ≠ Part of the Event by Default.
Dependency Candidate
A Dependency Candidate is an element that may materially support,enable, condition, constrain, or explain the Event Formation
Assembly.
Possible candidates may include: prior authorization; existing
contractual state; account status; infrastructure availability;
prior resource allocation; system permission; operational
prerequisite; platform access; prior transfer; machine
configuration; delegated authority; external service
availability; prerequisite production state.
Candidate status does not establish a dependency.
Therefore:
Dependency Candidate ≠ Qualified Formation Dependency.
Dependency Relevance
A dependency should be qualified only where it materially affectsthe formation or structural understanding of the event.
A dependency may be relevant because the event: could not have
occurred without it; could not have formed in the observed manner
without it; requires it to explain a material structural
relationship; relies on it for execution; relies on it for access
or authorization; relies on a prior operational state; relies on
external infrastructure or resources.
Minor background conditions should not automatically become
governed dependencies.
Otherwise, dependency chains could expand indefinitely.
Background Condition ≠ Formation Dependency
Every event ultimately depends on countless background
conditions.
A digital payment depends on electricity.
Electricity depends on infrastructure.
Infrastructure depends on other systems.
Those facts do not mean every background condition must enter
Event Formation governance.
EFDM therefore requires material dependency relevance.
Background Condition ≠ Formation Dependency by Default.
Only dependencies materially necessary to understand the
formation should be governed within EFDM.
Enabling Dependency
An Enabling Dependency makes the formation operationallypossible.
Examples may include: activated service access; available payment
infrastructure; valid system access; available production
capability; machine availability; resource allocation.
The enabling condition supports formation.
It does not automatically belong to the event.
Conditional Dependency
A Conditional Dependency exists where Event Formation dependsupon a particular condition being satisfied.
For example:
Approval
↓
Release
Authorization
↓
Execution
Inventory Availability
↓
Fulfilment
The condition may be structurally relevant even where it
represents a separate operational occurrence.
Therefore:
Conditional Dependency ≠ Event Component by Default.
Prior-Activity Dependency
A current formation may depend on earlier activity.For example:
a refund may depend on a previous purchase.
A subscription renewal may depend on an existing subscription.
A machine settlement may depend on earlier resource consumption.
A later delivery may depend on a prior production action.
EFDM may preserve that dependency.
It does not automatically merge the earlier activity into the
current event.
Therefore:
Prior Event Dependency ≠ Same Event.
Dependency Chain
Some formations rely on several dependencies.For example:
Delegation
↓
Agent Authorization
↓
Resource Reservation
↓
Service Execution
EFDM may represent a dependency chain where materially necessary.
However, dependency chains must remain proportionate.
The existence of a chain does not require every historical
prerequisite to become part of the governed formation.
Therefore:
Dependency Chain ≠ Event Expansion.
Dependency ≠ Legal Causality
EFDM governs structural and operational dependency.It does not determine legal causation.
For example, establishing that one operational condition enabled
another action does not establish: legal responsibility;
contractual causation; tax liability; damages; fault; legal
attribution.
Therefore:
Formation Dependency ≠ Legal Causality.
Where accountability or liability must be determined, other
governance or legal systems own those questions. Dependency ≠
Authority
An autonomous action may depend on delegated authority.
EFDM may record that the formation relies upon an
authority-related condition.
It does not determine whether the authority was legally valid or
who owns that authority relationship.
Therefore:
Authority Dependency ≠ Authority Governance.
Where available, EFDM may consume governed authority information
from OBIDENITY®, ASGA™, or other relevant architecture.
Dependency ≠ Identity
An event may depend on an existing account, actor relationship,
device, organization, or autonomous agent.
That does not make identity itself part of Event Formation
Dependency governance.
Therefore:
Identity Reference ≠ Identity Governance.
EFDM may consume identity references.
It does not establish identity origin, ownership, continuity, or
provenance.
Distributed Dependencies
A formation may depend on several systems or organizations.For example:
Marketplace
↓
Identity Service
↓
Payment Network
↓
Cloud
Infrastructure
↓
Service Provider
No single system may contain the complete dependency
representation.
EFDM must permit distributed dependencies to be represented where
materially relevant.
Therefore:
Distributed Dependency ≠ Multiple Events by Default.
Machine Dependencies
Machine-generated events may depend on: software state; resourceavailability; sensor state; machine permission; automated
authorization; infrastructure capacity; prior machine execution.
EFDM must distinguish dependencies that materially affect
formation from ordinary machine operating conditions.
Therefore:
Machine Prerequisite ≠ Formation Dependency by Default.
Autonomous Dependencies
Autonomous systems may rely on complex chains of permissions,delegated objectives, resource conditions, or other agents.
EFDM may govern these dependencies where they materially affect
Event Formation.
However:
Autonomous Dependency ≠ Autonomous Responsibility.
The existence of a dependency does not determine who is
accountable for the resulting event.
Dependency Conflict
Different systems may provide incompatible representations of thedependencies supporting the same formation.
For example:
a platform may state that authorization preceded execution;
another system may indicate that execution occurred before final
authorization.
EFDM must preserve material dependency conflict rather than
silently selecting one representation.
Possible states may include:
Dependency Candidate
Dependency Qualified
Dependency Excluded
Dependency Conflict
Dependency Unresolved Dependency
Uncertainty
Where a material dependency cannot be sufficiently established,EFDM must preserve uncertainty.
The system should not invent a dependency merely because one
would make the event structure easier to explain.
Therefore:
Expected Dependency ≠ Established Dependency.
Dependency Traceability
A qualified Formation Dependency should remain traceable to itsgoverned basis.
Where materially required, traceability may preserve: dependency
reference; dependency type; related formation or component;
qualification basis; source reference; dependency relationship;
uncertainty; conflict; revision history.
This allows subsequent modules to distinguish the event structure
from the conditions upon which that structure depends.
Dependency Independence from Event
Boundary
EFDM identifies dependencies before TREBS establishes the finalEvent Boundary.
This means a qualified dependency may later: remain outside the
Event Boundary; contribute to Boundary analysis; relate the event
to another event; become relevant to Event Relationships; require
separate governance.
Therefore:
Qualified Dependency ≠ Boundary Inclusion.
TREBS later determines final event extent.
Governance Requirements
EFDM requires that: dependencies are assessed against a GovernedEvent Formation Assembly; dependency candidates are distinguished
from qualified dependencies; dependency relevance is materially
established; background conditions do not automatically become
dependencies; dependencies remain distinct from Event Formation
Components; dependencies remain distinct from Event Membership;
prior activity is not automatically merged into the current
event; dependency chains remain proportionate; structural
dependency remains distinct from legal causality; identity and
authority dependencies do not absorb identity or authority
governance; distributed dependencies may be represented; machine
prerequisites are filtered for material relevance; dependency
conflicts remain visible; unresolved dependencies remain
explicitly unresolved; dependency decisions remain traceable;
dependency qualification does not determine Event Boundary;
dependency qualification does not determine legal taxability.
Governance Logic
EFDM applies a focused dependency logic:What surrounding condition, action, structure, system, resource,
or prior activity materially supports this Event Formation
Assembly?
Is the relationship sufficiently material to qualify as a
Formation Dependency?
Is the dependency part of the formation structure, or merely a
condition upon which that structure relies?
Are dependency relationships conflicting or unresolved?
What dependency structure must remain visible before Event
Formation Root analysis begins?
The transformation is:
Governed Event Formation Assembly
→ Dependency Candidates→ Dependency Relevance
→ Qualification / Exclusion
→ Dependency Relationships
→ Governed Event Formation Dependency Structure
Minimum Implementation Framework
A minimum EFDM implementation must be capable of:1. receiving the Governed Event Formation Assembly from EFAM; 2.
identifying candidate Formation Dependencies; 3. assessing
material dependency relevance; 4. distinguishing dependencies
from Event Formation Components; 5. distinguishing dependencies
from ordinary background conditions; 6. qualifying or excluding
dependency candidates; 7. representing enabling, conditional,
prior-activity, infrastructural, distributed, machine, or
autonomous dependencies where relevant; 8. representing material
dependency chains without uncontrolled expansion; 9. identifying
Dependency Conflict or Dependency Uncertainty; 10. preserving
dependency traceability; 11. preventing dependency from
automatically becoming Event Membership; 12. producing a Governed
Event Formation Dependency Structure; 13. transferring the
governed formation and dependency structure to EFRM for Event
Formation Root governance; 14. preventing dependency analysis
from becoming Event Boundary, legal causality, responsibility, or
jurisdiction-specific tax determination.
EFDM does not prescribe a specific dependency graph, ERP model,
workflow system, database schema, AI model, transaction
architecture, tax engine, identity system, or legal causality
model.
Governance Outputs
EFDM may produce:Governed Event Formation Dependency Structure — the principal
Module output.
Qualified Formation Dependency — a materially established
dependency supporting Event Formation.
Excluded Dependency Candidate — a candidate determined not to
require dependency governance.
Unresolved Formation Dependency — a materially relevant
dependency whose status remains unresolved.
Dependency Relationship Record — the governed relationship
between a dependency and the formation.
Dependency Chain Reference — representation of materially
relevant connected dependencies.
Dependency Conflict Indicator — indication of materially
incompatible dependency representations.
Dependency Qualification Record — the basis for dependency
qualification or exclusion.
Dependency Traceability Reference — linkage between the
dependency and its governed basis.
Critical Distinctions
Formation Dependency ≠ Formation Component.A dependency may support formation without becoming a component.
Formation Dependency ≠ Event Membership.
Dependency does not determine final inclusion.
Necessary for Formation ≠ Part of the Event by Default.
Operational necessity and structural membership are different
questions.
Dependency Candidate ≠ Qualified Formation Dependency.
Identification precedes qualification.
Background Condition ≠ Formation Dependency by Default.
Dependency governance must remain materially bounded.
Conditional Dependency ≠ Event Component by Default.
A condition may remain external to the formed event.
Prior Event Dependency ≠ Same Event.
Dependency does not merge separate activity.
Dependency Chain ≠ Event Expansion.
Historical prerequisites must not create unlimited event
structures.
Formation Dependency ≠ Legal Causality.
EFDM does not determine legal consequence.
Authority Dependency ≠ Authority Governance.
Authority remains governed by the architecture owning that space.
Identity Reference ≠ Identity Governance.
EFDM may reference identity without governing identity.
Machine Prerequisite ≠ Formation Dependency by Default.
Ordinary machine operation does not automatically become governed
dependency.
Autonomous Dependency ≠ Autonomous Responsibility.
Dependency does not determine accountability.
Expected Dependency ≠ Established Dependency.
Structural assumptions require governed support.
Qualified Dependency ≠ Boundary Inclusion.
TREBS owns final Event Boundary.
Formation Dependency ≠ Taxability Determination.
EFDM does not determine tax law.
Enterprise Application
EFDM addresses a major structural problem in complex enterpriseand digital systems:
systems frequently confuse what an event depends on with what the
event actually is.
A payment may depend on an account.
A delivery may depend on a warehouse release.
A digital service may depend on authentication.
An autonomous transaction may depend on delegated authority.
A production action may depend on resource allocation.
If every prerequisite is absorbed into the event, the event can
expand indefinitely.
If dependencies are ignored entirely, the event loses the
structural conditions necessary to understand how it formed.
EFDM creates the governed middle layer:
the dependency remains visible without automatically becoming
part of the event. Use CasesUse Case 1 — Global Digital Service
Depends on Multiple Prior Activities Across Different Companies
A customer purchases a cloud-based enterprise service through a
global marketplace.
The Event Formation Assembly includes: service commitment;
activation; service execution; settlement.
However, the formation also relies on: prior customer account
creation; platform authentication; an existing provider
agreement; payment authorization infrastructure; previously
allocated cloud capacity.
Without EFDM, a system may either ignore these dependencies
completely or absorb them all into one oversized event.
EFDM determines which dependencies materially support the
formation and preserves their relationship without automatically
treating them as Event Formation Components.
The customer account does not become part of every service event.
The provider agreement does not become part of every execution.
The cloud infrastructure does not become the event merely because
execution depends on it.
The result is a governed dependency structure that explains how
the formation became possible without redefining what the
formation is. Use Case 2 — Autonomous Industrial Network Creates
a Deep Chain of Machine Dependencies
An AI-controlled manufacturing network autonomously accepts a
production requirement and coordinates: production capacity;
energy allocation; robotic equipment; material availability;
autonomous transport; machine authorization; digital settlement.
The resulting Event Formation Assembly depends on several prior
machine and infrastructure states.
If every dependency is recursively absorbed, the event could
expand from one production formation into the entire factory,
energy grid, software stack, and historical authorization chain.
If dependencies are ignored, critical structural relationships
disappear.
EFDM identifies only the dependencies materially necessary to
understand the formation.
It may preserve:
Production Formation
→ depends on Material Availability→ depends on Production Capacity Allocation
→ depends on Authorized Machine Execution
without converting every underlying technical prerequisite into
an Event Formation Component.
The key result is:
dependency remains governable without allowing the event to
expand indefinitely through the systems that made it possible.
Canonical Boundary
EFDM governs the identification, differentiation, qualification,relationship, uncertainty, conflict, and traceability of material
dependencies supporting a Governed Event Formation Assembly. It
does not identify original Event Formation Components, assemble
those components, establish the Event Formation Root, determine
complete Formation Integrity, determine final Event Boundary,
establish legal causality, govern identity or authority,
determine accountability, or determine any jurisdiction-specific
tax consequence.
The handoff is:
EFAM — Governed Event Formation Assembly
→ EFDM — Governed Event Formation Dependency Structure→ EFRM — Event Formation Root Module