NOVAS

Most AI services hide their underlying infrastructure.

A question goes in. Somewhere in a large remote data centre, a model runs. An answer comes back.

NOVAS is being designed around a different architecture.

The intelligence layer and the compute layer are separated.

That means NOVAS does not have to assume that every task should be sent to the same model, the same GPU or even the same type of computer.

Instead:

understand → govern → select capability → route → execute → verify → remember

This is important to CEAC. A distributed network of community data centres becomes much more useful when there is an intelligence system capable of deciding how that distributed infrastructure should actually be used.

NOVAS is best understood as a collection of cooperating systems rather than one enormous model.

Language and reasoning models provide powerful capabilities inside NOVAS, but NOVAS is not defined by any one model.

Different models can be used for different jobs.

As model technology changes, models can be replaced without rebuilding the surrounding memory, governance, routing and infrastructure architecture.

The model provides intelligence. NOVAS provides the system around it.

That distinction allows the underlying compute to evolve independently of the application.

The same principle exists physically inside CEAC:

replace the compute sled — not the infrastructure.

For NOVAS:

replace the model — not the intelligence architecture.

NOVAS has a structured memory architecture.

Rather than treating every interaction as an isolated prompt, information can move through different memory horizons.

Memory can therefore be retrieved selectively rather than repeatedly sending an ever-growing conversation history through a model.

That matters for usability. It can also matter for compute.

Remember what is useful. Retrieve what is relevant. Avoid repeatedly processing everything.

Some problems already have exact computational answers.

• • Date calculations
• • Arithmetic
• • Structured lookups
• • Policy checks
• • Known factual records
• • Defined software functions

When NOVAS identifies work that can be resolved deterministically, that work can be sent to an appropriate tool or computational path instead of asking a large language model to approximate the answer.

This produces a simple design rule:

Use generative intelligence where reasoning is useful. Use deterministic computation where certainty is available.

It can improve correctness while avoiding unnecessary model inference.

NOVAS is designed to support multi-agent workflows through its Swarm architecture.

Instead of requiring one model invocation to perform every stage of a complex job, work can be decomposed into specialised activities.

One process may investigate. Another may calculate. Another may inspect evidence. Another may compare alternatives. Another may prepare the final result.

The objective is not to create more AI activity for its own sake. It is to organise computation around the structure of the problem.

Simple work should remain simple. Complex work can become coordinated work.

Before an action or execution path is allowed, NOVAS can apply governance controls through ADA.

Governance can determine whether an action is permitted, what authority is required and which boundaries apply before work proceeds.

This separates an important pair of questions:

Can the system do this?

from:

Should this system be allowed to do this?

That distinction becomes increasingly important as AI moves from answering questions to interacting with infrastructure, tools and real-world systems.

NOVAS is being developed around evidence-producing operation rather than invisible execution.

Its control-evidence architecture can retain information about significant decisions, actions and outcomes so they can be inspected and audited afterwards.

Smart Atom Router extends the same principle into the compute layer, where execution can return evidence describing the resource used and the resulting operation.

The objective is a traceable chain:

request → decision → authority → route → execution → result → evidence

Not every internal event needs to become a permanent record. The aim is useful evidence, not infinite logging.

Intelligence and compute are separate layers.

This is one of the fundamental ideas behind the Sparse architecture.

NOVAS does not need to know how to operate every individual processor, server or computing provider. Smart Atom Router provides that abstraction.

NOVAS can request a capability. Smart Atom Router determines which computing resources are:

• • capable,
• • permitted,
• • trusted,
• • available,
• • economically appropriate,
• • and suitable for the workload.

Only eligible resources enter the routing decision.

That resource might eventually be:

• • local CPU
• • local GPU
• • neuromorphic compute
• • another CEAC
• • a Smart Atom Retail hub
• • approved cloud infrastructure
• • an explicitly permitted specialist computing resource

NOVAS asks for the capability. Smart Atom Router finds the appropriate eligible compute.

CEAC gives NOVAS somewhere local to think.

CEAC is the physical community infrastructure layer.

A Generation-1 CEAC combines AI compute, storage, networking, protected power, cooling, monitoring and security inside a deployable community-scale data-centre node.

NOVAS can sit above that infrastructure.

For suitable workloads, a request could therefore remain close to the community that generated it.

A simple path might be:

1. Person or local service
2. NOVAS — understand the request, recover relevant memory, determine the required capability, apply governance
3. Smart Atom Router — create the eligible compute set, evaluate locality, availability and policy, select execution resource
4. Local CEAC — CPU · GPU · storage · specialist compute
5. Result + evidence — return the result, record appropriate execution evidence, update relevant context

If the local CEAC cannot perform the task, Smart Atom Router can select another permitted destination — eventually another CEAC, shared community infrastructure or approved remote compute.

A distributed system only works if it understands its limits. NOVAS and CEAC are therefore not based on the idea that every AI workload should execute locally.

Some work belongs at the edge. Some belongs elsewhere.

The infrastructure can therefore behave as a hierarchy:

local when appropriate → federated when useful → remote when necessary

Don't process what hasn't meaningfully changed.

NOVAS sits within a wider Sparse design philosophy.

Modern computing frequently responds to increasing demand by adding more computation. Sparse systems ask another question:

What computation can be avoided without materially reducing the quality of the result?

That principle can appear throughout the architecture.

• • Retrieve relevant memories instead of every memory.
• • Use deterministic computation instead of model inference when possible.
• • Detect meaningful events instead of continuously analysing unchanged sensor streams.
• • Use specialist low-power compute when a workload genuinely fits it.
• • Keep suitable data and processing local rather than automatically sending it through remote infrastructure.
• • Escalate to heavier compute when the problem requires it.

This is not simply about making individual processors more efficient. It is about reducing unnecessary computation across the system.

AI carbon impact is not determined by the model alone.

It is affected by:

• • how often computation occurs
• • which hardware executes it
• • where that hardware is located
• • how efficiently it performs the workload
• • the electricity supplying it
• • network movement
• • storage
• • cooling
• • the embodied impact of the infrastructure

CEAC provides a physical carbon-accounting layer.

Smart Atom Router can use operational energy and carbon information as part of the wider execution evidence and routing architecture.

NOVAS sits upstream of those decisions.

That creates the possibility of addressing carbon before unnecessary computation occurs.

The lowest-carbon computation can sometimes be the computation that never needed to happen.

NOVAS

The intelligence and orchestration layer — understands the objective, works with memory, coordinates capabilities, applies governance and manages the wider task.

ADA

The governance layer — controls authority and whether proposed actions are permitted.

SWARM

The multi-agent workflow layer — coordinates specialised agents and complex workflows where decomposition is useful.

Smart Atom Router

The secure execution and routing layer — determines which computing resources are permitted and best suited to execute a workload.

CEAC

The community infrastructure layer — provides local compute, storage, connectivity, power, cooling, monitoring and physical security.

Control evidence

The proof and audit layer — provides evidence around significant decisions and execution rather than relying entirely on opaque system behaviour.

One CEAC provides local infrastructure. Multiple CEACs create distributed capacity.

Smart Atom Router provides a way to address that capacity as a compute fabric. NOVAS provides an intelligence system capable of using it.

That changes the proposition. CEAC is not simply a small data centre.

The longer-term architecture is:

• distributed physical infrastructure
• distributed compute
• intelligent workload orchestration
• persistent local context
• governed execution
• measurable evidence

The result is a different way of thinking about AI infrastructure — not one enormous computer somewhere else, but a network of computing resources that can cooperate while retaining the ability to execute useful work close to the people, organisations and communities that need it.

1. People · applications · community services

2. NOVAS

   Intelligence · memory · reasoning · orchestration

3. ADA + Swarm

   Governance · authority · coordinated workflows

4. Smart Atom Router

   Eligibility · trust · execution placement · evidence

5. Distributed compute fabric

   CEAC · Smart Atom Retail · CPU · GPU · neuromorphic · approved cloud · specialist compute

6. Physical infrastructure

   Power · cooling · storage · network · security · energy

7. Measurement

   Execution · utilisation · energy · carbon · evidence