In Æilus, value is never delivered in a vacuum. The same value element can be interpreted differently depending on the context in which it is delivered.
Æilus formalizes these contexts as Domains, and the constraints they impose as Domain Policies. Domains are not optional “non-functional extras”. They define whether delivered value remains acceptable or becomes anti-value.
Why domains exist
A common failure mode in real systems is producing something that looks like value locally, but becomes anti-value at the system level.
For example, a functional improvement may be acceptable from a “feature” perspective, but unacceptable from a security or continuity perspective. In such cases, value is not rejected because it is useless - it is rejected because it violates the context required for safe participation.
Domains exist to make this explicit:
Domains define the context in which value is interpreted and accepted.
Definition: Domain
A Domain is a type of value-interpretation context that imposes requirements on admissible practices, processes, and outcomes of a transformer.
Domains:
- do not create value directly;
- prevent non-admissible anti-value;
- protect the admissibility and sustainability of delivered value over time.
Domains exist because value interpretation depends not only on “what was delivered”, but also on “under which conditions it was delivered”.
Domains as a mechanism for partial commensurability
In Æilus, domains are not “additional aspects” of delivery. They are a methodological mechanism for operating in systems where value is not fully commensurable. A single scalar score is often insufficient to represent value conflicts across performance, availability, security, compliance, knowledge, and other contexts.
Domains therefore function as partial value spaces: each domain provides its own constraints and admissibility criteria, and domain policies define what is acceptable before value can be considered deliverable within the system.
Definition: Domain Policy
A Domain Policy is a set of requirements for transformer practices that ensures:
- an admissible level of value interpretation within the domain,
- prevention of violations of participation conditions,
- preservation of value system sustainability.
Domain policies:
- do not define which value should be produced;
- define how value may be produced without generating non-admissible anti-value.
Aggregation policy and domain trade-offs
When domains conflict, a value system must rely on an explicit aggregation policy (or trade-off policy). Without it, “system value” becomes an implicit and unstable claim, and optimization degenerates into local preference, political influence, or metric gaming.
Domain Owners enforce domain policies locally, while the Value System Owner defines how cross-domain trade-offs are resolved at the system level.
Domains as a bridge between actors
Domains act as a synchronization mechanism for value interpretation between transformers and receiving actors.
They answer a systemic question:
Is the delivered value acceptable under the constraints that matter to the receiver?
Without domains, systems often drift into local optimization: transformers maximize output and planned value, while recipients experience instability, risk, and hidden anti-value.
Evaluating practices through domains
In Æilus, practices are never evaluated as “good” in the abstract. They are evaluated relative to the domains in which the transformer operates.
A practice is admissible if:
- it satisfies domain policies of the transformer;
- it does not violate value interpretation for receiving actors;
- it does not lead to violations of participation conditions or sustainability of the value system.
The same practice may be admissible in one domain and non-admissible in another.
Typical domains
Æilus does not define a closed or universal list of domains. The set of domains is determined by the value system context and the transformer’s participation requirements.
Typical domains may include (but are not limited to):
- Performance
- Availability and Continuity
- Security
- Architecture
- Continuous Improvement
- Knowledge Management
Domains can be introduced whenever “good vs bad” interpretation becomes impossible without specifying a quality context.
Domain Owner role
A Domain Owner may be introduced when a domain becomes critical for value interpretation and system sustainability. This role is responsible for:
- defining and maintaining domain policies;
- assessing practices and processes against domain requirements;
- detecting systemic anti-value caused by domain violations;
- early escalation of domain risks threatening sustainability and participation conditions.
The Domain Owner:
- does not “produce value” directly;
- does not replace the Value Transformer Owner;
- acts in the interest of sustainability of the value system.
In short:
Domains do not optimize value. Domains prevent value from becoming non-admissible.