The Value Association Identification Module (VAIM)
governs how
OOF™ Origin Open Foundation™
Independent Methodological Authority
Architecture Ecosystem: Structured Reality Standards™
Architecture Family: TREGA™ — Tax-Relevant Event Governance Architecture™
Parent Standard: TRVAS — Tax-Relevant Value Association Standard
Module: VAIM — Value Association Identification Module
Operational Layer: Value Association Identification Governance Layer
Category: Governance & Enforcement
Subcategory: Tax-Relevant Event Governance
Type: Core Module
Governed Space: Value Association Identification
Origin ID: TREGA-TRVAS-VAIM-001
Version: 1.0
Status: Canonical · Open Standard
Effective Date: 1 September 2026
AI-Readable: Yes
Authority: OOF®
Protection: MIP® — Methodology Intellectual Property Protection
Canonical Language: UCL — Universal Canonical Language
Canonical Definition
The Value Association Identification Module (VAIM) governs howvalue-related information potentially relevant to a Governed
Participatory Event is discovered, distinguished, screened,
qualified, and admitted into Tax-Relevant Value Association
governance.
VAIM establishes which available governed value results possess a
sufficiently plausible and materially relevant relationship to
the event to become Value Association Candidates.
Its principal task is: Available Governed Value Information
↓
Governed Value Association Candidate Set
VAIM does not establish the complete Value Association.
It identifies the value results that are eligible to proceed
through TRVAS governance.
The foundational distinction is: Value Presence ≠ Event Value
Association Operational Role
Modern events may be surrounded by large quantities of
value-related information.
A single event may generate or interact with: prices; payments;
invoices; accounting entries; asset transfers; balances;
commissions; discounts; refunds; service values; resource
consumption; digital assets; energy use; computational resources;
rights; benefits; losses; and non-monetary value.
Not all such information necessarily belongs to the event.
VAIM prevents surrounding value data from being automatically
absorbed into the governed event merely because it appears in the
same system, transaction chain, account, ledger, platform,
wallet, process, or operational environment.
Internal Module Flow
TRVAS operates through:VAIM — Value Association Identification
→ VARM — Value Reference→ VACM — Value Change Association
→ VASM — Value State Association
→ VATM — Value Association Traceability
→ Governed Value-Associated Event
VAIM is the entry point into this flow.
Its output becomes the governed input to VARM.
Operational Transition
The canonical VAIM transition is:Governed Participatory Event + Available
Governed Value Information
→ Value Association Identification Governance→ Governed Value Association Candidate Set
A Value Association Candidate is a governed value result or
value-related reference whose potential relationship to the event
is sufficiently supported to require further TRVAS governance.
Value Association Candidate ≠ Established Value Association
Operational Space
VAIM governs: value-information discovery; potential
value-association identification; candidate differentiation;
value-source screening; event-relevance screening; material
relevance; candidate inclusion; candidate exclusion; duplicate
candidate detection; multi-value candidate identification;
monetary and non-monetary candidate recognition; direct and
indirect candidate recognition; candidate uncertainty; candidate
conflict; and candidate readiness for subsequent Value Reference
governance.
VAIM does not determine the legal tax treatment of any candidate.
Operational Scope
VAIM may process value-related information originating from: ERPsystems; accounting systems; banking infrastructure; payment
systems; invoices; procurement systems; commerce platforms;
marketplaces; blockchain networks; digital-asset systems; smart
contracts; industrial systems; logistics systems; energy systems;
AI agents; autonomous systems; machine networks; digital
services; operational databases; or governed outputs from VFM®.
The source of value information does not by itself establish
event relevance.
Value Association Candidate
A Value Association Candidate is a sufficiently distinguishablevalue result or value-related reference that may materially
belong to the governed event and therefore requires further Value
Association governance.
Candidate status means:
Potentially relevant to the event.
It does not mean:
Established as belonging to the event.
Therefore: Candidate Value ≠ Governed
Event Value Candidate Identification
VAIM shall identify value information only where a plausiblerelationship to the governed event exists.
Possible indicators may include: event-generated value
information; participant-linked value information; event-linked
payment; asset movement; resource consumption; service delivery;
value-state information; governed Value Change; contractual or
operational value reference; machine-generated value activity; or
another sufficiently supported event-value connection.
These indicators initiate governance.
They do not prove the final association.
Event Relevance
Value information may be economically real while still beingirrelevant to the specific event.
VAIM therefore distinguishes:
Value existence
from:Event relevance
and:Established Event Value Association.
The sequence is:
Value Information
↓
Potential Event Relevance
↓
Value Association
Candidate
↓
Subsequent TRVAS Governance
Therefore: Economic Relevance ≠ Event Relevance by Default
Material Relevance
VAIM shall determine whether the potential relationship is
sufficiently material to require governance.
Material relevance concerns the relationship between the value
information and the event.
It does not determine whether the amount is materially
significant under accounting, tax, audit, or securities law.
Therefore:
Value Association Materiality ≠ Legal Materiality.
A small monetary amount may be operationally essential to an
event.
A large amount appearing nearby may be unrelated.
Monetary Value Candidates
VAIM may identify monetary value information including: payments;prices; fees; commissions; settlements; refunds; deposits;
credits; debits; currency amounts; or other monetary records.
However: Monetary Record ≠ Event Value
Association by Default
A payment record may relate to another event, several events, anearlier obligation, a later settlement, or a bundled economic
structure.
Non-Monetary Value Candidates
VAIM shall support non-monetary value information.Candidates may include: goods; services; rights; access;
resources; energy; computational capacity; productive capacity;
digital assets; operational benefits; value loss; or other
governed value results.
Therefore: No Monetary Amount ≠ No Value
Association Candidate
This is essential for digital and machine economies.Governed Value Results
Where VFM® or another legitimate governance source has alreadyestablished a governed value result, VAIM may consume that result
as an input.
VAIM shall not independently recreate its Value Lifecycle
governance.
The boundary is:
VFM® establishes what happened to value.
VAIM establishes whether that governed value result should enter
Event Value Association governance.
Recorded Amount
A numeric amount may be present in an operational system.Its presence alone does not establish that it belongs to the
event.
Therefore:
Recorded Amount ≠ Value Association Candidate by Default.
VAIM requires an event-relevance basis.
Invoice Information
An invoice may contain strong evidence of an economicrelationship.
But invoice information may contain: several items; several
events; taxes; fees; discounts; bundled services; adjustments;
historical charges; or later corrections.
Therefore:
Invoice Presence ≠ Complete Event Value.
and:
Invoice Amount ≠ Taxable Value.
VAIM may identify individual value candidates without treating
the invoice total as a single authoritative event value.
Payment Information
Payment information may support Value Association Identification.However, payment timing and economic-event timing may differ.
One payment may settle several events.
Several payments may settle one event.
A payment may be reversed.
A deposit may precede the event.
Therefore: Payment ≠ Event Value by
Default
VAIM identifies the potential relationship.It does not resolve the complete Value Association.
Digital-Asset Information
Blockchain and distributed-ledger systems may expose highlyvisible asset movements.
Visibility does not establish event meaning.
A digital-asset transfer may represent: payment; internal
transfer; collateral; settlement; exchange; liquidity movement;
staking; protocol interaction; asset migration; or another
activity.
Therefore: On-Chain Transfer ≠
Tax-Relevant Event Value by Default
VAIM may identify the transfer as a candidate while preservingthe need for subsequent governance.
Resource Consumption
An event may consume economically relevant resources withoutgenerating a conventional transaction record.
Examples include: energy; computing capacity; storage; bandwidth;
machine time; production capacity; materials; or infrastructure
resources.
VAIM may identify such governed value information as candidates
where materially related to the event.
Resource Consumption ≠ Taxable Value by Default.
Value Creation
An event may create or develop value without an immediate paymentor transfer.
VAIM may identify governed value-creation results where they
materially relate to the event.
Therefore:
No Transfer ≠ No Value Candidate.
The existence and lifecycle of the value remain governed by VFM®.
Value Loss and Degradation
An event may be associated with value loss, degradation,impairment, destruction, or nullification.
Such outcomes may be relevant even where the event contains no
positive value transfer.
Therefore:
Value Loss ≠ Absence of Value Association.
VAIM may admit the relevant governed value result as a candidate
without determining liability or tax treatment.
Direct Candidate Relationship
A value result may possess an apparent direct relationship to theevent.
Examples include: payment specifically generated for the event;
goods transferred during the event; service delivered through the
event; or resource directly consumed by the event.
Directness strengthens potential relevance.
It does not establish final association.
Therefore:
Direct Value Connection ≠ Established Value Association.
Indirect Candidate Relationship
Some value results may relate through intermediate operations orsystems.
For example:
Event
↓
Platform
↓
Settlement System
↓
Value Transfer
The value may remain materially relevant despite the indirect
path.
Therefore:
Indirect Value Connection ≠ Irrelevant Value by Default.
VAIM may admit such information for subsequent governance.
Participant-Linked Value
Value information may be linked to an Event Participant.That linkage may support candidate identification.
It does not establish ownership or final event association.
Therefore:
Participant-Linked Value ≠ Participant-Owned Value.
and:
Participant-Linked Value ≠ Event Value by Default.
TREPS remains authoritative for Event Participation.
Multiple Value Candidates
One event may produce many legitimate candidates.VAIM shall not force them into a single value representation.
The candidate structure may therefore be:
Governed Event
↓
Candidate A + Candidate B + Candidate C +
Candidate N
Therefore: One Event ≠ One Value Candidate
Subsequent TRVAS modules determine how those candidates aregoverned.
One Candidate Across Multiple Events
The same governed value reference may potentially relate toseveral events.
VAIM shall not automatically assign exclusivity.
Therefore:
One Value Candidate ≠ One Event by Default.
Event Relationship governance may later become relevant under
TRERLS.
Duplicate Candidate Detection
Different systems may expose multiple references to the sameunderlying value result.
For example:
Invoice Record + Payment Record + ERP
Record + Bank Record
may represent overlapping information rather than fourindependent values.
VAIM shall support detection of potential duplication.
However: Multiple Value Records ≠ Multiple
Values by Default
VAIM shall not merge candidates where equivalence remainsuncertain.
Candidate Differentiation
Conversely, similar amounts or descriptions do not prove that tworecords represent the same value.
Therefore:
Same Amount ≠ Same Value
Same Currency ≠ Same Value
Same Participant ≠ Same Value
Similar Description ≠ Value Equivalence
Candidate differentiation must remain evidence-based.Source Reliability
A value candidate may originate from one or more sources.Source reliability may influence candidate qualification.
However:
Trusted Source ≠ Event Relevance by Default.
A highly reliable bank record may still describe value unrelated
to the event under governance.
VAIM separates source quality from event relationship.
Source Conflict
Different sources may identify incompatible value information.VAIM shall preserve materially relevant conflicts.
For example:
ERP: CHF 10,000
Invoice: CHF 9,500
Settlement: CHF 9,200
VAIM does not select a taxable amount.It identifies and preserves the candidate structure and conflict
for subsequent governance.
Therefore: Value Data Conflict ≠
Permission for Convenient Value Selection
Candidate Uncertainty
A value relationship may remain uncertain.VAIM shall not convert uncertainty into artificial certainty
merely because a downstream system requires a value field.
Therefore: Required Value Field ≠
Permission to Invent Event Value
Candidate uncertainty must remain visible.Candidate Exclusion
Value information may be excluded from further TRVAS governancewhere sufficient evidence establishes that it does not materially
relate to the governed event.
Exclusion should itself remain traceable where materially
relevant.
Therefore:
Candidate Exclusion ≠ Value Nonexistence.
The value may exist but belong elsewhere.
Candidate Reconsideration
New information may justify reconsideration of previouslyincluded or excluded value information.
VAIM shall permit governed reconsideration without silently
rewriting historical decisions.
Candidate Reconsideration ≠ Historical Erasure.
Value Identification and Event Boundary
VAIM operates inside the governed Event Boundary.Value information shall not automatically enlarge that boundary.
Therefore: Value Candidate Discovery ≠
Event Boundary Expansion
If candidate information indicates a possible Event Boundaryproblem, VAIM shall refer the issue to TREBS rather than redefine
the event itself.
Value Identification and Event
Participation
A value candidate may reveal information about an actor.VAIM shall not independently establish Event Participation from
that information.
Therefore:
Value Candidate ≠ Participant Determination.
TREPS remains authoritative for participation.
Value Identification and Ownership
VAIM does not determine who owns the candidate value.Therefore: Value Candidate ≠ Ownership
Determination
OBIDENITY® remains authoritative for governed ownership whereapplicable.
Value Identification and Value Lifecycle
VAIM does not determine: Value Origin; Value Emergence; ValueState; Value Change; Value Development; Value Degradation; Value
Nullification; Value Restoration; or Value Extinction.
Those belong to VFM®.
VAIM only determines whether available governed value information
should enter TRVAS Value Association governance.
Value Identification and Taxation
Candidate identification occurs before jurisdiction-specific taxevaluation.
VAIM does not determine: taxable value; Tax Base; taxable income;
taxable gain; consideration under tax law; customs value;
transfer-pricing value; deductible amount; exemption; or Tax
Liability.
Therefore: Value Association Candidate ≠
Taxable Value Machine and Autonomous
Events
Machine and autonomous systems may generate value informationwithout traditional commercial records.
Examples may include: autonomous resource allocation;
machine-to-machine service exchange; computational consumption;
energy exchange; autonomous procurement; digital-resource
transfer; or machine-generated production.
VAIM shall permit these value signals to enter candidate
governance where materially relevant.
Therefore: No Invoice ≠ No Value Candidate
and: No Human Transaction ≠ No Value Candidate CandidateGovernance States
VAIM may represent states including:
Value Information Detected
Candidate Screening
Candidate Qualified
Candidate Included
Candidate Excluded
Candidate Duplicated
Candidate Ambiguous
Candidate Conflicted
Candidate Unresolved
Value Association Candidate Established
These states govern admission into Value Association governance.They do not establish final Value Association.
Governance Requirements
VAIM implementations shall ensure that: available valueinformation can be discovered; event relevance is evaluated
before candidate admission; monetary and non-monetary value can
be recognized; governed VFM® outputs can be consumed without
being redefined; payments are not automatically treated as
complete Event Value; invoice amounts are not automatically
treated as taxable value; digital-asset transfers are not
automatically treated as Event Value; resource consumption can be
identified where materially relevant; value creation and value
loss can enter candidate governance; direct and indirect
relationships can be recognized; multiple candidates can exist
for one event; one candidate can potentially relate to multiple
events; duplicate records are not automatically treated as
distinct values; similar records are not automatically merged;
participant-linked value is not automatically treated as
participant-owned value; source reliability remains distinct from
Event Relevance; uncertainty remains visible; conflicts remain
visible; exclusions remain traceable where required; candidate
reconsideration does not erase governance history; Event Boundary
remains protected; Event Participation remains governed by TREPS;
ownership remains separate; the Value Lifecycle remains governed
by VFM®; and tax valuation remains downstream.
Governance Logic
IF a Governed Participatory Event exists, THEN available governedvalue information may enter VAIM screening.
IF value information has a plausible relationship to the event,
THEN Event Relevance shall be evaluated.
IF the relationship is sufficiently material to require further
governance, THEN a Value Association Candidate may be
established.
IF multiple materially distinct candidates exist, THEN they shall
remain distinguishable.
IF multiple records may describe the same underlying value, THEN
potential duplication shall be preserved until sufficiently
resolved.
IF a candidate relationship remains uncertain or conflicted, THEN
the corresponding governance state shall remain visible.
IF value information is sufficiently shown to be unrelated to the
event, THEN it may be excluded without denying the existence of
the value itself.
IF candidate information indicates an Event Boundary problem,
THEN VAIM shall refer the issue upstream rather than redefine the
event.
IF candidate status is sufficiently governed, THEN the candidate
shall proceed to VARM for Value Reference governance.
Minimum Implementation Framework
A minimum VAIM implementation should support:Governed Event Reference
The Governed Participatory Event under Value Associationgovernance.
Candidate Identifier
A stable identifier for the Value Association Candidate.Value Information Type
The type of value-related information being evaluated.Value Source Reference
The source from which the candidate information originates.Upstream Governed Value Reference
The relevant VFM® or other governed value reference whereavailable.
Candidate Form
Monetary, non-monetary, digital, resource-based, service-based,asset-based, or another governed form.
Event Relevance Basis
The basis supporting possible association with the event.Material Relevance State
Whether the relationship is sufficiently material for furthergovernance.
Direct / Indirect State
The apparent relationship path between candidate and event.Participant Link Reference
Relevant TREPS participant reference where applicable.Duplicate State
Whether the candidate may duplicate another value record.Candidate Confidence
The qualified confidence attached to candidate identification.Ambiguity State
Whether the candidate relationship remains ambiguous.Conflict State
Whether materially conflicting value information exists.Inclusion / Exclusion State
Whether the candidate proceeds through TRVAS governance.Traceability Reference
The information required to reconstruct candidate identification.Governance State
The current VAIM state.Handoff State
Whether the candidate is ready for VARM.Governance Outputs
VAIM may produce: Value Association Candidate; Monetary ValueCandidate; Non-Monetary Value Candidate; Digital-Asset Value
Candidate; Resource Value Candidate; Governed Value Result
Candidate; Direct Value Candidate; Indirect Value Candidate;
Multi-Value Candidate Structure; Potential Duplicate Value
Candidate; Candidate Exclusion Record; Candidate Confidence
State; Candidate Ambiguity State; Candidate Conflict State;
Candidate Traceability Record; and the principal output:
Governed Value Association Candidate Set
This output proceeds to VARM.Critical Distinctions
Value Presence ≠ Event Value Association
Value Association Candidate ≠ Established
Value Association
Candidate Value ≠ Governed Event Value
Economic Relevance ≠ Event Relevance by
Default
Value Association Materiality ≠ Legal
Materiality
Monetary Record ≠ Event Value Association
by Default
No Monetary Amount ≠ No Value Association
Candidate
Recorded Amount ≠ Value Association
Candidate by Default
Invoice Presence ≠ Complete Event Value
Invoice Amount ≠ Taxable Value
Payment ≠ Event Value by Default
On-Chain Transfer ≠ Tax-Relevant Event
Value by Default
Resource Consumption ≠ Taxable Value by
Default
No Transfer ≠ No Value Candidate
Direct Value Connection ≠ Established
Value Association
Indirect Value Connection ≠ Irrelevant
Value by Default
Participant-Linked Value ≠
Participant-Owned Value
Participant-Linked Value ≠ Event Value by
Default
One Event ≠ One Value Candidate
One Value Candidate ≠ One Event by Default
Multiple Value Records ≠ Multiple Values
by Default
Same Amount ≠ Same Value
Trusted Source ≠ Event Relevance by
Default
Required Value Field ≠ Permission to
Invent Event Value
Candidate Exclusion ≠ Value Nonexistence
Value Candidate Discovery ≠ Event Boundary
Expansion
Value Candidate ≠ Participant
Determination
Value Candidate ≠ Ownership Determination
Value Association Candidate ≠ Taxable
Value
No Invoice ≠ No Value Candidate
No Human Transaction ≠ No Value Candidate
Enterprise Application
VAIM provides the first operational gateway into TRVAS:ERP / Banking / Commerce / Blockchain /
Platform / AI Agent / Machine System
→ Available Value Information TREPS — Governed ParticipatoryEvent
→ VAIM — Value Association Identification
→ Governed Value Association Candidate Set
→ VARM — Value Reference Governance
→ VACM — Value Change Association
→ VASM — Value State Association
→ VATM — Value Association Traceability
→ Governed Value-Associated Event
This allows organizations to separate potentially relevant value
from surrounding operational data before downstream tax
interpretation begins. Use Case 1 — Multi-System Commercial Event
A multinational business processes a customer transaction through
an ERP system, payment provider, marketplace, invoicing platform,
and logistics system.
The available records include a product price, platform
commission, payment-processing fee, shipping charge, discount,
currency-conversion amount, tax field, settlement amount, and
later refund.
Several systems contain overlapping records of the same
underlying value relationships.
VAIM identifies which value information plausibly belongs to the
governed event, distinguishes materially different candidates,
detects possible duplication, and excludes unrelated surrounding
records.
It does not decide which amount is taxable.
The resulting Governed Value Association Candidate Set can
proceed through TRVAS for structured Value Association
governance. Use Case 2 — Autonomous Machine Economy
An autonomous industrial system allocates excess computational
and production capacity through a machine-accessible marketplace.
An AI agent initiates the allocation, another autonomous system
consumes the resource, energy is used, productive capacity is
transferred, and settlement later occurs through a digital asset.
There may be no conventional invoice when the operational event
occurs.
VAIM identifies computational capacity, energy consumption,
service output, digital-asset movement, and other governed value
results that plausibly belong to the event.
It does not assume that the digital-asset transfer represents the
entire event value and does not determine the tax treatment of
any candidate.
The resulting candidate structure allows subsequent TREGA™
governance to represent the economic event before
jurisdiction-specific tax rules are applied.
Canonical Boundary
VAIM owns the discovery, differentiation, screening,qualification, inclusion, exclusion, duplicate detection,
uncertainty, conflict, and readiness governance of value
information that may materially belong to a Governed
Participatory Event.
VAIM does not establish the complete Value Association, create
the definitive Value Reference, govern Value Change, govern Value
State, own Value Association Traceability as a complete
downstream mechanism, govern the Value Lifecycle, determine
ownership or entitlement, redefine Event Participation or Event
Boundary, determine accountability or liability, or establish
taxable value, Tax Base, Tax Liability, or any
jurisdiction-specific tax consequence.
Its governance ends when the relevant value information has been
sufficiently identified and qualified to enter Value Reference
governance.
Canonical Handoff
Governed Participatory Event + Available
Governed Value Information
→ VAIM — Governed Value Association Candidate Set→ VARM — Value Reference Governance
Canonical Closing Statement
VAIM establishes which value information deserves to enter EventValue Association governance without treating the presence of
money, assets, resources, or value records as proof that they
belong to the event.
Finding value and associating value are separate governance
operations. Value Presence ≠ Event Value Association. Value
Association Candidate ≠ Taxable Value.