What if a domain could be expressed in a form that is human-readable, machine-interpretable, grounded in evidence, executable, and visual?

That question grew out of an earlier experiment: Architecture of the Mind: A Visual Model Through Ruby and Systems Thinking. In that post, concepts such as thought, memory, fear, attention, the observer, and silence were arranged as a system so that their relationships became easier to see.

The next question was more ambitious:

Could the domain itself have a language?

That led to Holoflux.

Here the name is used for a proposed semantic and visual language architecture, inspired by David Bohm’s image of an undivided whole in continuous movement. It is not a claim that Bohm designed this software model. The borrowing is conceptual: instead of treating knowledge as a pile of isolated objects, Holoflux treats concepts, relations, constraints, evidence, and representations as movements inside a larger semantic field.

The goal is not to replace natural language.

It is to make some of its hidden structure explicit.

Contents

• Why a domain language?
• What Holoflux is
• Holoflux, implicate order, and explicate form
• Explicate forms: how Holoflux becomes visible
• The Holoflux artifact model
• The architecture of Holoflux
• How a Holoflux domain is conceived
• A minimal language
• Why Ruby is a useful first runtime
• Krishnamurti as the first reference domain
• Beyond one domain
• Where RAG belongs
• Where intent-oriented programming belongs
• From semantic language to visual language
• What would make the experiment useful?
• References

Why a domain language?

Natural language is extraordinarily expressive, but it often leaves relationships implicit.

A technical specification may mention a customer, eligibility, a policy, an approval, a risk, and an exception across several pages. A philosophical text may discuss thought, memory, fear, attention, time, and the observer over decades of talks. A mythology may distribute a single symbolic movement across gods, places, rituals, transformations, and narrative cycles.

A reader can reconstruct those relationships.

A language model can infer them.

But neither guarantees that two readers—or two model runs—will construct the same semantic structure.

A domain language can make that structure inspectable.

The simplest transformation is:

The important move is not from prose to code.

It is from implicit meaning to explicit relationships.

Holoflux therefore begins with a small set of semantic primitives:

Primitive	Purpose
domain	Establishes a bounded field of meaning.
concept	Declares a semantic entity or idea.
relation	Connects concepts with a typed meaning.
constraint	Defines what is valid, invalid, conditional, or bounded.
source	Grounds a claim or definition in evidence.
context	States the perspective in which a relation is meaningful.
movement	Represents process, transition, emergence, or transformation.
field	Represents a context that should not be reduced to a simple causal node.
correspondence	Expresses a qualified cross-domain similarity without declaring identity.

That last primitive matters. A good cross-domain system should be able to say:

A resembles B because of X,
but differs from B in Y.

rather than collapsing everything into A == B.

What Holoflux is

Holoflux is best understood as a semantic movement with a stack of supporting components, not as one file format or one stored graph.

At the center is a semantic domain language. Around it are the components that make the language useful:

• human intent gives direction;
• AI interprets, extracts, proposes, compares, and explains;
• a Holoflux domain gives explicit semantic structure;
• sources and RAG provide evidence and provenance;
• a semantic graph makes relationships traversable;
• Ruby is the first reference runtime;
• explication selects scope, intent, audience, depth, and representation;
• a visual grammar renders one family of explicate artifacts as diagrams, maps, and interactive spaces.

The separation of responsibilities is essential:

The domain gives meaning. Holoflux gives structure. RAG gives evidence. AI gives interpretation. Ruby gives execution. Human judgment gives authority.

This prevents the AI layer from quietly becoming the ontology.

Holoflux, implicate order, and explicate form

The name Holoflux is inspired by David Bohm’s language of wholeness, holomovement, and the relation between implicate and explicate order. The analogy is useful, but it should not be turned into a literal identity.

Holoflux is not Bohm’s implicate order in software form.

A computational model is already a selection. It names concepts, draws boundaries, and makes relations explicit. What Holoflux can do is preserve a richer semantic whole from which several contextual representations may be unfolded.

The distinction becomes:

Implicate order          philosophical inspiration
       ↓
Holoflux Model           structured, enfolded semantic whole
       ↓
Explication              contextual unfolding
       ↓
Explicate Artifact       Mermaid · prose · DSL · infographic · UI

The more important insight is that Holoflux should name the movement, not only the stored model.

This gives Holoflux a more precise conceptual center:

Holoflux is the continuous semantic movement between a structured, enfolded model of meaning and the multiple explicate forms through which that meaning becomes observable, communicable, executable, and revisable.

The model is therefore one state inside Holoflux, not the whole of Holoflux.

Explicate forms: how Holoflux becomes visible

An explicate form is a contextual projection of the semantic whole.

The same domain model can unfold differently depending on what the user wants to understand.

For example, suppose the model contains:

relation :thought, :creates, :observer
relation :attention, :reveals, :what_is

One explicate form may be executable Ruby:

domain.explicate(
  focus: :observer,
  intent: :understand,
  audience: :developer,
  representation: :ruby
)

Another may be Mermaid:

And another may be prose:

Thought constructs a psychological observer, while attention reveals what is present without first turning it into an object of psychological interpretation.

These are not three different models.

They are three explicate artifacts derived from the same semantic source.

A Holoflux explication therefore needs more than a format selector. It has at least four dimensions:

WHAT      semantic scope
WHY       intent
FOR WHOM  audience / context
HOW       representation

A more complete request could look like:

explicate :fear do
  intent :understand
  audience :beginner
  scope :psychological_time
  depth :conceptual
  representation :mermaid
end

Changing the audience or intent may produce a different artifact without changing the underlying domain.

That separation is essential. Otherwise a diagram can accidentally become the ontology.

The Holoflux artifact model

The word artifact becomes useful once the layers are separated.

A practical Holoflux system can expose at least three related artifacts:

Artifact	Responsibility
Holoflux Model	The governed semantic structure of the domain.
Holoflux Explication	A contextual projection specification: scope, intent, audience, depth, representation.
Explicate Artifact	The material result: Mermaid, prose, Ruby, SVG, infographic, interactive view, or another representation.

That gives us a transformation such as:

Holoflux Model
   Krishnamurti domain
          ↓
Holoflux Explication
   fear through psychological time
          ↓
Explicate Artifact
   Mermaid concept map

The same explication could instead target an infographic, a narrated explanation, or a queryable graph view.

In a future implementation, this could become a first-class API:

view = domain.explicate(:fear) do
  through :psychological_time
  audience :beginner
  depth :conceptual
  representation :mermaid
end

view.render

The important invariant is:

representation may change without silently changing domain meaning.

If a representation causes a new semantic insight, that insight enters a different path: proposal, review, and only then revision of the canonical domain.

The architecture of Holoflux

The complete architecture can be summarized compactly:

Each layer has a different responsibility.

Human intent states what matters: explain fear, compare two traditions, trace a telecom handover, visualize a Rails request path.

The AI interpreter translates that intent into semantic operations. It can select a domain, identify relevant concepts, propose a traversal, request evidence, and choose an output form.

The Holoflux domain is the governed semantic model. It contains the domain’s concepts, typed relations, constraints, contexts, sources, and accepted interpretations.

The semantic model or graph makes that structure computationally traversable.

The Ruby runtime validates, queries, composes, serializes, and renders the model.

Explication sits between the semantic model and any representation. It determines which part of the whole is unfolded, for what intent, for whom, at what depth, and in which form.

The visual language is one important family of explicate artifacts: a representation in which relation types are not merely arrows with different labels but have their own visual grammar.

The evidence layer is deliberately below the architecture rather than inside the AI box. Evidence should remain independently addressable.

How a Holoflux domain is conceived

A language needs a specification. A domain built with that language needs an authoring process.

The proposed model is AI-assisted and human-governed:

The AI can discover patterns, but discovery is not semantic authority.

A useful lifecycle has at least three explicit states:

candidate → reviewed → canonical

A model could propose:

relation :attention, :creates, :silence

But a domain reviewer might reject that relation because creates imposes a causal meaning the source does not support. The reviewed relation could instead become:

relation :attention, :reveals, :silence

or even remain deliberately unresolved.

The language should preserve this distinction.

A future specification could make provenance first-class:

relation :thought, :creates, :observer do
  status :reviewed

  evidence do
    source :brockwood_1970_talk_1
    confidence :high
  end
end

The resulting domain is not a claim of final truth. It is a versioned semantic model whose assumptions are visible.

A minimal language

A first Holoflux syntax does not need to be large.

domain :krishnamurti do
  concept :what_is, kind: :fact
  concept :thought, kind: :movement
  concept :observer, kind: :constructed_center
  concept :attention, kind: :field
  concept :silence, kind: :field
  concept :whole, kind: :field

  relation :thought, :creates, :observer
  relation :attention, :reveals, :what_is
  relation :silence, :opens_to, :whole
end

The code is intentionally readable without knowing much Ruby.

A technical domain could use the same core:

domain :lte_handover do
  concept :ue
  concept :source_cell
  concept :target_cell
  concept :measurement_report
  concept :handover_command

  relation :ue, :reports_to, :source_cell
  relation :source_cell, :selects, :target_cell
  relation :source_cell, :sends, :handover_command
end

The vocabulary changes.

The semantic machinery does not.

That is the test of whether Holoflux is a general language or merely a Krishnamurti DSL.

Why Ruby is a useful first runtime

Ruby is not part of the definition of Holoflux.

It is the first implementation language.

That distinction matters:

Holoflux specification ≠ Ruby DSL
Holoflux specification → Ruby reference implementation

Ruby is attractive because blocks, symbols, metaprogramming, and contextual evaluation make it possible to prototype a readable internal DSL before committing to a separate parser.

A small executable sketch is included in the support material:

Download the Holoflux v0.1 support package

The core idea looks like this:

Holoflux.domain(:krishnamurti) do
  concept :what_is, kind: :fact
  concept :thought, kind: :movement
  concept :observer, kind: :constructed_center

  relation :thought, :creates, :observer,
    status: :candidate
end

Ruby’s instance_eval can evaluate a block in the context of a receiver, which is one of the mechanisms that makes this internal-DSL style practical. The semantic specification, however, should remain implementation-independent so that a later TypeScript runtime, visual editor, or interchange format can share the same model.

Krishnamurti as the first reference domain

Krishnamurti is useful as a first reference domain precisely because it is difficult to reduce to ordinary boxes and arrows.

The earlier architecture-of-the-mind experiment already exposed several relationships:

• memory and knowledge participate in thought;
• thought can construct an observer that appears separate from what is observed;
• psychological time connects memory, projection, fear, desire, and becoming;
• choiceless awareness is not another controller;
• attention is described without a psychological center;
• silence and wholeness should not be modeled as objects manufactured by thought.

A compact Holoflux view can separate two movements:

what-is is especially important.

It gives the language a starting point that is not a conclusion:

concept :what_is do
  kind :fact
  before :interpretation
  before :comparison
  before :psychological_projection
end

This is where a semantic language can do more than a generic knowledge graph. It can define that some constructs are fields, some are movements, some are constructed centers, and some relations are intentionally non-causal.

Krishnamurti Foundation material on awareness repeatedly distinguishes awareness and attention from concentration and emphasizes observation without choice. The earlier blog post used this distinction as a systems metaphor; Holoflux turns the metaphor into a candidate domain model rather than treating it as universal ontology.

Beyond one domain

A general language must survive a second domain.

And then a third.

The most useful stress test is not to choose only similar cultural domains. Holoflux should be able to represent very different semantic worlds:

• Krishnamurti — thought, attention, observer, psychological time, silence;
• Egyptian mythology — deities, thresholds, transformations, cycles, symbols;
• Bohm — implicate and explicate orders, holomovement, dialogue, wholeness;
• Tarot — symbolic forms, archetypal relations, sequences, correspondences;
• telecom — nodes, protocols, states, events, measurements, handovers;
• software architecture — components, dependencies, messages, constraints, runtime evidence;
• education — concepts, learning progressions, misconceptions, assessments.

What is common is not the subject matter.

It is the need to express:

concepts
relations
constraints
contexts
sources
movements
representations

A cultural domain may use a rich symbolic layer.

A telecom domain may use almost none.

The core should not care.

Where RAG belongs

RAG is useful, but it is not the language.

A conventional RAG pipeline often looks like:

question → retrieve chunks → LLM → answer

GraphRAG adds explicit graph structure. Microsoft’s GraphRAG project describes an indexing process that extracts entities, relationships, and claims from text and then uses those structures during retrieval and querying.

Holoflux proposes a different responsibility boundary:

Holoflux domain → determines semantic structure
RAG / GraphRAG → finds supporting evidence
AI → interprets the query and evidence
human governance → decides what becomes canonical

This means retrieval can be guided by the domain model.

If a question involves fear, thought, and psychological_time, the system can use those semantic relations to decide what evidence it needs rather than relying only on nearest-vector similarity.

The distinction can be summarized as:

RAG retrieves knowledge. Holoflux makes the intended semantic structure explicit.

Where intent-oriented programming belongs

Intent-oriented programming remains relevant, but it belongs above the domain model.

Holoflux answers:

What does this domain mean?

Intent-oriented interaction answers:

What do I want to discover or accomplish within that meaning?

For example:

use_domain :krishnamurti

intent "explain fear visually" do
  emphasize :psychological_time
  audience :beginner
  output :concept_map
end

The intent should not have to specify graph traversal, evidence selection, diagram syntax, or layout.

Those are implementation decisions.

This gives the two ideas a clean relationship:

Holoflux defines the semantic space. Intent-oriented programming navigates that space.

From semantic language to visual language

The semantic language is not the final destination.

The long-term idea is a visual language whose elements carry executable semantic meaning.

A conventional knowledge graph often reduces everything to nodes and labeled edges:

A ──relation──> B

Holoflux can eventually do better.

Different semantic relationships could have different visual grammar:

Semantic meaning	Possible visual grammar
creates	directed emergence
conditions	surrounding influence
contains	field or enclosure
opposes	tension / polarity
transforms_into	state transition
reveals	removal of obstruction
corresponds_to	qualified bridge
whole	containing field rather than ordinary node

The visual representation could also become bidirectional:

Holoflux → semantic graph → visual language
Holoflux ← semantic graph ← visual editing

A user could move a concept, connect two structures, qualify a relationship, or open its evidence. The visual act would modify the semantic model rather than merely producing a picture.

That is the larger possibility:

not a visual interface for AI, but a visual language shared by humans, software, and AI.

What would make the experiment useful?

The proposal is technically conceivable with existing components: DSL techniques, LLM extraction, knowledge graphs, RAG, graph retrieval, Ruby runtimes, Mermaid, SVG, and interactive web visualization.

The unanswered question is not whether those components exist.

It is whether the semantic layer improves understanding enough to justify itself.

A useful v0.1 should therefore stay small:

1. define a minimal Holoflux language;
2. implement the Ruby reference runtime;
3. model one difficult domain: Krishnamurti;
4. model one very different domain: telecom;
5. support explain, trace, and visualize;
6. attach evidence to non-trivial relations;
7. compare the results with unconstrained LLM answers;
8. measure whether the structured version is easier to inspect, challenge, reuse, and visualize.

If that works, the next step is not a larger prompt.

It is a real language specification.

Final thought

Bohm’s holomovement points to an undivided movement from which explicit forms can be abstracted. Any language necessarily does the opposite: it draws boundaries, names things, and makes relations explicit.

That tension is useful.

Holoflux should never claim to capture the whole.

Its purpose is more modest:

to make explicit forms while preserving awareness that they belong to a larger movement of meaning.

Or more compactly:

Holoflux is not the diagram. It is the movement from meaning into form — and from form back into meaning.

A domain model is a map.

A semantic graph is a map.

A visual language is a map.

The value of Holoflux would be in making those maps explicit, grounded, revisable, and capable of leading us back to the territory.

References

• Architecture of the Mind: A Visual Model Through Ruby and Systems Thinking
• David Bohm — The Implicate or Enfolded Order: A New Order for Physics
• Pari Center — Interview with David Bohm on the holomovement
• Lohrey & Boreham — Lifting the veil on Bohm’s holomovement
• Krishnamurti Foundation Trust — Krishnamurti on Awareness
• Krishnamurti Foundation Trust — Thought and the Awakening of Intelligence
• Krishnamurti Foundation Trust — Time, Action and Fear
• Ruby documentation — BasicObject#instance_eval
• Microsoft GraphRAG — documentation
• Microsoft GraphRAG — indexing architecture
• Microsoft GraphRAG — visualization guide