Computational Dialectics

V. What kind of system could a Computational Dialectics Core be?

14. Not reducing reality to numbers, but making relations processable

The question "how will we compute social relations?" is easy to misunderstand. Computational Dialectics does not claim that all reality can be converted into a handful of numbers. Human experience, historical specificity, meaning, institutions, and social relations are not exhausted when compressed into a table.

What we are trying to make computable is narrower: the structure of the representation a model uses for a particular problem, and how that structure changes under evidence.

For example, "worker A works at company B" is not necessarily only an edge between two nodes. If the analysis requires it, the relation type, time interval, contract form, decision authority, income dependence, position in the production process, and links to other institutions may also be part of the representation. In another problem, most of these may be irrelevant.

The goal is therefore not to build a "final ontology of the world," but to develop a representation regime that selects the determinations needed for the question while retaining awareness of what it has left out.

This leads to an important principle:

Computability does not have to mean ontological reduction. Making particular aspects of a relation processable is not the same as claiming the relation consists of nothing else.

15. A temporary but persistent concept/world state

In our long-term architecture hypothesis, the system does not perform only momentary computation over an input token sequence. It carries a temporary world/concept state that is fed by inputs and can change under new evidence.

We do not define this using one mandatory data structure. For exposition, we can separate several conceptual parts:

• entities / referents: things or actors that must be distinguished in the problem;
• relations: links describing how they condition one another;
• process state: how relations change over time;
• scope: where and when a determination is valid;
• evidence: which observations or records support the state;
• rivals: alternative reconstructions still compatible with the same evidence;
• history / lineage: which revisions the state has passed through;
• failure conditions: what new evidence would challenge the current representation.

These do not have to be explicit symbols in the final system. Continuous vector state, relational slots, graph-like latent state, recurrent memory, or another structure may serve the same semantic function.

The critical question is not the name of the data structure, but this:

Can the model access these distinctions behaviorally and causally, or is the whole story merely a post-hoc explanation?

16. Where does the Core sit in the architecture?

The simplest picture of the current working hypothesis is:

TEXT / IMAGE / AUDIO / ACTION / MEASUREMENT
                    │
                    ▼
        neural encoder / language substrate
                    │
                    ▼
          binding + state construction
                    │
                    ▼
       dynamic relational / process state
                    │
                    ▼
      COMPUTATIONAL DIALECTICS CORE
       ├─ frame/scope alignment
       ├─ mismatch diagnosis
       ├─ selective revision
       ├─ rival reconstruction
       ├─ discriminating action
       ├─ schema/concept revision
       └─ mediated reconstruction
                    │
                    ▼
        revised active latent state
                    │
                    ▼
         decoder / policy / action

This diagram is not a final architecture. It is a separation of responsibilities.

16.1 Devim Candidate Cognitive Architecture

From this point onward, the book will carefully separate an architecture thesis from a validated architecture. The strongest candidate direction for Devim today is:

observation / language / action
            │
            ▼
neural perception / encoder
            │
            ▼
concept binding
(entity / event / relation)
            │
            ▼
dynamic world / concept state
(relations / scope / evidence / history / rivals)
            │
            ▼
Computational Dialectics Core
(abstraction / mediation / contradiction diagnosis /
rival reconstruction / discriminating action / revision)
            │
            ▼
latent state transition / rollout
            │
            ▼
decoder / policy / action

The central claim is that thought does not necessarily have to unfold inside a token sequence. Tokens can be powerful input and output surfaces, while the temporary object over which the system reasons may be a world/concept state with relations and revision conditions. In this view, word != concept and embedding != concept: an embedding may be part of access to a concept, but the concept itself is not defined as a single vector or word.

This section describes a candidate architecture today. If later experiments change the result, the book will not bend the evidence in order to preserve the diagram. The architecture must change with what we learn.

16.2 Architecture maturity labels

From this point on, architectural components in the book are tracked with one of four statuses:

• HYPOTHESIS: theoretically motivated, but without controlled experimental support;
• TESTING: actively tested through an executable benchmark or ablation;
• SUPPORTED: reproducible behavioral/causal evidence exists under a matched baseline and preregistered gate;
• INTEGRATED: the mechanism has been connected to the actual Devim model path and has passed post-integration capability/failure tests.

Today, selective relational revision is TESTING. Rival reconstruction, discriminating action, concept/schema revision, and mediated reconstruction remain at HYPOTHESIS level. The B0-v2 stability result supports only that the experimental baseline can be run; it does not support Dialectical Core capability. The overall Devim architecture is not yet INTEGRATED.

16.3 When will we call it "the Devim architecture"?

We do not require a component to be integrated into Devim before discussing it in the book; otherwise we would lose the history of how the research emerged and changed. But we use a harder threshold before calling it part of the validated Devim architecture:

1. the primitive must justify itself against ordinary/generic alternatives in its own controlled benchmark;
2. the advantage must survive different seeds or distributions;
3. causal/ablation evidence must explain the behavioral score;
4. integration into Devim must not damage language generation or basic FORM capability;
5. if the same capability can be obtained through a simpler mechanism, the special dialectical-primitive claim must be withdrawn;
6. after integration, a real state-revision or reasoning advantage must be measurable in use.

When these thresholds are crossed, the status in the book changes SUPPORTED → INTEGRATED, and the diagram becomes part of Devim's reference architecture rather than only a research program.

The language substrate can process text, but the job of the Core is not to produce philosophical sentences. The Core must have an effect on how state is built and rebuilt under changing evidence.

Likewise, if the Core is merely an external Python rule engine that hands a final answer to a neural language model, we have not realized the neural-architecture claim we are investigating. Hybrid systems may still be useful, but causal ablations must separate what is neural, what is symbolic, and which component actually carries the capability.

17. Where does the Transformer fit?

The Transformer may play one or several roles:

1. a strong language encoder/decoder substrate;
2. a computation layer that processes relations inside state;
3. part of the Core itself.

The research does not exclude Transformers, but it does not identify the Core with the Transformer in its current form.

If a vanilla or memory-augmented Transformer learns the same state-revision behavior under matched compute, the case for a special architecture becomes weaker. If recurrent state, slots, SSMs, or special relational updates provide a clear advantage, then an architecture change becomes justified.

For that reason, it is too early to give a single name in answer to "what replaces the Transformer?" The correct order is:

what computation is required → what representation carries it → what architecture learns it best → does the advantage survive scale?

18. How does historical context enter state?

Thinking historically is more than loading historical facts into a model. The same relation can play a different role under different conditions in different periods. State therefore needs to carry not only "what happened?" but also "what did it mean within which structure?"

It is useful to separate two graphs conceptually:

Event graph: which event happened before or after which other event?

Structural/dependency graph: which relation or mechanism conditions or reproduces which outcome?

These are not the same. An institution may have been established earlier in history but not be the fundamental mechanism in an explanation. Conversely, a relation we present first analytically may have taken shape later historically.

If a computational system cannot preserve this distinction, it may mistake historical narrative for causal explanation or turn a structural explanation into a chronological story.

19. Thinking through a social-relation example

Consider the observation:

"Automation increased productivity, but working time did not fall proportionally."

A bad "dialectical" system might immediately stamp the label "contradiction of capitalism" on it. That is not the behavior we want.

A more careful system first asks which determinations are missing:

• how is productivity measured?
• working time for whom and over what period?
• did output volume change?
• did employment change?
• how did wages, ownership, competition, and investment decisions change?
• what happened to technology cost and demand?
• is the same pattern present across sectors?

It can then construct multiple reconstructions. One may suggest that increased output was used to meet additional demand; another that competitive pressure directed the productivity gain toward output rather than reduced working time; a third that the measurement mixes different groups of workers.

The value of these rivals is not their political labels, but that they produce different observational or intervention consequences. What data would distinguish them? Under which changed condition would their predictions diverge? Computational Dialectics begins there.

This example also shows the boundary between social theory and computational mechanism. The model's job is not to reproduce a Marxist conclusion declared correct in advance. Its job is to build a relational/historical representation, expose assumptions, generate rival explanations, and test which ones the evidence supports.

20. Mediation: not inventing a missing link

If a system cannot explain an apparent relation between A and B, it is easy to invent a "hidden mechanism" in between. That is not mediation; it may be confabulation.

Our working rule is stricter:

A mediator candidate should enter the research state only if it produces a new distinction, prediction, observation, or intervention consequence.

If two rival explanations produce the same observable outcomes in every case, their supposed "mechanism difference" is not yet operational. If new data cannot distinguish them, the system must be able to remain unresolved.

21. Rival reconstruction and discriminating action

Retaining multiple explanations is not, by itself, a success. A model can write the same sentence three times in different words.

Real rivals must diverge somewhere:

• a different prediction;
• a different scope;
• a different intervention consequence;
• a different evidence-update behavior.

The next capability follows naturally: which new observation would distinguish these rivals most quickly or reliably?

This can connect Computational Dialectics to an active research loop rather than a system that only "produces interpretations":

state → rivals → discriminating action → external result → revised state

This loop is not the equivalent of human praxis. At machine level it is a narrower external-discrimination loop.

22. What could abstract-to-concrete mean computationally?

"Concrete" here does not mean a longer answer, more nodes, or more detail.

In our working hypothesis, abstraction is the operation of temporarily foregrounding a relation while recording the conditions it leaves out. Concrete reconstruction then attempts to rebuild a whole that explains how the system is produced or reproduced by re-relating the necessary determinations.

A good reconstruction should therefore carry questions such as:

• Which relations produce the outcome?
• Which mediating processes are necessary?
• Which counter-tendencies exist?
• Under what conditions does the relation change direction?
• Which part remains unresolved?

Measuring this is difficult and is currently OPEN. We will not accept easy proxies such as graph density or response length as measures of concreteness.

23. When is concept/schema revision necessary?

Sometimes the problem is not that a value inside the current schema is wrong. The schema itself is inadequate.

If one category systematically produces opposite predictions under two different condition sets, changing confidence may not be enough; a concept split may be required. Conversely, if two separate concepts continually produce the same relations, predictions, and intervention behavior, a merge may be better.

One of the stronger long-term claims of the Core is that the decomposition of representation itself can change under evidence.

But this capability has not yet been established experimentally. D1-B's relation-rebinding task is a controlled precursor to that larger problem.

---