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 RewriteRules 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 NotebookOutputs, 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 ComputeJobs — 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 StreamingOperations (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 ProofConjectures; 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; DerivationSteps 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.