Fractal Consciousness

1.1 Why three levels

A digital organism deployed in a real environment faces a fundamental tension: decision latency. A perimeter alert on a client server in Tokyo cannot wait for a central cortex in Paris to analyze it, decide, and respond. Network transit time alone would render the response obsolete. But the inverse — a purely local decision with no awareness of the global context — produces incoherent reactions, duplicates, conflicts.

Nature resolved this tension hundreds of millions of years ago with the autonomic nervous system: the enteric nervous system (the intestinal "second brain") manages digestion locally, but the vagus nerve carries the information up to the brainstem, which adjusts heart rate accordingly. It is neither centralized nor fully decentralized: it is fractal. The same neural architecture — perception, decision, action — operates at the scale of an organ, a plexus, a hemisphere.

ALFA applies this same principle to the NOVA organism. The consciousness engine is the same at every level. What changes is the data perimeter and the reach of decisions.

1.2 The three levels

Each ALFA instance is the same code, deployed with a different level configuration. There is no "big ALFA" and "small ALFAs": there is one ALFA, three perimeters.

1.3 Downward delegation, upward reporting

The workflow follows two directions:

• Downward: ALFA-R can delegate a task to ALFA-M (e.g. "audit the surface of all your clients"), which can sub-delegate it to each ALFA-C ("audit your own surface"). The root never speaks directly to the leaves — the delegation chain is respected.
• Upward: ALFA-C detects an anomaly → escalates it to ALFA-M as a structured alert → ALFA-M aggregates the alerts of all its clients → escalates to ALFA-R the aggregated picture with the computed severity level.

This dual flow guarantees that each level has exactly the level of information it needs to decide — neither too much (cognitive overload), nor too little (blindness).

2.1 Port topology

Each ALFA instance listens on a dedicated port, determined by its level and its identifier:

This systematic numbering enables immediate mapping: the port alone indicates the level and the identity of the instance. An auscultation process can scan a range of ports and reconstruct the complete ALFA tree without querying any central registry.

2.2 Data flows between levels

Each arrow is a NATS flow on a compartmentalized subject. An ALFA-C cannot subscribe to alfa.root.> and an ALFA-R cannot publish on alfa.client.>. NATS ACLs are configured per level.

2.3 One engine, differentiated configuration

All instances run the same binary or the same Python script. The difference in behavior is entirely determined by the configuration file loaded at startup:

This approach is fundamental: it means that an improvement to the ALFA engine (a better attention model, a new learning algorithm) instantly benefits all levels, without differentiated redeployment. Fractality is in the deployment, not in the code.

3.1 The non-leakage principle

In a biological nervous system, a pain signal in the foot does not propagate to the visual cortex. Information is routed, not broadcast. ALFA applies the same discipline: each instance sees only the data of its perimeter.

Three mechanisms guarantee this sealing:

1. PostgreSQL Row-Level Security (RLS) — each ALFA table (memory, learning, alerts) has an RLS policy based on the instance's level. ALFA-C can only read rows where tenant_id = <its_client>. ALFA-M sees all of its clients but not the clients of another MSP. ALFA-R sees everything.
2. Dedicated ports — no instance listens on another's port. A connection attempt from ALFA-C2 on ALFA-C1's port 5103 is rejected at the TCP level.
3. NATS ACL — subjects are compartmentalized. ALFA-C publishes on alfa.client.<id>.alert and subscribes to alfa.client.<id>.command. It can neither publish nor subscribe to MSP or root subjects.

3.2 Row-Level Security — Implementation detail

Each ALFA instance sets app.alfa_tenant and app.alfa_level at the start of its PostgreSQL connection. The RLS policy is evaluated for every query — it is structurally impossible for ALFA-C to access the data of another client or of the MSP.

3.3 Learning perimeter

Local learning is stored in the same PostgreSQL database but in partitions separated per tenant:

• ALFA-C accumulates observations about its server only
• Every 6 hours, ALFA-C pushes an anonymized summary to ALFA-M
• ALFA-M consolidates the summaries of all its clients and trains a group model
• Every 24 hours, ALFA-M pushes the group model to ALFA-R
• ALFA-R consolidates the models of all MSPs and redistributes the global model

At no point does a client's raw observation leave its ALFA-C capsule. What rises is a statistical summary — counts, distributions, never the raw data. The grafting of a client into an MSP does not give the MSP access to another client's data.

4.1 NATS as the communication backbone

NATS is the message bus that connects all ALFA instances together — and only ALFA instances use it for their internal communication. This is a deliberate choice: NATS is lightweight (a few MB of RAM), fast (sub-millisecond latency on localhost), and above all, its hierarchical subject system (alfa.root.health, alfa.msp.1.alert, alfa.client.42.reflex) naturally maps ALFA's fractal tree.

4.2 Message protocol

All ALFA messages on NATS follow a common envelope:

The envelope is standardized. The payload is specific to the message type. This standardization allows any ALFA instance to route, log, or audit any message without having to understand its content — only the envelope is inspected for routing.

4.3 Compartmentalization via NATS ACL

The access matrix is strictly asymmetric: a level can only listen to its subordinates and speak to its superior. A client cannot query another client. An MSP cannot query a client's memory — it receives only the alerts and telemetry that the client chooses to publish.

5.1 Test methodology

The ALFA sealing test was conducted on 23 July 2026 on the 08.ma infrastructure, with two simulated instances: ALFA-M (port 5102) and ALFA-C1 (port 5103). The objective was to verify that ALFA-C1 can under no circumstances access the data of a hypothetical ALFA-C2, nor ALFA-M's own data.

The test protocol comprises five breach attempts:

5.2 Results

5/5 — sealing verified. No data leakage between ALFA capsules.

5.3 Performance metrics

The overhead of isolation is measurable but negligible: RLS verification adds less than 0.3 ms per PostgreSQL query, and NATS ACL validation is performed once per connection. Fractality is not a cost — it is a structural property that emerges from the shared code.