Skip to content
B
All projects
Research engineeringMachine Learning / Research Engineer Aug 1, 2024

Pattern Miner & ECAN — research engineering at SingularityNET

Built components of a Pattern Miner system for AGI research and contributed to ECAN (Economic Attention Allocation) mechanisms at SingularityNET.

Domain
AGI research
Codebase
OpenCog / Hyperon
Org
SingularityNET
Tenure
1y+

Stack

PythonC++OpenCogSchemePyTorchLinux

Context

SingularityNET is one of the longest-running labs working on AGI from a non-deep-learning angle. The core idea isn't "scale a transformer until it generalizes"; it's a graph-based knowledge representation (the AtomSpace), a reasoning layer on top, and economic attention mechanisms that decide what the system thinks about next.

I worked across two areas:

  1. Pattern Miner — finding meaningful sub-graphs in the AtomSpace
  2. ECAN (Economic Attention Allocation) — how the system distributes a limited "attention" resource across concepts over time

This case study explains what those mean in plain terms and what I actually built.

What is the Pattern Miner

The AtomSpace stores knowledge as a hypergraph: nodes are concepts, links are relationships, both can be nested. A "pattern" is a small sub-graph that appears unusually often. Find enough of them and you have something like the system's vocabulary of recurring ideas.

The hard parts are:

  • The graph is huge and changes constantly
  • Naive enumeration is exponential
  • "Unusually often" needs a probability model that doesn't itself blow up

My contributions were in the candidate generation and scoring layers — making the miner explore the right neighborhood instead of the entire graph, and rejecting patterns that were statistically uninteresting before paying their evaluation cost.

What is ECAN

ECAN treats attention as a budget. Each atom in the graph has two values:

  • STI (Short-Term Importance) — does the system care about this now?
  • LTI (Long-Term Importance) — has this been useful historically?

A small "central bank" redistributes these over time based on how atoms are being used. Concepts that are forming useful patterns get more attention; stale ones decay.

I worked on diffusion (how STI moves between connected atoms) and forgetting (the boring but critical other half — bounded memory is non-negotiable in a long-running system).

What I actually shipped

Pattern Miner

  • Tightened the candidate filter so the miner skips obviously non-promising sub-graphs early
  • Added statistical pre-screening to avoid running expensive frequency counts on patterns that couldn't pass the threshold
  • Wrote tests against curated knowledge fragments so future changes have a measurable signal

ECAN

  • Profiled and reduced the per-cycle cost of attention diffusion
  • Added convergence checks so the simulation could be stopped meaningfully instead of running forever
  • Documented the actual parameter ranges that produced stable systems (the prior docs trailed reality)

Research engineering vs research

I am not claiming to be a theorist. My contribution was making the existing ideas runnable, profilable, and testable — the unglamorous half of any research codebase.

How this is relevant outside AGI work

Pattern mining and attention allocation are not weird academic toys. The same shapes show up in:

  • Recommendation systems (which items deserve attention this session?)
  • Anomaly detection (which sub-graphs occur unusually often?)
  • Agent memory (what should an LLM agent keep in its working context?)

A lot of the work I do today on LLM agents — RAG selection, context budgets, scoring — uses the same instincts.

What I would do differently

  • Add a clear benchmarking story earlier: research code without numbers becomes uncomparable across branches very quickly
  • Spend more time wrapping the C++ core with a friendly Python surface for experimentation — the ergonomic gap costs real research hours

Stack at a glance

  • Core: OpenCog / Hyperon (C++ + Scheme + Python bindings)
  • ML experimentation: Python, PyTorch
  • Profiling: Linux perf, cProfile, custom instrumentation
  • Ops: Linux, git-based research workflow

Why this matters on a portfolio

Recruiters look at this and see two things: ability to operate inside a complex research codebase, and willingness to ship the boring infrastructure that makes other people's ideas testable. Both translate directly to senior engineering roles.

Next case study

rateeat.app — full-stack restaurant rating platform

Built and deployed rateeat.app from scratch — Vue front end, Express + MongoDB API, Dockerized on AWS with Terraform-defined infra and GitHub Actions CI/CD.