Runtime Execution Map

This page describes the verified execution role of NGB.Runtime.

Verified source anchors

NGB.Runtime/NGB.Runtime.csproj
NGB.Runtime/Documents/DocumentService.cs
NGB.Runtime/Reporting/ReportEngine.cs

Runtime in one sentence

NGB.Runtime is the orchestration center that turns platform metadata/definitions plus persistence abstractions into real business operations.

Dependency shape

The runtime project file directly confirms dependencies on:

• NGB.Accounting
• NGB.Application.Abstractions
• NGB.Contracts
• NGB.Definitions
• NGB.OperationalRegisters
• NGB.ReferenceRegisters
• NGB.Persistence
• NGB.Metadata

This is the right shape for a runtime core:

• it depends on business engines and abstractions;
• it does not depend on a specific provider package like PostgreSQL;
• provider-specific behavior is expected to sit below runtime.

Document execution center

Verified file:

NGB.Runtime/Documents/DocumentService.cs

What the file explicitly centralizes

From constructor dependencies and its application ports, DocumentService is the universal runtime orchestrator for:

• document metadata lookup;
• list/page queries;
• single-document reads;
• cross-type lookups by id/query;
• draft create/update/delete;
• trusted/system post / unpost / repost and mark / unmark lifecycle operations;
• trusted/internal draft derivation;
• relationship graph building;
• effects loading;
• payload validation and part validation;
• reference payload enrichment;
• audit write coordination.

The interactive 2.0 action façade is split out: IDocumentActionQueryService returns editor state, and IDocumentActionDispatcher executes lifecycle, derivation, and vertical commands with authorization, availability, optimistic concurrency, idempotency, audit, and outbox guarantees.

Document execution map

Important architectural consequence

This file proves that document behavior in NGB is not split randomly across controllers, repositories, and handlers. The runtime service acts as the main coordination surface.

That is one of the core architectural strengths of the platform.

Reporting execution center

Verified file:

NGB.Runtime/Reporting/ReportEngine.cs

What the file explicitly centralizes

From constructor dependencies and method flow, ReportEngine owns:

• definition resolution;
• layout validation;
• execution planning;
• executor invocation;
• sheet building;
• variant resolution;
• filter scope expansion;
• interactive field enrichment;
• bounded grouped and specialized accounting page execution;
• bounded export-sheet helper.

ReportQueryService owns read sessions and protected cursors. Complete downloads use ReportDownloadService and streaming exporters.

Reporting execution map

What is especially important in this file

1. Runtime owns semantics, not SQL

The engine decides:

• the effective request;
• the runtime model;
• the plan;
• which bounded page or plan executor handles the request;
• how diagnostics are surfaced.

2. Runtime owns interactive enrichment

The file explicitly enriches document-related report fields with display text and support metadata for UI navigation.

3. Runtime owns composable grouped paging behavior

ReportPagedQueryExecutor reads one row-group branch at a time and preserves pivot columns within each page. There is no rendered-sheet snapshot store. See Report Browsing and Direct Downloads.

Honest boundary statement

This page does not claim that only these two files matter in runtime. It claims that these two files are verified central execution anchors from which the runtime role can be documented confidently.

Recommended reading order

1. NGB.Runtime/NGB.Runtime.csproj
2. NGB.Runtime/Documents/DocumentService.cs
3. NGB.Runtime/Reporting/ReportEngine.cs

Continue with

• PostgreSQL Source Map
• Reporting Execution Map