Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners

Full text

1 Introduction

Managers talk about value every day. Product teams "deliver value", operations "protect value", strategy "creates value". Yet two people in the same meeting rarely mean the same thing by the word, and almost never say for whom the value exists. In most organisations the only definition that survives a disagreement is money. Money is countable and widely accepted, but it is also late. Many effects that decide whether a product, a team or a process works happen before money appears or long after it is counted: time spent waiting, effort without result, trust gained or lost, capability built or destroyed.

This is the entry paper of an eight-part series on applying the Theory of Value Management (VMT) and the Æilus methodology in business. Its purpose is narrow: to give practitioners a working vocabulary for value that does not start from money. It defines value, anti-value, value systems, value elements, value flows and value transformers, explains how value can be observed without monetary proxies, and introduces two tools that later papers use repeatedly: the perspective inversion and the transformer efficiency formula. It ends with a one-page glossary.

VMT is a descriptive theory of how value and anti-value arise, move, transform, accumulate and disappear in socio-economic systems. It does not derive prices, rank outcomes as good or bad, or replace economic theory. Æilus is the methodology that operationalises VMT through principles, roles, processes, artifacts and practices. The formal treatment of VMT, including the Æ value currency, is given in "Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective" (Bolshakov, ÆVRI, 2026) and is not repeated here. This paper refers to the VMT axioms (A1-A13) and theorems (T1-T17) by number.

The value system analysed is deliberately generic: a product organisation, its teams and its clients, connected by flows of work, products, money, information and trust. Where an example narrows the boundary, the text names the new boundary. All examples are illustrative. The paper reports no measured data.

2 Value Exists Only in a Value System

2.1 Two axioms that change the question

Axiom A1 (context) states that value is defined only inside a value system. Axiom A2 (multiple interpretations) states that the same reality can produce different values in different value systems. Together they lead to theorem T1: "value in general" does not exist. "This feature is valuable" is incomplete until it says valuable to whom, inside which system, by which criteria. Many arguments about value are not disagreements about facts. They are disagreements about which system is being discussed, held by people who do not notice that they stand in different systems.

2.2 What a value system is

A value system needs at least two actors and at least two directed flows that allow reciprocal interaction. An actor is any entity able to interpret changes in its own state as better or worse: a person, a team, a department, a client organisation, a service. A value system is described by its actors, its flows, the criteria of improvement and deterioration, the rules for interpreting changes, and a time horizon. The boundary is set by the choice of actors and flows.

Theorem T15 gives the consequence: changing the boundary changes the conclusions, even when nothing in reality changes. A support team can look efficient inside the boundary "support department" and look like a source of loss inside "support, product team and clients". Both conclusions can be correct. They belong to different systems.

2.3 Naming the system first

The first working rule of this vocabulary follows: never discuss value without naming the value system. Before asking "is this valuable?" or "who creates value here?", ask three shorter questions: for whom, inside which system, toward which goal. Every later paper in this series opens its analysis by naming its value system and boundary for this reason.

3 Forms of Value and the Value Element

3.1 Four forms of value

Ordinary language treats value as one number attached to a thing. VMT separates four forms, each tied to a different moment and interpreter:

• Potential value - a capability that exists before a recipient and a delivery flow are defined, such as a team skill nobody has asked for yet.
• Planned value - the sender's interpretation of the expected effect once a recipient and a flow are defined: what a product team believes a feature will do.
• Realized value - the recipient's interpretation at the moment of consumption, as an actual change of state: what the user experiences.
• Retrospective value - the recipient's later re-evaluation of realized value, triggered by feedback from further flows: the user learns months later that the feature saved time but locked their data into a format they cannot export.

Axiom A6 (realization) states that value is realized at consumption, not at production. Axiom A4 states that planned and realized value usually do not coincide, and theorem T3 adds that the gap is structural: a zero gap is an unstable special case. The plan/fact gap is therefore not a failure to eliminate. It is a permanent property of value to observe and manage.

3.2 The value element

Value is carried by value elements. A value element is any material or immaterial entity created, selected or transferred within a system, passing through a chain of transformers and carrying planned and realized value or anti-value. The range is intentionally wide: an object, a software feature, a decision, an action, a regulation, a signal, an infrastructure component, even a transformer embedded into another system. Working with elements instead of tasks, projects or products is what makes the four forms usable: it becomes possible to compare plan and fact, see where early estimates failed, and locate where value grows, degrades or turns into anti-value.

3.3 Life cycle: hypothesis, fact, refinement

1. Hypothesis. The element is created with a value hypothesis: for whom, why, with what expected effect. This is planned value, Æ (plan).
2. Fact. When the next transformer consumes the element, the hypothesis is tested through user feedback, analytics or business metrics, and Æ (plan) can be compared with Æ (fact).
3. Refinement. The element moves on, enters new contexts and becomes part of larger systems. At each step its value is refined: increased, reduced, or flipped in sign. This is where retrospective value lives.

The source material uses a brick to illustrate this. A factory produces a strong, standard brick. A builder finds it suitable for a house. A family living in a cold climate finds it thermally inefficient. Eighty years later the house still stands. The brick never changes; the transformers, contexts and assessments do. No transformer can know the final value of an element. Each evaluates it correctly only within its own context.

3.4 A role, not an object

A value element is not a result and not an object in itself. It is the role an entity plays inside a system of transformations. The same code is one element in the delivery flow toward users and another in the maintenance flow inside engineering. Two properties follow:

• Cost of transformation. Elements are transformed with zero depth (resale), partial depth (modification, combination) or full depth (disappearance into a new result). Each transformation has a cost that shapes how the next transformer evaluates the element. Buying toothpaste is a clean exchange, but if it then needs a special brush, the cost of consumption changes the final evaluation.
• Cost of existence. Unused elements take space, need maintenance, complicate systems and influence future decisions. Legacy code, temporary solutions that became permanent and "just in case" artifacts are typical. Existence alone can produce value or anti-value.

Thinking in elements moves a team beyond "done / not done" and explains why correct decisions sometimes produce poor results: the decision was evaluated in one context and realized in another.

4 Anti-Value as an Independent Category

4.1 Why anti-value is not negative value

Axiom A5 states that anti-value is independent of value. It is not zero value and not value with a minus sign. A change of state interpreted as deterioration is anti-value: a task becomes harder, a risk higher, time is lost, trust declines. Anti-value also has planned, realized and retrospective forms.

The distinction matters because one element can carry value and anti-value at the same time, and they do not cancel out for the recipient. A release can deliver a useful function and, in the same flow, a workflow change users must relearn. Netting the two into one score hides both. The user experiences a gain and a separate loss, and the loss can drive the decision to stay or leave regardless of the gain. Kept separate, anti-value becomes trackable. It accumulates rather than disappearing at the end of a sprint, and theorem T6 states that accumulated distortion reduces a system's ability to realize future value.

4.2 Illustrative business examples

The following examples are illustrative, not observed cases.

• Product. A feature added for one large client adds settings and support questions for every other client. One client receives value; the others receive anti-value as complexity.
• Process. An approval step reduces one kind of risk and adds waiting time to every request. The waiting is anti-value produced by a step planned as pure value.
• Management. A decision taken without the team that will carry it out may be right on the merits and still produce lost context, rework and lower trust. A later paper in this series examines leadership decisions and hidden anti-value.
• Support. A client's request arrives carrying anti-value the client already experienced. Whether support converts it into value or passes it on is the subject of a later paper in this series.

5 Value Flows and Transformers

5.1 Flows and transformers

Axiom A3 states that any redistribution of value can be represented as a set of flows. A value flow is a directed interaction between a sender and a recipient in which value elements are transferred. It may connect actors inside the system or an internal actor with an external one. Work handed from design to engineering, a product delivered to a client, payment back to the company and feedback from users are all flows. The flow is where plan meets fact: the sender holds planned value, the recipient forms realized value.

Axiom A7 defines transformation: an actor that realizes incoming value and produces new planned value plays the role of a transformer. A transformer is a role, not an entity. A developer, a team, a service or a client can play it, and several actors can share it. In Æilus schemas the transformer role is drawn as a converter. Theorem T8 links sustainability to roles: a system loses stability when a transformation role cannot be performed or value cannot be delivered, and reserving critical roles increases stability. In Æilus the Value Transformer Owner (VTO) is responsible for a transformer's value production and practices, and the Value System Owner (VSO) for the sustainability of the system. A later paper in this series is devoted to these roles.

5.2 Flow resistance

VMT calls the reasons value does not arrive as planned flow resistance. It has three components: the gap between planned and realized value; realized anti-value produced along the way; and undelivered value, created and sent but never received because of delays, blocking, lost context or forgotten deliverables. Theorem T4 states that resistance accumulates historically. A team that has repeatedly received specifications that did not match reality starts to discount every new one. The discount is rational, and it is itself resistance. An Æilus guardrail follows: reduce resistance, do not move it. Shifting a delay from one team to another may improve a local indicator while total resistance stays the same or grows.

5.3 Leakage

Axiom A10 states that value systems interact only through external flows: inflows and outflows. Axiom A11 defines leakage as a persistent excess of realized value leaving a system over realized value entering it. Leakage is an imbalance over time, not a single loss. Theorem T9 adds a diagnostic: if the observed flows cannot explain why a system stays stable, there are hidden flows or the boundary is wrong. Informal help between teams and unpaid personal effort are typical hidden flows.

6 Observing Value Without Money

6.1 Observation starts with a change of state

Value is observed as a change of state in someone who receives something, not as a property of an object. A document, a feature or a sum of money has no value by itself. Value appears when a task becomes possible, a decision easier, a risk lower, a process faster. Observation needs no dashboard to begin. It starts with four questions about the recipient: did something become easier or harder; did the time to act decrease or increase; did uncertainty turn into clarity or the reverse; did someone gain or lose the ability to take the next step? Changes read as improvement are value. Changes read as deterioration are anti-value.

6.2 Types of signals

Measurement does not always mean numbers. Value can be compared through four types of signal:

• Binary - did this help or not?
• Relative - better or worse than before?
• Ordinal - more valuable than A, less than B?
• Quantitative - how much time was saved, how many errors avoided?

Numbers are useful only while they reflect real changes of state. Detached from interpretation, they represent noise rather than value. This is close to Goodhart's (1975) observation that a measure used as a target loses its link to what it measured. A later paper in this series applies the point to OKRs and KPIs.

6.3 Money as a special case

Money measures one specific form of value exchange. Many important effects happen before or after money changes hands, and two people receiving the same sum can experience very different value. Axiom A13 states that values can be commensurable, partially commensurable or incommensurable. Practitioners should neither force every effect into one currency nor conclude that what cannot be priced cannot be compared. The Æ currency is an instrument for comparison within a named value system, not a claim that all value reduces to one scale.

Once value is observed, patterns appear: where value is consistently lost, where anti-value accumulates, where effort changes nothing. Theorem T14 explains why this matters: value left uninterpreted degrades into lost value. A later paper in this series shows how observation becomes measurement in software delivery with the Value System Schema (VSS).

7 The Perspective Inversion

The usual framing of a business is company, product, client. Inside it, the company receives value from clients as money and the client receives value from the product as utility. The model is useful inside its own boundary.

Now take the client as a value system in its own right. Money is no longer incoming value. It is consumed value. The client spends it to save time, reduce effort, lower risk and enable value creation elsewhere in its own chain. The product is no longer "the value" but an enabling element in the client's production. The same flow and the same transformer acquire opposite meanings: revenue for the company is cost for the client; product value for the business is an efficiency investment for the user. Theorem T2 (flow inversion) states this generally. Neither view is more correct. They belong to different systems.

Many product and monetisation conflicts come from this mismatch, not from mistakes. One party argues from one system, the other answers from another, and neither notices. The pattern appears as pricing disputes, failed monetisation, "users do not appreciate the value" narratives and debates about who the product is for. Without an explicit system, value discussions degrade into ideology.

Used deliberately, the inversion becomes a design tool. Products are designed as value enablers in the client's system, not as containers of value. Monetisation is treated as value extraction that must respect the client's participation condition. Axioms A8 and A9 explain why: an actor stays only while its participation condition holds, and a system is sustainable only while the conditions hold for all actors. Theorem T7 states the alternative: the actor leaves or changes its form of participation. Optimisation shifts from maximising capture to preserving the shared system.

8 Transformer Efficiency

8.1 The formula

"Efficiency" is said of people, teams, companies and states, almost never with a statement of efficiency at what, in which system, at whose expense. Æilus separates four levels: system, flow, transformer and element. Only the transformer has a formula.

Transformer efficiency = (produced value - produced anti-value) / (consumed value - consumed anti-value)

Both sides count anti-value, in line with A5: a transformer may receive anti-value in incoming flows and produce it in outgoing ones. An earlier formulation in the author's material divided by consumed value only. The current form also subtracts consumed anti-value. The formula applies to people, teams, services and departments, and can be calculated inside a named system or for a transformer on its own. Its main consequence is that a transformer need not be efficient in every system at once. The same person can be highly efficient at work and destructive in another system. The formula keeps these apart instead of averaging them.

A hypothetical example shows only the arithmetic. Inside a named product system, a team consumes inputs valued at 100 Æ, of which 10 Æ is anti-value it received (unclear specifications, an unstable environment). It produces 120 Æ of value and 12 Æ of anti-value (defects, added complexity). Its efficiency in that system is (120 - 12) / (100 - 10) = 1.2. The numbers are invented and are not a benchmark.

8.2 Elements, flows and systems

• Element. An element does not decide or choose routes, so the "efficiency of a brick" is the wrong question. What can be measured is the value cost of creating it, its ability to keep value across several transformers, and its potential value in a suitable context. An element can be undervalued at first because the system lacks transformers able to use it.
• Flow. A flow is judged by convergence of plan and fact, by losses (delays, distortions, transaction costs, anti-value) and by dynamics. A large but unpredictable flow is inefficient. Efficiency here means reliability, not size.
• System. A value system is not obliged to be efficient, stable or useful. What it has is viability in three dimensions: balance (feeding its transformers without permanent deficit or rising anti-value), growth (positive dynamics in flows and capacity) and structural fitness (resilience, adaptability, no critical bottlenecks). Below a survival threshold of incoming value a system does not become "inefficient". It begins to die.

8.3 Why system efficiency is a profile

At system level efficiency is a profile, not a number, and it cannot be obtained by adding transformer scores. Theorem T5 states that local optimisation does not guarantee global improvement: a transformer can raise its own ratio by passing anti-value downstream while the system profile worsens. Theorem T13 adds that there is no universal criterion of optimality. The question "is it efficient?" should be replaced by four narrower ones: in which system, through which flows, above or below the survival threshold, at whose expense. VMT also separates efficiency from moral judgement. A system can be efficient internally and still produce anti-value for other systems; the ethical assessment is a separate level of analysis outside this paper.

9 One-Page Glossary

10 Conclusion

Practitioners need a definition of value that does not start from money because much of what decides the fate of products, teams and processes happens outside the monetary flow. VMT supplies one by placing value inside a named value system (A1, A2), separating the forms in which it is planned, realized and re-evaluated (A4, A6, T3), and treating anti-value as a category of its own (A5). The value element, a role rather than an object, links these forms over time through hypothesis, fact and refinement.

Flows and transformers describe how value moves and changes; resistance and leakage describe how it is lost. Observing changes of state through binary, relative, ordinal and quantitative signals makes value visible without reducing it to price. The perspective inversion explains why one flow can be revenue for one party and cost for another, and why many product and monetisation conflicts come from unnamed systems rather than wrong facts. The transformer formula gives a number at the one level where a number makes sense, while the system profile reminds practitioners that local ratios do not add up to global improvement (T5).

The later papers in this series apply this vocabulary to leadership decisions, technical support, AI as a transformer, measuring delivery with the VSS, practices as local value systems, OKRs and KPIs, and value ownership roles. The vocabulary is offered as a working tool, not a validated measurement instrument. It should be tested in use: by naming the system before every value discussion, recording value and anti-value separately, comparing plan and fact element by element, and checking whether conflicts turn out to be about boundaries rather than facts.

References

• Bolshakov, V. Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective. ÆVRI, 2026.
• Bolshakov, V. Value Management Theory. aeilus.tech/theory-of-value-management/, 2026.
• Bolshakov, V. How Can Value Be Observed and Measured? aeilus.tech/welcome/how-can-value-be-observed-and-measured/, 2026.
• Bolshakov, V. Value Elements: What We Actually Produce and Consume. aeilus.tech/news/detail.php?ID=802, 2026.
• Bolshakov, V. Rethinking Efficiency: Value Systems, Flows, Converters, and Elements. aeilus.tech/news/detail.php?ID=803, 2026.
• Bolshakov, V. Value System Perspective Inversion. aeilus.tech/news/detail.php?ID=815, 2026.
• Goodhart, C. Problems of Monetary Management: The U.K. Experience. 1975.