← Skillful-Alhazen

The Multi-Database Model

The Multi-Database Model

Skillful Alhazen is not one application — it is a family of applications that share one engine. The same agent, the same TypeDB server, and the same Next.js dashboard host several independent knowledge products at once. What keeps them separate is the database: each application curates its knowledge into its own TypeDB database, and you switch between applications by switching the database the dashboard reads.

This page explains that model. It is the organizing idea behind everything else in these docs.

One engine, many databases

A single TypeDB server (localhost:1729) holds many databases side by side. Each application family loads its skills’ schema namespaces into its own database and writes only there. Nothing bleeds across a database boundary — an application’s data, and the dashboards that read it, are scoped to one database.

Application Skills repo TypeDB database What it curates
Core (Skillful Alhazen) alhazen-skill-examples alh_core / alhazen_notebook The notebook itself — memory, operator profile, schema, web search, skill-building
Deep Research alhazen-skill-deep-research alh_deep_research Literature corpora, technology investigations, hypothesis trends
Personal Assistant alhazen-skill-personal-assistant alh_personal The executive team — career, research analyst, advisors, scribe, ops, chief of staff, health coach
Mythras GM mythras-gm alh_mythras Persistent tabletop RPG campaigns

Each row is a self-contained product. You can install one family without the others; the database it needs is provisioned on first use, and its dashboards appear only when that database is present.

Why separate databases instead of one big notebook

Early Skillful Alhazen put everything into a single alhazen_notebook database. That works while every skill is part of the same research notebook, but it stops working once the skills serve different owners and different jobs:

  • Isolation. Your health metrics, your board decisions, and a public literature corpus have no business sharing a namespace or a blast radius. A destructive reset of one application must not touch another.
  • Portability. An application is git clone + its database. You can back up, move, or hand off alh_personal without dragging along a rare-disease knowledge graph.
  • Schema clarity. Each database loads only the namespaces its application uses, so its schema is exactly the domain model for that product — nothing more to reason about.
  • A clean switch. Because the boundary is the database, “which application am I in?” has one answer: the database currently selected. The dashboard turns that into a literal switch (below).

The trade-off is that cross-application links are soft references, not TypeDB relations. For example, the Research Analyst lives in alh_personal but commissions the Tech Recon engine in alh_deep_research; it records the investigation’s id as an external_ref string rather than a graph edge across the database boundary. Within an application, everything is a first-class relation; across applications, you cross by reference.

Namespaces within a database

Databases separate applications; namespaces separate skills within an application. Every skill owns a short type-name prefix, and a database holds the union of its application’s namespaces:

Application / database Namespaces (skill prefixes)
Core — alh_core nbmem- (agentic memory), aos- (agent-os), dm- (curation-skill-builder)
Deep Research — alh_deep_research scilit- (scientific literature), trec- (tech recon), dm- (dismech notebook)
Personal Assistant — alh_personal career-, anlst-, advsr-, scribe-, ops-, coach-, plus the shared alh-person
Mythras GM — alh_mythras myth-

Skills in the same application can share entities on purpose. In the personal assistant, Ops and Career both use the shared alh-person entity so a stakeholder and a collaborator are the same person, not two records — and Chief of Staff reads across all of them. That kind of sharing is exactly why they live in one database.

See Skill Architecture for how a skill’s namespace is defined and loaded, and the Schema Reference for the base types every namespace extends.

The switch: how you move between applications

The dashboard is a single Next.js app with a database switcher in its hub. Selecting a database is how you select an application:

  1. The hub calls typedb-notebook scan-databases, which lists every database on the server and, for each one, probes whether each skill’s representative entity type exists there — reporting data (rows present), schema (type defined, empty), or absent (type not defined).
  2. When you pick a database, the hub shows only the dashboards valid for it and hides the rest. Select alh_personal and you see Career, Analyst, Advisor, Scribe, Ops, Chief of Staff, and Coach; select alh_deep_research and you see Scientific Literature, Tech Recon, and DisMech Notebook instead.
  3. Every dashboard page you open then reads from the selected database, so the whole UI is scoped to one application at a time.

The result is that the multi-database model isn’t a backend detail you have to hold in your head — it is the top-level navigation. Choosing what you want to work on and choosing which database to read are the same action.

Where to go next