Skip to content

BVER Overview

BVER is the foundational engineering operation layer inside the ETG stack. The ETG Platform hosts user-facing applications. The ETG Engine deploys and runs services. BVER defines the reusable engineering operations and contracts those services should expose. In this repo, that target architecture is only partially implemented today: bver-runtime mostly provides service/runtime substrate and transport scaffolding, while the full BVER primitive model still needs to be built.

What BVER Is

Applications (ETG Platform)
  -> Engine services (ETG Engine)
    -> Reusable engineering operations (BVER)

BVER should let domain expertise be defined once and reused across services, tools, and applications. Its job is to standardize how engineering capabilities are represented, versioned, exposed, and safely invoked. The goal is not to bury domain logic inside REST handlers or UI code. The goal is to make domain logic explicit, machine-usable, and portable across products.

The current ETG system overview establishes a small set of primitive operation types for BVER:

  • Interpreter
  • Resolver
  • Generator
  • Validator
  • Simulator
  • Evaluator

Those primitives are the intended BVER vocabulary. They are not the same thing as the current repo's OperationSpec, which is an exposure mechanism for transport-level operations.

What BVER Owns

  • Formal engineering operation contracts for the primitive types above, including metadata, inputs and outputs, versioning, mutability, and discovery.
  • Domain-agnostic schemas and state/graph contracts that let different applications bind their own semantics onto a shared execution model.
  • Deterministic, inspectable tooling that LLMs and services can call without inventing the underlying mechanics.
  • Auto-exposed service surfaces for REST, MCP, and internal execution paths so definitions do not need to be re-described per transport.
  • Reusable integration points for jobs, events, persistence, security, caching, and external adapters when those are needed to operationalize BVER-backed services.

BVER should stay generic at the contract level. Applications and domain packs provide the concrete domain semantics.

What BVER Does Not Own

  • Web, desktop, or mobile UX.
  • Product-specific views, sessions, dashboards, or presentation logic.
  • Environment provisioning, DNS, secrets systems, CI/CD policy, or deployment control-plane responsibilities.
  • Business logic duplicated inside endpoint routers or tool wrappers.
  • A single required infrastructure or framework stack. Concrete integrations can vary as long as they satisfy the runtime contract.

ETG Engine services own deployment and orchestration concerns. Applications own user experience. BVER owns the reusable engineering definition layer underneath them.

Where This Repo Stands Today

Area Current state in repo What is still missing
Service/runtime substrate Present. bver-runtime already has capability-driven bootstrap, security, persistence, jobs, events, refs, pointers, taxonomy, capabilities, and observability modules. These pieces still need to be aligned around first-class BVER engineering definitions instead of only generic runtime concerns.
Transport exposure Present. OperationRegistry, OperationBroker, REST exposure, MCP exposure, and tests for listing/invoking operations already exist. This exposure layer still needs a direct mapping from formal BVER primitives, not just generic transport-facing OperationSpecs.
Integrations and operational plumbing Partial. The repo has scaffolding for Celery, Redis, outbox/events, admin/reset, dependency health, migrations, and integrations such as RabbitMQ, Postgres, OpenSearch, Keycloak, and LiteLLM. Many of these modules are still placeholders or intentionally thin stubs.
Formal BVER primitive model Missing. There are no first-class Interpreter, Resolver, Generator, Validator, Simulator, or Evaluator contracts or registries in the runtime. The repo still needs the core BVER definition model itself.
Engineering graph/state/domain binding Missing. The repo does not yet define a shared engineering graph, evidence/state model, or domain-pack contract for reusable engineering semantics. These shared models are needed before BVER can support serious multi-domain engineering workloads.
Concrete domain packs Missing. The repo does not yet contain the first real electrical or Condor-facing domain pack that proves the abstractions end to end. A real domain pack is needed to validate the architecture against an actual product use case.

In short, this repo already contains useful runtime substrate, but it mainly scaffolds how services start, expose operations, and integrate with platform capabilities. It does not yet fully implement the engineering definition system described by the ETG overview documents.

What Still Needs Implementation In BVER

  1. Define the primitive contracts and registries. BVER needs first-class abstractions for Interpreter, Resolver, Generator, Validator, Simulator, and Evaluator, plus explicit schemas, metadata, versioning, and discovery.
  2. Add the engineering graph, state, evidence, and domain-binding layer. BVER needs generic models that let services represent systems, bind semantics, track provenance, and support interpretation or simulation style workloads without hard-coding one domain into the runtime.
  3. Build the execution bridge. Primitive definitions need to map cleanly into runtime execution, jobs, workflows, policy controls, and auto-generated REST/MCP surfaces. BVER should supply the reusable execution contracts, while ETG Engine level orchestration remains explicit rather than hidden.
  4. Implement the first real domain pack. The first electrical or Condor-facing pack should prove the abstractions with actual generators, validators, simulators, and interpretation/resolution workflows instead of framework-only code.
  5. Complete the substrate that is already stubbed. Workers, durable events/outbox support, Redis cache, admin/reset flows, dependency health, migration hooks, and planned integrations should move from placeholder modules to real implementations.

How BVER Gets Operationalized

BVER definitions are meant to be deployed through ETG Engine services, not embedded directly into applications. The intended implementation plan standardizes the service contract so every service repo looks and deploys the same way.

Each service repo should include:

  • domain code
  • tests
  • Dockerfile
  • a service manifest such as service.yaml
  • health and version metadata
  • CI/CD workflow definitions

Exposure modes should deploy separately even when they share the same underlying domain package:

  • rest
  • mcp
  • worker
  • optional beat

The current intended deployment pattern is containerized, environment-specific promotion through shared CI/CD rather than hand-written deployment logic per repo. The planning documents currently point at standardized service manifests, per-environment deployment targets, and a consistent runtime contract for how services are launched. That deployment shape is an operational target for BVER-backed services, not a hard dependency that defines BVER itself.

  1. Formalize the primitive contracts and decide how they map to the current OperationSpec exposure model.
  2. Add shared graph, state, evidence, and domain-binding models.
  3. Connect those definitions to jobs, workflows, and auto-generated REST/MCP surfaces.
  4. Implement the first electrical domain pack and prove the abstractions against a real use case.
  5. Replace placeholder integrations and finish the standardized service/deployment template.