Skip to content

Technology

CephalonEngine is intentionally small at the core, broad at the edges. The engine and abstractions stay tight; capabilities ship as opt-in companion packages.

This section catalogs every shipped package by domain. Each domain page lists the packages, their current maturity label, what they ship, and how to enable them.

Core

Core

Cephalon.Abstractions, Cephalon.Engine, runtime contract types, scaffolding internals.

Open core
Hosts

Hosts & transports

Cephalon.AspNetCore (REST, SSE, WebSocket), AspNetCore.GraphQL, AspNetCore.Grpc, AspNetCore.JsonRpc, Cephalon.Worker.

Open hosts
Data

Data

Cephalon.Data + adapters for Postgres, SQL Server, MySQL, Oracle, MongoDB, Cassandra, ClickHouse, Elasticsearch, OpenSearch, Redis, Neo4j, Qdrant, NATS, Debezium.

Open data
Eventing

Eventing

Cephalon.Eventing + Wolverine adapter. Outbox, scheduled delivery, DLQ replay, process managers, CDC capture.

Open eventing
Identity

Identity

Host-agnostic identity capability + AspNetCore adapter. Audit companion package.

Open identity
Multi-tenancy

Multi-tenancy

Tenancy primitives, governance (memberships, invitations, domain ownership, approvals), email-delivery adapters.

Open multi-tenancy
Observability

Observability

OTLP exporter + provider adapters (AWS, Azure, GCP, …) + dependency-health probes for 18+ backends.

Open observability
Edge

Edge

Cephalon.Edge runtime + Traefik and Kubernetes Gateway adapters.

Open edge
Agentics

Agentics

Agentic workload runtime services — task graph, tool registry, scheduled agents.

Open agentics
Retrieval

Retrieval

Retrieval/RAG runtime services + Qdrant adapter.

Open retrieval
Tooling

CLI & scaffolding

Cephalon.Cli, Cephalon.Scaffolding, Cephalon.TemplatePack, Cephalon.ReferenceDocs.

Open tooling
Identifiers

Identifiers

Cephalon.Ids.Sfid — the Sfid.Net-backed default for generated apps.

Open identifiers

Each domain page has four sections:

  1. Packages — every package in the domain, with current maturity (M0M4) and what it ships.
  2. How to enable — the Engine:* configuration plus the AddXxx(...) builder call.
  3. What you get — what the package adds to the runtime manifest, what services it registers, what behaviors it exposes.
  4. Cross-references — pointers to tutorials, reference docs, and the synced versioned source docs.
  • Optional by default. Adding a package never breaks an existing app.
  • Capability-driven. The package fulfils a declared Capability; the engine validates that providers exist for declared capabilities at composition time.
  • Host-agnostic. Where possible, the package’s runtime lives outside the host adapter. Host-specific adapters are separate packages.
  • Maturity-labelled. Every package ships with an explicit M0–M4 label so adopters know what is taxonomy-only, narrow, broad, or adoption-ready.
  • Source-traced. Every contribution appears in the runtime manifest with the contributing package and module recorded.

The full per-package source of truth lives in Reference → Architecture → Maturity audit and Conformance matrix.