# Kalika Domain - Features

> Mathematics, theoretical physics, materials science, and scientific research
> platform (`apps/kalika/*`, `libs/kalika/*`; TODO Phases 99-131)

Kalika is the scientific research platform paired with Oshun. It provides the
computational kernels, notebooks, agents, and reproducible-compute machinery for
symbolic mathematics, theoretical physics, and materials science. Kalika owns
the scientific _kernels and workflows_; the domains that consume its outputs —
Saraswati (technology), Brigid (industrial), Cybele (built environment), Airmid
(botanical), Demeter (agriculture), Maat (planning) — keep their own product
responsibilities and do not own the kernels.

The document is organized in two parts. The first specifies the **implemented
surface** — the Computer Algebra Engine, Research Notebooks, the Compute
Service, Research Agents, and the six application services — at the depth of a
feature spec. The second groups the **mathematics, physics, and materials
science capability libraries** into thematic sections, noting which programs
within them remain planned (TODO Phases 99-131). A closing **Scientific
Reproducibility** section states the cross-cutting correctness and provenance
contract.

## Implemented Surface

### Computer Algebra Engine (`@kalika/cas-engine`)

The CAS engine is a Rust symbolic-manipulation kernel — built as a Cargo
workspace, with both a `napi-rs` native Node binding and a `wasm-bindgen`
WebAssembly build — and is the foundation every mathematics and physics library
builds on. The symbolic algebra it operates on is the `Expr` type defined in the
TypeScript foundation `@kalika/core`: a discriminated union over a `kind` field
whose `EXPR_KINDS` tuple enumerates 20 node kinds (`IntegerLiteral`,
`RationalLiteral`, `RealLiteral`, `ComplexLiteral`, `Symbol`, `FunctionApp`,
`BinaryOp`, `UnaryOp`, `Derivative`, `Integral`, `Sum`, `Product`, `Limit`,
`Matrix`, `Tensor`, `Set`, `Piecewise`, `Equation`, `Proof`, `Undefined`). All
expression fields are `readonly`; expressions are immutable values.

The following capabilities are provided by the CAS engine:

- **Symbolic AST** — expressions are represented as a typed abstract syntax tree
  over the 20 `Expr` node kinds. The tree is the canonical in-memory form, and
  `@kalika/core` round-trips it to portable encodings (native JSON, OpenMath,
  Content MathML, SMT-LIB, TPTP, SCSCP).
- **Simplification** — algebraic simplification, normal-form reduction, and
  canonicalization, so structurally equal expressions compare equal; an e-graph
  (equality-saturation) data structure and structural hash-consing back this.
- **Substitution** — replacement of symbols or sub-expressions by other
  expressions, with consistent re-simplification of the result.
- **Pattern matching** — structural matching of `ExprPattern` templates against
  the AST, the basis for `RewriteRule`s and transformation libraries; each
  rewrite records its provenance (`axiom`, `theorem`, `definition`, or
  `heuristic`).
- **Assumptions** — per-symbol `SymbolAssumptions` (domain assumptions such as
  real, positive, integer; algebraic properties; finiteness) recorded on the
  expression and consulted by simplification so that domain-dependent rewrites
  are only applied when sound; assumption closure and conflict detection are
  computed by `analyzeSymbolAssumptions`.
- **Arbitrary-precision arithmetic** — an exact arithmetic path
  (arbitrary-precision integers, rationals, modular arithmetic, p-adics,
  algebraic numbers, and interval "ball" arithmetic) distinct from floating
  point, so symbolic results are not corrupted by rounding.
- **Rust kernel** — the performance-critical AST manipulation runs in Rust,
  callable from the TypeScript layer through the native binding or the WASM
  build.

The Rust kernel provides differentiation, transcendental and algebraic-extension
integration (Risch, Rubi, heuristic), Gruntz limits, series expansion, symbolic
summation (Gosper, Zeilberger, creative telescoping), polynomial algebra, and
ODE/PDE classification and solving. It ships with property tests, golden
fixtures, regression suites, and Criterion benchmark checks (see Scientific
Reproducibility).

### Research Notebooks (`@kalika/notebooks`, `apps/kalika/svc-notebooks`)

A `NotebookDocument` holds a title, metadata, and an ordered list of cells. Each
`NotebookCell` has an `id`, a `type`, a `content` string source, an `execution`
record, and a list of `outputs`. The key engineering choice is that notebooks
are reactive: a cell that consumes a result defined by another cell is
automatically re-evaluated when its dependency changes, keeping the visible
document consistent with the latest inputs.

- **Cell types** — `NOTEBOOK_CELL_TYPES` (5): `code` (executable code),
  `markdown` (prose), `latex-math` (mathematical notation), `visualization`
  (rendered plots and figures), and `prose`.
- **Execution states** — every cell's `execution.status` is one of
  `NOTEBOOK_EXECUTION_STATUSES` (4): `idle`, `running`, `completed`, or
  `errored` — an `errored` execution must carry an `error` payload. The status
  is the unit of progress reporting in the workbench.
- **Outputs** — a cell carries a list of `NotebookOutput`s, one of 8 output
  types (`text`, `latex`, `html`, `svg`, `image`, `data-table`,
  `interactive-widget`, `custom`), each with a fixed MIME contract.
- **Dependency graph** — cells form a dependency graph: a cell that consumes a
  symbol or result defined upstream is re-evaluated when its dependency changes.
  The reactive engine plans a topological execution order that can differ from
  document order.
- **Reproducibility** — notebooks capture random seeds, the execution
  environment, and dependency locks, and support reproducible export bundles.
- **Publishing and interop** — notebooks export to native JSON, HTML, LaTeX,
  PDF, `.ipynb`, plain text, and the `kalika` format, and interoperate with
  Jupyter, Mathematica, and Pluto notebooks.

The notebook document model and reactive execution engine live in
`@kalika/notebooks`; the notebook text file extension is `.kalika-nb`.

### Compute Service (`@kalika/numerical-engine`, `apps/kalika/svc-compute`)

The compute service runs scientific workloads as `ComputeJob`s — a discriminated
union over a `kind` field. Jobs may be submitted synchronously for small
requests or queued for longer work. The four job kinds are: `symbolic` (a
symbolic operation), `evaluate` (numeric evaluation), `matrix` (a matrix
operation), and `tensor` (a tensor operation). Synchronous routes run a job or a
`BatchRequest` of jobs inline; longer work is submitted to the compute queue.

- **Symbolic, matrix, and tensor operations** — `SymbolicOperation` (6):
  `simplify`, `differentiate`, `integrate`, `solve`, `series`, `limit`;
  `MatrixOperation` (7): `add`, `subtract`, `multiply`, `transpose`,
  `determinant`, `inverse`, `trace`; `TensorOperation` (2): `einsum`, `shape`.
- **Compute queue** — a BullMQ-backed queue, in-memory by default and Redis when
  configured. A `QueuedComputeTask` is a discriminated union over `kind`:
  `compute` (a `ComputeJob`), `ibp_reduction` (integration-by-parts reduction of
  Feynman integrals), or `lattice_monte_carlo` (a 2-D Ising-style Monte Carlo
  sweep). Queue priorities are `interactive`, `batch`, `background`; a queued
  job's status is one of `queued`, `running`, `completed`, `failed`,
  `cancelled`, `timed_out`.
- **Caching** — identical tasks share a content-hashed `cacheKey`, so an
  identical re-submission can be served from cache; this is the operational
  basis of reproducible compute results.
- **Streaming computations** — a streaming WebSocket runs `StreamingOperation`s
  (`groebner_basis`, `large_simplification`, `numerical_simulation`) with
  progress events and cancellation.

Every compute result is a `ComputeResponse<T>` carrying `ComputeMetadata` — the
operation, engine, duration, and a `verificationStatus` (`proven`, `numerical`,
or `conjectured`).

### Research Agents (`@kalika/research-agents`, `apps/kalika/svc-agents`)

The agent service runs autonomous research assistants over the CAS engine,
notebooks, and compute service. Rather than hard-coding a single research
strategy, the agent substrate decomposes a `ResearchGoalSpecification` into a
typed plan of steps (`scope`, `compute`, `literature`, `verify`, `reflect`,
`synthesize`, `custom`) and executes them, reflecting on progress between
iterations.

`@kalika/research-agents` provides a research agent base, a proof agent,
conjecture formulation, specialist agents, and a multi-agent orchestrator:

- **Conjecture generation** — agents propose candidate mathematical statements
  as `FormulatedConjecture` records, each with a `ConjectureRanking` (novelty,
  plausibility, significance, falsifiability) and a counterexample-search plan.
- **Literature search** — agents search and ingest scientific literature through
  arXiv, INSPIRE-HEP, OpenAlex, Semantic Scholar, and OEIS clients, writing
  papers, methods, and citations into the knowledge graph.
- **Proof attempts** — the proof agent attempts formal proofs of
  `ProofConjecture`s; its `ProofAgentStatus` is one of `proved`, `disproved`,
  `inconclusive`, or `not-run`, and it records which `ProofAgentMethod` produced
  the outcome (`decision-procedure`, `smt`, `atp`, `lean-proof-search`,
  `lean-tactic`, or `computation`). Verification draws on
  `@kalika/formal-verification` (see Scientific Reproducibility).
- **Workflow planning and explanation** — agents plan multi-step research
  workflows (a `ResearchAgentRun` over a typed plan) and produce explanations of
  computed results.

Kalika owns the scientific domain semantics — what a conjecture, proof, or
campaign _means_. Reusable agentic-scientist orchestration and evaluation
primitives are consumed from the Nous autonomous-research substrate (Phase 178):
literature graphs, novelty scoring, search and reasoning kernels,
FunSearch/AlphaEvolve-style discovery, reproducibility bundles, and lab-driver
integration. Kalika keeps the math, physics, materials, and physical-lab
workflows; Nous keeps the generic agent machinery.

### Application Services (`apps/kalika/*`)

Six applications compose the platform, handling different surfaces and concerns:

- **`apps/kalika/bff`** — the Fastify backend-for-frontend; composes the
  downstream services for the web workbench.
- **`apps/kalika/web`** — the React research workbench web application: reactive
  notebooks, math input, and visualization.
- **`apps/kalika/cli`** — the `kalika` command-line tool, running over the
  `@kalika/sdk` WASM CAS (`eval`, `simplify`, `solve`, `notebook run`,
  `training-data`).
- **`apps/kalika/svc-agents`** — hosts the Research Agents described above.
- **`apps/kalika/svc-compute`** — hosts the Compute Service described above.
- **`apps/kalika/svc-notebooks`** — hosts the notebook execution and storage
  service.

The foundation libraries are `@kalika/core` (the symbolic expression algebra,
provenance model, rewrite machinery, and serialization formats) and
`@kalika/utils` (physical dimensions, quantities, and codified constants); every
other library depends on `@kalika/core`. An embeddable `@kalika/sdk` (with a
separate `@kalika/sdk-python`) wraps a WASM-local CAS for use in external
applications.

### Research Workbench UX

The web workbench is the human surface of the platform, where researchers
interact with notebooks, submit computations, explore the knowledge graph, and
collaborate with other users.

- **Reactive notebooks** — editing a cell re-evaluates downstream dependents
  along the dependency graph, so the visible document stays consistent with the
  latest inputs.
- **Math input** — direct mathematical-notation entry feeding the CAS engine,
  rendered through the typesetting layer; the design target is zero-latency
  entry so notation keeps pace with typing.
- **Spatial canvas** — a non-linear workspace for arranging expressions,
  figures, and notes alongside the linear notebook.
- **Visualization and animation** — dynamic plots and animations driven by
  computed results.
- **Collaboration and publishing** — multi-user notebook collaboration and
  publication of notebooks as research outputs.
- **Accessibility** — the workbench meets accessibility requirements for the
  research UI.

## Capability Libraries

Beyond the foundation, `libs/kalika/` carries an extensive set of mathematics,
physics, and materials libraries — real, substantive TypeScript packages (most
carry 5-40 source modules), with implementation depth varying by package. Each
extends the `@kalika/core` symbolic AST with domain objects and adds
domain-specific rewrite rules, algorithms, and tests. They are grouped
thematically below; numerical results they produce are governed by the
Scientific Reproducibility contract. Where a specific solver or program within a
theme is not yet built, it is labelled `(planned)`; the broader materials and
autonomous-experimentation programs (TODO Phases 116-131) are largely planned
and called out in their own sections.

### Pure Mathematics

Pure mathematics libraries cover the major branches of modern mathematics. Each
extends the symbolic AST with domain-specific objects (groups, manifolds,
categories, etc.) and the simplification machinery with domain-specific rewrite
rules.

Abstract algebra (groups, rings, fields, modules) and linear algebra; real and
complex analysis; number theory; topology, including 3-manifold topology;
category theory and higher categories; combinatorics and algebraic
combinatorics; probability and stochastic processes; measure theory;
optimization, automatic differentiation, and approximation theory; mathematical
logic. Advanced geometry libraries cover algebraic geometry, geometric analysis,
symplectic topology, noncommutative geometry, vertex algebras, and quantum
groups.

### Theoretical Physics

Theoretical physics libraries cover the major frameworks of modern physics, from
quantum mechanics and field theory through general relativity and cosmology.

Quantum mechanics (states, operators, Hilbert spaces, perturbation theory);
quantum field theory (fields, path integrals, Feynman tooling); general
relativity (tensors, metrics, geodesics, curvature); statistical mechanics
(ensembles); Lie theory; string theory; condensed matter; cosmology; particle
phenomenology; quantum gravity and gravitational waves; lattice field theory;
information theory. Capstone physics libraries cover non-perturbative QFT,
supersymmetry, integrable systems, spectral geometry, open quantum systems,
quantum chaos and optics, non-equilibrium statistical mechanics, topological
quantum computing, post-Minkowskian dynamics, neutrino physics, Big Bang
nucleosynthesis, and entanglement measures.

### Classical and Continuum Physics

Classical and continuum physics libraries cover the branches of physics that
admit deterministic or thermodynamic macroscopic descriptions, and which are the
computational substrate for Kalika's materials and engineering consumers.

Classical mechanics, electrodynamics, fluid dynamics, thermodynamics, optics,
plasma physics, astrophysics, nonlinear dynamics, and atomic and molecular
physics. Theoretical astrophysics and mathematical-physics tooling live here;
observatory and astronomy calculations belong to Nyx, not Kalika.

### Computational Engine

Numerical and compute libraries sit on top of the Rust `numerical-engine` and
`cas-engine` crates, bridging their compiled performance to the TypeScript
orchestration layer.

Packages include `@kalika/numerical`, `@kalika/autodiff` and
`@kalika/autodiff-core`, `@kalika/hpc-orchestrator`, `@kalika/sdp-core`
(semidefinite programming), `@kalika/surrogate`, and `@kalika/tensor-networks`.
Ordinary- and partial-differential-equation solvers, Monte Carlo methods, GPU
acceleration, and special-function numerics are `(planned)` extensions of the
`numerical-engine` foundation.

### Formal Verification and AI Research

Formal verification and AI research libraries connect the symbolic kernel to
automated theorem-proving systems and machine-learning research tools.

A Lean bridge and theorem-proving machinery for formal verification; conjecture
generation; FunSearch-class symbolic search; symbolic regression;
physics-informed neural networks; literature ingestion. Frontier-method
libraries cover tropical and positive geometry, motivic amplitudes, resurgence
and trans-series, the conformal bootstrap, applied category theory,
differentiable physics, quantum simulation, ML for algebraic geometry, and
topological data analysis for physics.

ML sovereignty for mathematics (Phase 108) lives in the training-data library:
curated scientific corpora; math-specialized embedding training with LaTeX-aware
preprocessing and Lean proof-state premise retrieval; custom math-model training
pipelines (tokenizer extension, continued pretraining, instruction tuning,
mathematical constitutional AI, math-domain reward models, RLVF, CAS-in-the-loop
and tool-use fine-tuning); a verified-computation data flywheel with flywheel
metrics, targeted synthetic data, weekly model refresh, and model A/B testing;
and an intent-based serving router that escalates from direct CAS evaluation
through small and large math models to Lean proof search. Nous owns the generic
model-serving and training machinery; Kalika owns the mathematical data, reward
semantics, and routing policy.

### Research Platform Libraries

Research platform libraries provide the output surface — they turn computed
results into human-readable, citable, and reproducible research artifacts.

Notebooks, the renderer, LaTeX/typesetting, the knowledge graph, and citations
provide the research-output surface: rendered mathematics, figures, cited
literature, and the knowledge graph of mathematical objects, papers, methods,
hypotheses, and materials facts. Interoperability libraries handle physics data
formats, formal-proof imports, cross-CAS bridges, computation verification,
notebook interoperability, citation formats, and visualization exports.

### Materials Science (Phases 116-131)

Electronic structure is built — `@kalika/electronic-structure` (Kohn-Sham DFT),
`@kalika/xc-functionals`, and `@kalika/wannier`. The broader materials layer is
a large `(planned)` program covering the electronic, atomic, and continuum
scales.

The built electronic structure package implements Kohn-Sham density functional
theory (DFT) with a plane-wave basis, pseudopotentials, an SCF solver,
exchange-correlation functionals, band structure, density of states, Wannier
functions, structural relaxation, and charge density.

The planned program is organized by physical scale and property:

- **Crystallography** (planned) — lattice and unit-cell models, space groups and
  symmetry operations, crystal structures, crystallographic file I/O, reciprocal
  space, diffraction, slabs, and interfaces.
- **Many-body methods** (planned) — GW, the Bethe-Salpeter equation, dynamical
  mean-field theory, quantum Monte Carlo, coupled cluster for solids,
  time-dependent DFT, and embedding methods.
- **Lattice dynamics** (planned) — phonons, density-functional perturbation
  theory, thermodynamic properties, anharmonicity, thermal transport,
  electron-phonon coupling, and Eliashberg theory.
- **Molecular dynamics** (planned) — classical and ab initio MD, force fields,
  enhanced sampling, free-energy methods, trajectory analysis, Green-Kubo and
  non-equilibrium MD, and coarse graining.
- **ML potentials and informatics** (planned) — descriptors, equivariant neural
  potentials, classical and pretrained universal potentials, active learning,
  crystal graph neural networks, generative materials models, and screening.
- **Defects, surfaces, interfaces** (planned) — point defects, dislocations,
  grain boundaries, stacking faults, surfaces, adsorption, catalysis, and
  transition states.
- **Properties** (planned) — Boltzmann transport, thermoelectrics, dielectric
  and optical response, magnetism and spintronics, topological materials,
  piezo/ferroelectrics, and elastic and mechanical properties.
- **Spectroscopy** (planned) — XAS/XANES/EXAFS, photoemission, vibrational
  spectroscopy, NMR, Mossbauer, and EELS, with processing, comparison, and
  visualization.
- **Thermodynamics and phase diagrams** (planned) — CALPHAD-style Gibbs-energy
  models, phase equilibria, thermodynamic databases, cluster expansion, ab
  initio thermodynamics, diffusion modeling, nucleation, and solidification.
- **Functional materials** (planned) — battery materials, photovoltaics,
  thermoelectrics, catalysis, 2D materials, metal-organic frameworks, polymers,
  high-entropy alloys, metamaterials, nuclear materials, and corrosion and
  degradation.
- **Code interoperability** (planned) — interfaces to VASP, Quantum ESPRESSO,
  ABINIT, FHI-aims, LAMMPS, GROMACS, Phonopy/Phono3py, WANNIER90, LOBSTER,
  BoltzTraP2, and ASE/pymatgen compatibility, plus materials databases and
  workflow engines.
- **Multiscale engineering** (planned) — phase-field models, crystal plasticity,
  dislocation dynamics, damage/fracture/fatigue/creep modeling, process
  simulation, manufacturing digital twins, and uncertainty quantification.
- **Materials research platform** (planned, Phase 128) — interactive
  crystal-structure visualization, materials property dashboards, autonomous
  materials-discovery agents that plan screening campaigns over the layers
  above, and a collaborative materials workbench that extends the
  notebook/collaboration surface with materials-specific views.

### Autonomous Experimentation (Phase 130)

Autonomous experimentation closes the loop between computation and physical
laboratory work. The planned design makes an `ExperimentCampaign` the unit of
physical-lab work, with campaign changes emitting an `ExperimentCampaignUpdated`
event.

Planned closed-loop discovery capabilities include: experiment orchestration,
design of experiments, active campaign planning, robotic protocols, sample
operations, instrument control, and facility/beamline orchestration. Lab safety,
standard operating procedures, and human-governance checkpoints gate autonomous
experiment execution; experimental knowledge is captured back into the knowledge
graph.

This capability consumes Nous lab-driver and Coscientist/A-Lab/ChemCrow
integration patterns while keeping the scientific campaign semantics in Kalika.
The boundary exists because Kalika owns the domain model of what an experiment
_means_ (the campaign, the hypothesis, the safety constraints), while Nous owns
the generic machinery for driving robotic instruments.

## Scientific Reproducibility

Reproducibility is a cross-cutting correctness contract, enforced on every
numerical result, proof, compute job, and materials workflow. A bare number with
no units, tolerance, or method metadata is not an acceptable result.

- **Units and tolerances** — a numerical result must carry its units, tolerance,
  precision, computation method, and input assumptions wherever those apply.
  _Acceptance criterion:_ a result missing units, tolerance, or method metadata
  is rejected by the result schema.
- **Proof status** — a computed value carried in a `ProvenResult` declares a
  `confidenceLevel` (`proven`, `conjectured`, `numerical`, or
  `verified-by-independent-cas`) and a `verificationStatus` (`unverified`,
  `lean4-verified`, `coq-verified`, `smt-verified`, `atp-verified`,
  `numerical-spot-check`, or `cross-cas-verified`); the proof agent reports a
  `ProofAgentStatus` of `proved`, `disproved`, `inconclusive`, or `not-run`.
  Status invariants are enforced — a formal verification status requires the
  `proven` confidence level. _Acceptance criterion:_ no proof output is
  published without a status; a numerical or heuristic result is never presented
  as a formal proof.
- **Environment capture** — notebooks record random seeds, the execution
  environment, system architecture, and dependency locks under
  `kalika.reproducibility` and `kalika.environment` metadata, and support
  reproducible export bundles. Queued compute tasks content-hash into a
  `cacheKey`, so an identical re-submission yields an identical, cache-served
  result. _Acceptance criterion:_ a reproducible notebook captures its seeds,
  environment, and dependency locks; an identical compute task is served from
  cache.
- **Verifiable provenance** — `ProvenResult<T>` attaches a derivation chain, the
  assumptions used, a confidence level, and a verification status to a computed
  value; `DerivationStep`s record the rule, inputs, outputs, and justification
  of each step. _Acceptance criterion:_ a non-trivial result traces back through
  its derivation chain to the rules and assumptions that produced it.
- **Materials provenance** — materials and experimental workflows preserve
  provenance, the versions of any external code or interface used, sample
  lineage, and validation evidence _(planned, alongside the materials program)_.
- **Kernel verification** — scientific kernels are tested with property tests,
  golden fixtures, numerical-tolerance tests, benchmark checks, and
  reproducibility tests. Every scientific algorithm states its assumptions,
  units, tolerances, and supported domains.
- **Reproducible compute operations** _(planned, Phase 131)_ — beyond per-result
  provenance: license-aware scheduling for jobs that use license-limited
  external codes, full workflow replay (re-executing a recorded workflow from
  its captured environment and inputs and verifying the outputs match), and
  cross-site research governance so campaigns spanning multiple compute sites or
  labs carry consistent policy, audit, and data-sharing rules.

## APIs, Events, and Persistence

### API surface

The BFF exposes the workbench surface under `/api/v1`; the three back-end
services each expose their own `/api/v1` HTTP and WebSocket routes. All routes
use a `{ ok, result | error }` response envelope.

- **Compute APIs** — symbolic, evaluate, matrix, tensor, and batch operations on
  `Expr` values; the compute queue (submit, fetch, cancel, stats); a browser
  WASM manifest; and `ws/compute` / `ws/stream` WebSockets.
- **Notebook APIs** — notebook and cell CRUD, single-cell and whole-notebook
  execution, templates, execution jobs, multi-user collaboration (edits, CRDT
  updates, presence, locks), export, and file-sync.
- **Agent APIs** — managed-agent lifecycle (create, run, pause, resume,
  terminate, cost-estimate, usage) and research tasks (create, fetch,
  intermediate results, feedback, report).
- **SDK / CLI surface** — the embeddable `@kalika/sdk` exposes a WASM-local CAS
  (symbolic, evaluate, matrix, tensor, physics utilities); the `kalika` CLI runs
  over it.

### Events

Kalika's implemented eventing is in-process and WebSocket/SSE, not a
cross-domain message bus. The following events are live today:

- **`ComputationResultEvent`** (`@kalika/core`) — emitted on an in-process event
  bus for completed computations, with kinds `cas-computation`,
  `formal-verification`, `physics-calculation`, `verified-computation`,
  `custom-computation`.
- **BFF realtime events** — `compute.queue.submitted`,
  `compute.queue.cancelled`, `notebook.cell.execution.queued`,
  `notebook.execution.queued`, `agent.run.started`,
  `agent.research-task.created`, fanned to per-user WebSocket channels.
- **Compute streaming events** — `stream.started`, `stream.progress`,
  `stream.partial`, `stream.completed`, `stream.cancelled`, `stream.error`.
- **Notebook file-sync events** — `bound`, `saved`, `external-change`, `error`,
  `unbound`, `snapshot`, over an SSE stream.
- **Agent lifecycle events** — `created`, `run_started`, `run_completed`,
  `paused`, `resumed`, `terminated`, recorded on each managed-agent record.

A domain-level event surface published to the shared event bus
(`ExpressionEvaluated`, `NotebookCellExecuted`, `ComputeJobSubmitted`,
`ComputeJobCompleted`, `ProofAttemptCompleted`, `ArtifactRegistered`,
`ResearchFindingPublished`, `ExperimentCampaignUpdated`) is _(planned)_.

### Persistence and artifacts

The implemented services use in-memory stores by default — BFF sessions, the
notebook-service repository (hydrated on startup), and the agent-service store.
The compute queue persists either in memory or, when configured, in Redis
(BullMQ). A durable PostgreSQL store for projects, notebooks, job records,
citations, and collaboration state, and an object/artifact store for datasets,
environment bundles, rendered media, and provenance records, are the _(planned)_
persistence layer.

## Cross-Domain Integrations

Understanding where each capability lives — and why — prevents redundant
implementations and keeps cross-domain contracts explicit.

- **Sophia** supplies knowledge-retrieval and graph infrastructure patterns;
  Sophia owns general knowledge management and RAG for the broader ecosystem,
  while Kalika owns the scientific knowledge graph. The boundary exists because
  general knowledge retrieval (RAG over arbitrary documents) is Sophia's
  problem, while the structured graph of mathematical objects, proofs, and
  physical constants is Kalika's.
- **Nous** supplies model serving and training infrastructure and the
  autonomous-research substrate; Nous owns generic AI model infrastructure. The
  boundary exists because Nous provides the reusable machinery (agent loops,
  evaluation harnesses, FunSearch-style search) while Kalika supplies the
  scientific semantics (what constitutes a valid proof, what a DFT calculation
  means).
- **Iris** supplies assistant, agent, and conversational interfaces, which the
  Kalika workbench surface consumes.
- **Nyx** owns astronomy and observatory calculations; Kalika owns theoretical
  astrophysics and mathematical-physics tooling. The boundary is the telescope:
  theoretical calculations belong to Kalika, but anything that interfaces with a
  real instrument or sky survey belongs to Nyx.
- **Maat** consumes research operations and, where applicable,
  investment/capital planning outputs derived from Kalika scientific results.
- **Saraswati, Brigid, Cybele, Airmid, and Demeter** consume validated
  scientific and materials outputs for technology, manufacturing, construction,
  botanical, and agriculture workflows, exported through contracts, SDKs, or
  shared artifacts.