Research
Our research asks a narrow, stubborn question: how much useful capability can fit inside a small, selectively activated computational budget? Everything on this page is a hypothesis or a design direction unless it is explicitly marked as a measured result.
The objective
Make smaller, selectively activated AI systems competitive on useful workloads — the questions people actually ask — while running on hardware they already own.
Large models can require substantial memory, energy and specialised accelerators for inference. That cost shapes who gets to use AI, where data has to travel and how much control people keep. We think part of that cost is architectural, and architecture is something we can research.
Three ideas, three acronyms.
3CN Three Cell Node
A proposed three-cell structure for organising the conceptual nodes of a modular architecture.
Read moreMPN Modular Parameter Network
A selectively accessible, domain-organised parameter network that a shared core can draw on when a task needs it.
Read moreCNP Cell-Node Parameters
An exploratory scheme for how parameters are grouped inside cells and nodes so components can be added, replaced or removed.
Read moreOne core. Many modules. Only some awake.
Type a question and watch which conceptual modules the core would reach for. Select any node to inspect it.
The interactive architecture visualiser needs JavaScript. The domain modules it shows are: Mathematics, Statistics, Computer Science, History, Politics, Literature, Linguistics, Law, Music Theory, Architecture, Physics, Astronomy, Astrophysics, Chemistry, Biology, Medicine, Meteorology, Geology, Earth Science, Geography, Economics, Finance, Software Engineering, Machine Learning, Computer Networking, Computer Engineering, Computer Architecture, Mechanical Engineering, Electrical Engineering, Energy, Aerodynamics, Aerospace Engineering.
Relevant question → selected capability → everything else stays asleep.
- Solve a quadratic equation Mathematics
- Explain the Battle of Waterloo History
- Predict tomorrow's weather Meteorology
- Describe cellular respiration Biology
- Balance a chemical equation Chemistry
- Explain black holes Astronomy + Physics
- Debug a Python function Software Engineering
- Analyse a poem Literature + Linguistics
- Explain inflation Economics
- Translate a French sentence Linguistics
- Explain plate tectonics Geology
- Describe the human heart Biology + Medicine
- Calculate an integral Mathematics
- Explain TCP/IP Computer Networking
- Compare CPU architectures Computer Engineering
- Explain quantum entanglement Physics
- Analyse a historical treaty History + Politics
- Describe photosynthesis Biology
- Plan a database schema Software Engineering
- Explain how a turbine works Mechanical Engineering
- Identify a musical chord Music Theory
- Explain the water cycle Earth Science
- Calculate compound interest Mathematics + Finance
- Explain an orbital transfer Physics + Astronomy
- Discuss Roman architecture History + Architecture
- Explain neural networks Machine Learning
- Describe an electrical circuit Electrical Engineering
- Explain a volcano eruption Geology
- Analyse a Shakespeare passage Literature
- Explain supply and demand Economics
- Design a solar power system Electrical Engineering + Energy
- Explain aircraft lift Aerodynamics + Physics
- Summarise a legal contract Law + Linguistics
- Explain how vaccines work Biology + Medicine
- Calculate a rocket trajectory Mathematics + Aerospace Engineering
- Compare programming languages Software Engineering
- Analyse statistical data Statistics
- Explain how RAM works Computer Architecture
- Describe the formation of galaxies Astrophysics
- Diagnose an algorithmic complexity issue Computer Science + Mathematics
Proposed advantages of modularity
- Potentially reduced active computation — only selected modules participate in a forward pass.
- Smaller active parameter sets — the working set for a request can be a fraction of the total.
- Domain-specific extension — add knowledge by adding a module, not retraining everything.
- Hardware flexibility — choose which modules a device carries.
- Component replacement — improve one domain without disturbing the others.
- Quantisation opportunities — quantise rarely used modules more aggressively.
- Lower-cost local deployment — fit a useful configuration into a laptop’s memory.
- Resource-aware execution — respect a budget set by the user, not the model.
The hard parts
- Routing errors — if the router picks the wrong module, quality drops silently.
- Cross-domain reasoning — many real questions span domains; boundaries leak.
- Training complexity — modules must be trained to cooperate with one shared core.
- Module compatibility — replacing a module can break assumptions elsewhere.
- Memory movement overhead — loading modules on demand costs bandwidth and time.
- Quality degradation — removing capacity has a price that must be measured.
- Latency — routing and paging add steps to every request.
- Evaluation methodology — fair comparisons need matched tasks, hardware and budgets.
What fits in the memory you have?
An interactive, hypothetical memory-budget illustration (requires JavaScript).
In context
Frontier systems from OpenAI, Anthropic, Google DeepMind, Meta and others have shown what very large models can do, and mixture-of-experts designs already use sparse activation inside a single network. Our work sits alongside that research rather than in opposition to it. We are interested in a different trade-off: organising specialised knowledge into inspectable, removable modules around a small shared core, and asking how far that design can go on ordinary hardware.
We make no claim that Yaob matches or beats any frontier model. Comparisons will appear here only with published evidence.
Benchmarks
Research in progress — no results published.
Research in progress. When we have results, each one will be published with the model version, hardware configuration, accuracy measurements, inference speed, memory usage and enough methodological detail to reproduce it.