The Agentic Runtime
OpsDNA’s core engineering bet is that an “agentic CFO” cannot be a chat wrapper. LLM outputs are useful for interpreting questions and proposing structure, but everything that touches fund economics must flow through typed, validated, permission-gated, auditable machinery — because a CFO’s numbers have to be provable, not merely plausible. The repository README states the canonical runtime path directly:
Evidence Graph
+ Semantic / Computation Registry
+ Permission Engine
+ Typed Query Runtime
+ DomainPolicies as materialized standing queries
+ AnswerRun / PolicyRun audit tracesEvery question a user asks, and every standing policy the system evaluates, travels the same path: concepts are resolved against a registry (never invented), compiled into a typed query plan over a finite operation algebra, checked at every step by the permission engine, executed against adapters that ground results in the evidence graph, and sealed into an AnswerRun or PolicyRun audit trace whose hashes bind the plan, permissions, and outputs together.
The flow
The critical property: the LLM sits at exactly one trust boundary — candidate extraction inside packages/query-planner. Its output is explicitly typed as untrusted concept-resolution candidates that must pass through the deterministic resolver and query-runtime validation before anything executes. Planners cannot invent operations; the comment at the top of packages/query-runtime/src/algebra.ts puts it plainly: “Domain growth should happen through registries and operation arguments, not by letting planners invent new operations at runtime.”
What lives where
| Package | Role |
|---|---|
packages/query-runtime | Typed query algebra, plan validation, permission-gated execution, AnswerRun, gap emission |
packages/query-planner | Live (model-backed) planning — emits untrusted candidates only |
packages/semantic-registry | Controlled vocabulary: entities, metrics, rubrics, operations, gap types |
packages/computation-registry | Defined terms, typed formula ASTs, evaluator, reconciliation definitions |
packages/permission-engine | check/checkMany gates + decision proofs for every runtime surface |
packages/workflow-policy | DomainPolicy schema/runtime, PolicyRun, audience projections |
packages/workflow-core / workflow-runtime | Approved-workflow execution against decision packets |
packages/evidence-graph | Source → span → assertion → citation substrate (schema-only v0) |
packages/retrieval | query + scope + filters → evidence spans + trace, lexical baseline |
packages/source-claims | Versioned per-claim-type value schemas (fail-closed decoding) |
packages/findings | Finding lifecycle + contradiction flow surfaced from policy runs |
packages/ai, packages/evals | Effect AI inference layer and the eval harness |
Do not build on packages/query-execution. It is the legacy/demo intake package (document-to-workflow and side-letter experiments). Its fixtures and evals are still useful, but new durable runtime contracts belong in query-runtime, workflow-policy, or computation-registry — the README says so explicitly.
Where to go next
The runtime consumes facts produced by the source-to-ledger pipeline and persists its traces through packages/persistence (see the entity model for tenancy scoping). Demos of the full path exist today: bun run demo:largest-lp plans “Who was my largest LP in Fund 2?”, executes resolveEntities → rank → retrieveEvidence against seeded commitments, validates evidence-graph references, and prints a cited answer.