Empowering research innovation

Research automation, and what it is actually for

Most of a researcher’s time does not go into research. It goes into the surrounding work: finding the relevant prior art, re-deriving something to check it, wiring up an experiment, formatting the result. The interesting part — forming a hypothesis worth testing — is a thin slice of the calendar.

That is the gap the platform targets. Not replacing the researcher, but compressing everything around the judgement calls so the judgement calls get more of the day.

The architecture underneath

The foundation is SymbolicAI, which treats a language model as a semantic parser rather than an oracle. The model’s job is to turn something stated informally into a structured, executable representation; the surrounding machinery is responsible for deciding whether that representation is correct.

Everything is built from neuro-symbolic expressions — composable units that can be nested and chained, so a complicated behaviour is assembled from pieces that can each be inspected on their own rather than emerging from one long prompt.

The layering matters more than any single component:

Contracts, so that “plausible” is not the acceptance criterion

The hard problem in generative systems is not fluency, it is semantic correctness. Output that reads well and is wrong is worse than output that fails loudly.

So operations carry contracts: preconditions that must hold before an operation runs, postconditions that must hold after it, and a remedy path when a check fails. It is design-by-contract applied to a probabilistic component — the model is allowed to be uncertain, but the boundary around it is not.

Memory and retrieval as first-class parts

Reasoning over a body of literature needs somewhere to put what has been established. The stack includes vector-store memory for retrieving semantically relevant context, plus knowledge structures that let a claim be traced back to where it came from rather than being re-asserted from the model’s weights.

Putting it to work: a primality testing experiment

Architecture arguments are cheap, so we ran the platform at a real question — building a scientific case around primality testing and seeing how far the system could get on its own.

The work is organised as a graph of computational nodes: literature ingestion, hypothesis generation, verification, implementation, evaluation, with feedback loops between them. A node’s output becomes another node’s input, and evaluation is not a final step but a continuous one.

Running that loop, the system worked its way toward a characterisation connecting cyclotomic field theory to matrix algebra: for an integer n > 2, primality corresponds to the minimal polynomial of a particular circulant matrix having exactly two irreducible factors over the rationals. Evaluation nodes benchmarked the resulting test against established primality tests throughout, which is the part that makes the claim worth anything.

The output was not a suggestion, it was a draft with figures and experimental validation — eigenvalue distributions in the complex plane for a prime and a composite case, and the field extension structure that explains the factorisation pattern.

Limits, and why the human stays in the loop

Two honest caveats. First, novelty is relative: a result the system surfaces may be new to the operator and long known to a specialist, which is exactly why literature grounding and citation tracing are load-bearing rather than decorative. Second, the further the work gets from domains with crisp verification, the more the burden shifts back to human review.

The claim is not autonomous science. It is a shorter loop between a question and a checkable answer, across domains where that loop is currently measured in months.

The next step in research automation is not removing researchers from the process. It is giving them a system that can carry the mechanical weight and show its work when asked.