Have you ever wondered what happens when a skilled software, electrical, or control systems engineer opens a nuclear plant simulator for the first time? You instantly recognize the generators, turbines, and grid connection. But then you hit a screen labeled Reactor Kinetics, a value called pcm, or a button marked SCRAM, and find yourself in uncharted territory.

From Grid to Core is written specifically to bridge that gap.

Unlike traditional nuclear textbooks that begin with dense atomic physics and hand down axioms from page one, this book takes a deliberately reversed engineering approach. We start at the 400 kV switchyard—ground you already own as an engineer—and walk upstream, room by room, until we reach the nuclear core. Every new concept is explained using the language you already speak: control loops, negative feedback paths, numerical solvers, and component degradation.

Try the Live Software Demo Now!

This book is a hands-on, deeply integrated companion guide to NEXUS-1, a fully interactive, browser-based nuclear plant operator console and digital twin.

No server, no installation, and zero setup required. The entire simulator runs locally in your browser. You can load it right now, play with the control rods, monitor the core parameters, and watch the physics engines calculate the math live:

👉 Play with the Live Simulator: https://gregory82gr.github.io/Nexus-1-phase-0/

What’s Under the Hood? (The Engineering Blueprint)

This is not a cosmetic layout or a sci-fi game. The companion book explains the literal software architecture and mathematical implementations executing live inside the NEXUS-1 Phase 0 demonstrator:

• The Point-Kinetics Engine: Learn how the simulator solves the standard reactor dynamics equations using 6 delayed-neutron precursor groups (U-235 data) and a 12-group decay heat afterheat model.
• The Closed-Loop Feedback: Explore how the system self-regulates through physical negative feedback loops: Doppler gain (fuel temperature), moderator gain (coolant temperature), and Xenon-135 worth.
• Solver Validation & Verification: See how the live numerical integration scheme (built to handle stiff differential equations) is verified in real-time against textbook closed-form equations like the inhour equation and prompt-jump formula.
• Advanced Modules: Dive into the architecture of predictive diagnostics, automated alarm flood correlation using causal fault-propagation graphs, and interpretable reinforcement learning (Q-learning) for autonomous rod control.

How Every Chapter is Structured

To ensure maximum utility, every single chapter follows a predictable engineering blueprint:

1. What You Already Know: The structural bridge from your existing enterprise software, electronics, or control systems background.
2. The Concept: A clear, prose explanation of the system's real-world physics.
3. See it in NEXUS-1: Direct guidance on where and how that concept lives live on your simulator screen.
4. Try It (Drills): Guided interactive drills to manipulate the console (e.g., triggering a +10 pcm step or a post-shutdown Xenon transient) and analyze the telemetry response.
5. Honest Boundary: A completely transparent look at exactly where the Phase 0 simulator simplifies engineering realities and where it faithfully integrates exact textbook physics.

👤 Who This Is For

This project requires zero prior nuclear knowledge. If you are fluent in software engineering, systems design, control theory, or basic engineering, and you want to demystify how a modern Pressurized Water Reactor (PWR) works by driving a real, live-computed simulator, this book is built for you.

Author: Grigorios Kyriakos Agathangelidis.

Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης.

Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.

Something trips. In the next four seconds, two hundred alarms fire. The board is a wall of red, every annunciator is screaming, and the one alarm that actually matters — the cause — is buried somewhere in the flood, indistinguishable from the two hundred consequences stacked on top of it. "Loudest alarm wins" is how that ends badly.

And now there's a new temptation: point a large language model at the flood and ask it what happened. It will give you a fluent, confident, beautifully-worded answer — and you will have no way to know whether any of it is true.

From Flood to Cause is written to resolve both problems at once, around a single governing principle:

The engine decides, the model explains.

A deterministic causal engine — not a neural network — identifies the root cause from an engineered fault-propagation graph and corroborating telemetry. The language model never diagnoses, never ranks, never votes. It runs strictly downstream, in an advisory-only role, to put the engine's conclusion into cited language a person can audit — and it abstains the moment grounding is absent. This book shows you, end to end, how to build a system like that and why every piece is where it is.

Try the Live Console Now!

This is a hands-on companion to NEXUS-1, a fully interactive, browser-based root-cause console. No server, no installation, zero setup. Every incident, graph node, edge weight, and delay window in the book is drawn from this live system — nothing is invented. Load it, trigger a cascade, and watch the engine collapse the flood to a single origin:

👉 Play with the live console: https://gregory82gr.github.io/Nexus-1-phase-0/

What's Under the Hood? (The Engineering Blueprint)

This is not a prompt-engineering listicle. It's the literal architecture and the discipline that makes an LLM safe to put near an operating decision:

• The Engineered Causal Graph — backbone, learned-weight, artefact, and rejected edges; delay windows; how the engine separates the one origin from the cascade it caused.
• The Grounding Triangle — database, telemetry, and documentation as three independent witnesses, assembled into a single Unified Context.
• The Anti-Hallucination Engine (H1–H10) — ten concrete controls, each with a worked example: the closed-world contract, the grounding gate, entity and citation validation, structured output, forced abstention, and a hash-chained audit trail.
• What the Model May Read — building a RAG corpus you can trust: hybrid retrieval, retrieval evaluation, and corpus governance.
• The Reference Stack — OpenTelemetry, Prometheus, Grafana, and Microsoft Semantic Kernel used as a constrained orchestration layer (explicitly not an agent that picks its own tools), implemented in C# and SQL Server 2025 with vector retrieval.
• Three Case Studies from the Console — a cascade, an EMI artefact, and a QA escape, each diagnosed and explained from real console data.
• Five Developer Appendices (F–J) — copy-pasteable quickstart: project layout, the Ollama Modelfile, the closed-world prompt and validation schema, observability wiring, and a CI evaluation harness — everything needed to stand the explain side up on your own machine.

How Every Chapter Is Structured

Every chapter follows the same engineering blueprint:

1. What You Already Know — the bridge from your existing software, data, or control-systems background to the concept at hand.
2. The Concept — a clear, prose explanation of the mechanism and why it exists.
3. One Figure — a single precise diagram, drawn from real console data, never decoration.
4. See It in NEXUS-1 — exactly where that concept lives on the live console screen.
5. Honest Boundary — a transparent statement of what the Phase-0 system genuinely does versus where it simplifies, including the limits of the controls themselves. No claim that something works better than it does.

👤 Who This Is For

If you are a software, data, control-systems, or SRE engineer — comfortable with C#/.NET, SQL, and systems design — and you are being asked to put a language model somewhere its answers actually matter, this book is built for you. It assumes no background in alarm management or nuclear engineering; it builds the reasoning up from the screens and the code. It is the diagnostic-and-AI companion to From Grid to Core, and it stands entirely on its own.

Author: Grigorios Kyriakos Agathangelidis
Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης
Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.

Power is drifting below target.

An operator can correct it. A conventional controller can correct it. A page of carefully tuned if-rules can probably correct it too.

But what happens when the operating conditions change, the assumptions behind those rules begin to break down, and the trade-off between accuracy, stability, and actuator wear becomes too complex to tune by hand?

And now there is a new temptation: hand the problem to a machine-learning model and let it learn for itself.

It will produce recommendations.

It may even produce excellent recommendations.

But if the recommendation affects a control system, one question matters more than all the others:

Can you explain exactly why it chose that action?

From Trial to Policy is written around a single governing principle:

The agent learns, the engineer understands.

This book shows how to build a reinforcement-learning agent that remains completely readable after training. No hidden layers. No black-box neural network. No mysterious weights distributed across millions of parameters. The result of learning is a simple, inspectable Q-table: a finite set of states, a finite set of actions, and a number describing the long-term value of each possible choice.

Every recommendation can be traced.

Every action can be explained.

Every learned policy can be read directly by a human.

The book takes reinforcement learning apart piece by piece and rebuilds it from first principles. Agent. Environment. Reward. State. Action. Exploration. Policy. Nothing is assumed, and nothing is hidden behind mathematical jargon. Each concept is mapped directly to C#, .NET, SQL Server, and a working industrial-style control problem.

Try the Live Console Now!

This is a hands-on companion to NEXUS-1, a fully interactive browser-based optimization console. No installation, no server, zero setup. Every state, action, reward curve, policy grid, and training result shown in the book comes directly from this live system.

Open the console, start training, and watch the policy emerge from thousands of episodes of trial and error.

👉 Play with the live console:
https://gregory82gr.github.io/Nexus-1-phase-0/

What's Under the Hood? (The Engineering Blueprint)

This is not a machine-learning theory book. It is the architecture of a working, interpretable reinforcement-learning system.

• The Control Problem — how a familiar feedback loop becomes a learning problem.

• Agent, Environment, Reward — the three building blocks of reinforcement learning, mapped directly to C# interfaces and classes.

• The Digital Twin Training Ground — why learning happens inside a fast surrogate model rather than on the real system.

• State and Action Design — turning a continuous world into 35 readable states and five discrete control actions.

• The Q-Table — the entire learned policy stored as 175 auditable numbers.

• The Learning Algorithm — Q-learning explained step by step, arithmetic by arithmetic, without requiring a machine-learning background.

• Exploration versus Exploitation — why an agent must sometimes try apparently bad actions in order to discover better policies.

• Policy Interpretation — reading the learned table directly and understanding why every decision was selected.

• Advisory Deployment — how a learned policy becomes operational advice while remaining bounded, inspectable, and human-approved.

• C# and SQL Server Implementation — complete architecture, persistence model, training workflow, reward logging, and policy storage.

How Every Chapter Is Structured

Every chapter follows the same engineering blueprint:

What You Already Know — connecting new reinforcement-learning concepts to familiar software-engineering ideas.

The Concept — a precise explanation of the mechanism and why it exists.

One Figure — a focused diagram illustrating the idea being discussed.

See It in NEXUS-1 — exactly where the concept appears in the live console.

Honest Boundary — a transparent discussion of limitations, assumptions, and what the demonstration genuinely does versus what it deliberately simplifies.

No magic.

No hype.

No claims that learning systems are smarter than they are.

Only mechanisms that can be inspected, explained, and reproduced.

👤 Who This Is For

If you are a C#/.NET developer, software architect, controls engineer, simulation engineer, or systems designer who has never studied reinforcement learning but wants to understand how a real learning agent works, this book is for you.

It assumes you are comfortable with software development and basic engineering reasoning. It assumes no prior knowledge of machine learning, neural networks, statistics, or control theory.

By the final chapter you will be able to open a policy table, inspect every learned action, and understand exactly how trial and error became a decision-making strategy.

This volume is the reinforcement-learning companion to NEXUS-1 and the third book in the companion series following From Grid to Core and From Flood to Cause.

Author: Grigorios Kyriakos Agathangelidis
Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης
Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.

About the Book

What does a digital twin look like when you stop describing it in diagrams and actually give it a database?

From Schema to System is the complete data-backbone reference for the NEXUS-1 companion system. It takes the architecture introduced in From Table to Twin and writes it down as a full SQL Server / EF Core friendly schema atlas: one database, seventeen bounded contexts, hundreds of tables, typed lookup tables, primary keys, foreign keys, indexes, audit columns, and verification queries.

This is not a book about database theory in the abstract. It is a concrete schema reference for an industrial digital-twin platform built around the NEXUS-1 demonstration environment. The plant fleet, instrumentation layer, digital twin, alarm management, event management, maintenance records, root-cause engine, reinforcement-learning policy store, robotics fleet, radiation monitoring, emergency preparedness, compliance, reporting, and audit trail are all modelled as connected sectors of one database.

The central idea is simple:

A digital twin is only as trustworthy as the data backbone that holds it together.

If a unit exists in the reactor fleet, the same UnitId should be visible in instrumentation, alarms, root-cause analysis, maintenance, reporting, and audit. If a signal feeds a twin variable, that binding should be explicit. If an alarm becomes an incident, and the incident becomes a root-cause investigation, and the investigation produces corrective actions, the chain should be queryable. If the system claims that something happened, the database should be able to show where that claim came from.

This book is the schema map for that chain.

What This Book Contains

The book contains the complete NEXUS-1 schema atlas:

• 17 SQL Server schemas / bounded contexts
• 654 total tables
• 246 typed lookup or reference tables
• 408 substantive operational, historical, audit, fact, or relationship tables
• SQL Server / EF Core friendly DDL
• Primary-key and foreign-key definitions
• Lookup-table conventions
• ER diagrams and foreign-key passport maps
• Cross-schema dependency mappings
• Index definitions
• Seed-data examples
• Verification queries

The schemas covered are:

1. CorePlatform
2. Security
3. Organization
4. ReactorFleet
5. Instrumentation
6. DigitalTwin
7. AlarmManagement
8. EventManagement
9. Maintenance
10. RootCause
11. ReinforcementLearning
12. Robotics
13. RadiationMonitoring
14. EmergencyPreparedness
15. Compliance
16. Reporting
17. Audit

Together, these sectors form the complete data backbone behind the NEXUS-1 digital-twin concept.

Why This Book Exists

The earlier NEXUS-1 books each explained one major part of the platform.

From Grid to Core explained the plant and its physics.
From Flood to Cause explained alarm-flood collapse and root-cause reasoning.
From Trial to Policy explained the interpretable reinforcement-learning agent.
From Table to Twin explained why the data model matters and how a schema becomes a digital twin.

From Schema to System is the technical reference that follows from all of them.

It answers the question:

If all of those systems really lived in one coherent platform, what would the database look like?

The answer is not a single table, not a toy schema, and not a collection of disconnected examples. It is a complete, sector-by-sector architecture where every table has a place, every lookup has a type, and every cross-sector relationship is made explicit by a foreign key.

Who This Book Is For

This book is written for:

• software architects
• database designers
• .NET and EF Core developers
• SQL Server developers
• engineers interested in digital-twin platforms
• readers of the NEXUS-1 series who want the complete data model
• anyone studying how large operational systems can be organized into bounded contexts

You do not need nuclear-industry experience to read it. The nuclear-plant setting is the reference system, not the assumption. The real subject is enterprise data architecture for complex industrial systems.

If you have ever wondered how to model a system where telemetry, alarms, incidents, maintenance, root-cause analysis, compliance, reporting, and audit all need to speak about the same physical world, this book is for you.

What Makes It Different

Most database examples are too small to teach architecture. They show customers, orders, products, invoices, and perhaps a few lookup tables. That is useful, but it does not show what happens when a platform grows large enough to need real boundaries.

This book starts where small examples stop.

It shows:

• how to divide a large system into schemas without losing referential integrity
• how to use lookup tables without falling into hardcoded constants
• how to make foreign keys act as passports between bounded contexts
• how to keep operational records, history, evidence, and audit separate but connected
• how to design for EF Core without giving up SQL Server clarity
• how to make a digital twin queryable instead of merely visual

The result is not only a schema. It is a way of thinking about system truth.

Honest Boundary

NEXUS-1 is a Phase-0 demonstration and educational companion system. The schema in this book is a serious software-architecture reference, but it is not a licensed nuclear-plant information model, not safety-class software, not certified for operational use, and not connected to any real facility.

The purpose of this book is to show how a complex digital-twin platform can be structured, keyed, audited, and reasoned about at database level.

It is a schema atlas, not an operating manual.

In One Sentence

From Schema to System is the complete SQL Server / EF Core schema atlas for the NEXUS-1 digital-twin platform: one database, seventeen sectors, fully keyed.

Author: Grigorios Kyriakos Agathangelidis
Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης
Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.

About the Book

What does an enterprise EF Core model look like when the DbContext stops being a dumping ground and every entity gets its own professional configuration file?

From Entity to Context is the EF Core configuration companion to the NEXUS-1 schema atlas. It takes the database backbone defined in From Schema to System and shows how that structure can be mapped cleanly into C# using Entity Framework Core, Fluent API, configuration classes, migrations, indexes, relationships, defaults, constraints, and schema-aware folder organization.

This is not a general EF Core tutorial. It is a practical configuration atlas for a large industrial digital-twin platform. The focus is Code First, but not Code First as a toy example. The book shows how Code First can be organized in an enterprise-level project where the model is too large to live inside one OnModelCreating method.

The central idea is simple:

One entity should have one clear mapping, and the context should remain clean.

Instead of filling the DbContext with hundreds or thousands of mapping lines, each entity receives its own IEntityTypeConfiguration<T> class. Keys, table names, schema names, indexes, precision, default values, relationships, delete behavior, row versions, lookup-table conventions, and foreign-key names are placed where they belong: beside the entity they configure.

The result is a model that a programmer can navigate, review, test, migrate, and maintain.

What This Book Contains

The book contains the complete EF Core configuration atlas for the NEXUS-1 companion system.

It includes:

• EF Core Code First reminder chapter
• clean DbContext pattern
• ApplyConfigurationsFromAssembly
• schema-based folder structure
• configuration classes using IEntityTypeConfiguration<T>
• Fluent API mapping examples
• table and schema naming conventions
• primary-key configuration
• alternate keys and unique indexes
• required and optional properties
• SQL Server default values
• DATETIME2, decimal precision, and string-length conventions
• row-version and concurrency patterns
• lookup-table configuration patterns
• cross-schema foreign-key mapping
• migration and verification notes
• configuration indexes for the full atlas

The schema sectors covered are:

1. CorePlatform
2. Security
3. Organization
4. ReactorFleet
5. Instrumentation
6. DigitalTwin
7. AlarmManagement
8. EventManagement
9. Maintenance
10. RootCause
11. ReinforcementLearning
12. Robotics
13. RadiationMonitoring
14. EmergencyPreparedness
15. Compliance
16. Reporting
17. Audit

Together, these chapters show how the full NEXUS-1 data model can be represented in EF Core without losing structure, naming discipline, or database clarity.

Why This Book Exists

From Schema to System answered one question:

If the NEXUS-1 digital twin lived in one coherent SQL Server database, what would that database look like?

From Entity to Context answers the next question:

If that database is mapped professionally in a .NET application, what should the EF Core configuration layer look like?

The answer is not one giant DbContext.
It is not a pile of attributes scattered across entity classes.
It is not a migration file nobody understands.

The answer is a configuration atlas: one entity, one configuration file, one clear place where the database contract is expressed in C#.

Who This Book Is For

This book is written for:

• .NET developers
• EF Core developers
• backend engineers
• software architects
• database-aware C# programmers
• developers working on large enterprise systems
• readers of the NEXUS-1 series who want the C# mapping layer behind the schema

You do not need nuclear-industry experience to read it. The nuclear digital-twin setting is the reference system, not the prerequisite. The real subject is enterprise EF Core organization for large, schema-rich applications.

If you have ever opened a project where OnModelCreating became unreadable, where indexes had random generated names, where relationship configuration was scattered, or where nobody knew which class truly owned the database mapping, this book is for you.

What Makes It Different

Most EF Core examples are intentionally small. They show a few entities, a simple DbContext, and perhaps one or two Fluent API rules. That is useful for learning the basics, but it does not show what happens when the model grows into dozens or hundreds of tables across multiple bounded contexts.

This book starts where small examples stop.

It shows:

• how to keep DbContext clean in a large project
• how to organize configuration files by schema
• how to use Fluent API as the database contract
• how to give indexes and constraints stable professional names
• how to map lookup tables consistently
• how to configure cross-schema relationships
• how to keep Code First readable at scale
• how to prepare migrations that a real team can review
• how to make EF Core serve the database model instead of hiding it

The result is not only EF Core code. It is a way of keeping a large C# data model honest.

Honest Boundary

NEXUS-1 is a Phase-0 demonstration and educational companion system. The EF Core mappings in this book are serious software-architecture material, but they are not certified nuclear software, not a licensed plant data model, not safety-class implementation guidance, and not connected to any real facility.

The purpose of this book is to show how a complex digital-twin schema can be mapped professionally in EF Core using Code First discipline, configuration classes, clear naming, and explicit relationships.

It is a configuration atlas, not an operating manual.

In One Sentence

From Entity to Context is the complete EF Core configuration atlas for the NEXUS-1 digital-twin platform: one entity, one mapping, clean context.

Author: Grigorios Kyriakos Agathangelidis
Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης
Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.

About the Book

Have you ever worked on a system where the code, the database, and the business language slowly stopped agreeing with each other?

A table says one thing.
A service says another.
A controller knows too much.
An entity is only an anemic bag of properties.
A “rule” lives in five different places.
And everyone uses the same word — Unit, Event, Case, Model, Policy — with slightly different meanings.

From Domain to Twin is written to solve that problem from the ground up.

This book teaches Domain-Driven Design from zero, in plain human language, for mid-level .NET developers who already understand C#, EF Core, SQL tables, APIs, services, DTOs, and application structure, but have never had DDD explained slowly and practically.

It does not begin with abstract theory. It begins with the normal developer problems you already know: confusing models, unclear service boundaries, misplaced business rules, overgrown DbContext classes, fragile database relationships, and systems where nobody is quite sure who owns the truth.

Then it introduces DDD step by step.

You will learn what a domain is, what a model is, why a shared language matters, how entities differ from value objects, why aggregates protect consistency, what repositories should and should not do, where application services belong, what domain events really mean, and how bounded contexts prevent one word from meaning five different things.

But the book does not stop at definitions.

The second half applies every idea to NEXUS-1, a browser-based industrial digital-twin demonstrator. NEXUS-1 contains a plant/fleet model, instrumentation, alarms, root-cause reasoning, digital-twin snapshots, reinforcement-learning recommendations, audit, compliance, reporting, and EF Core persistence. That makes it a much richer DDD example than the usual shopping cart, invoice, or order-processing system.

Through NEXUS-1, the book shows how DDD can organize a serious engineering-style platform:

• A Unit is not just a string or dropdown value; it is part of the plant domain.
• A Signal is not an alarm; it is measured instrumentation data.
• An AlarmEvent is not a root cause; it is a domain fact that something crossed a configured condition.
• A RootCauseCase protects hypotheses, evidence, rejected candidates, and final verdicts.
• A TwinDivergence is the system admitting that the model and measured reality disagree.
• A reinforcement-learning Recommendation is not a command; it is advisory output that must stay inside its boundary.
• An AuditEntry is not log noise; it is part of the accountability story.

The final part turns the model into implementation. It connects bounded contexts to project structure, SQL schemas, EF Core mappings, aggregate roots, owned value objects, domain methods, application services, repositories, read models, reporting screens, and audit trails.

This book is not a theoretical contribution to DDD. It is a practical learning journey: DDD explained from first principles, then applied to a complex NEXUS-1 digital-twin architecture until the meaning of the system becomes visible.

What You Will Learn

• How to understand DDD without academic language
• How to distinguish entities, value objects, aggregates, services, repositories, and events
• How to decide where business rules belong
• How bounded contexts prevent language and ownership confusion
• How to define a ubiquitous language for a real system
• How to map DDD ideas to C#, EF Core, SQL Server, and application services
• How to separate commands, events, recommendations, decisions, and read models
• How to think about audit and traceability as part of the domain, not as an afterthought
• How NEXUS-1 can be read as a domain model, not merely as a dashboard

Who This Is For

This book is for software developers, especially .NET developers, who want a practical entry point into Domain-Driven Design.

You do not need prior DDD knowledge. You only need normal development experience: classes, services, controllers, databases, APIs, DTOs, and business rules.

It is especially useful if you have ever asked:

• Where should this rule live?
• Is this object an entity or a value object?
• Is this service doing too much?
• Should this table be part of the same context?
• Is this event a fact, a command, or just a log?
• Why does the database model feel different from the code model?
• How do I stop a large system from becoming a pile of tables and services?

The NEXUS-1 Boundary

NEXUS-1 is a demonstration and educational platform. It is not connected to any real plant, not safety-class software, not certified operational code, and not intended for use in any real nuclear facility.

In this book, NEXUS-1 is used as a rich software-architecture case study: a way to explain how domain language, boundaries, rules, data, and decisions can be organized in a complex industrial-style system.

Author: Grigorios Kyriakos Agathangelidis
Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης
Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.

Have you ever opened the database behind a system you thought you understood, and found two answers where you expected one? You recognize the tables — Unit, Signal, WorkOrder — but then you hit a folder of EF Core migrations that doesn't quite match the SQL someone else wrote by hand, a DbContext with shadow foreign keys nobody named, and a quiet, nagging question: which one of these is actually telling the truth about my data?

From Table to Twin is written specifically to answer that question.

Unlike most Entity Framework books, which hand you a DbContext on page one and never look back, this book takes a deliberately two-path approach. You build the same industrial schema twice — once by hand in SQL Server, reverse-engineered into C#; once from C# with Code First, generating its own migrations — and then you put the two builds side by side. Where Scaffold-DbContext and Fluent API disagree on naming, shadow keys, and inferred relationships, this book doesn't pick a winner and move on. It prints the disagreement, in a dedicated reconciliation chapter, and shows you which one to trust and when.

Try the Live Software Demo Now!

This book is a hands-on, deeply integrated companion guide to NEXUS-1, the same fully interactive, browser-based digital-twin console used throughout the series — except this volume is the one that finally writes down where all of it actually lives.

No server, no installation, and zero setup required. Open the console, and every schema named in this book, every query quoted, and every row counted can be counted again, live, in your browser:

👉 Play with the Live Console: https://gregory82gr.github.io/Nexus-1-phase-0/

What's Under the Hood? (The Schema Blueprint)

This is not a toy Blog/Post sample database. The companion book walks the literal data backbone of an industrial nuclear-plant digital twin — a schema plausibly past two hundred tables, built to the same standard throughout:

• One schema, seventeen bounded contexts. Reactor Fleet, Instrumentation, Alarm Management, Digital Twin, Root Cause Analysis, Reinforcement Learning, and the rest — every sector the first three NEXUS-1 volumes already wrote to, finally given a single, coherent home.
• Two builds, one model. Part 1 authors the database by hand in SQL Server — schemas, keys, indexes, constraints, views — then reverse-engineers it with Scaffold-DbContext. Part 2 rebuilds the identical model from C#: configuration classes, value converters, owned types, and generated migrations.
• The uniform lookup-table generator. Rather than forty near-identical CREATE TABLE listings, the book teaches one shape, one SQL generator, and one generic IEntityTypeConfiguration<T> — and proves it in an appendix that lists every table the generator actually produced.
• Advanced relationships, taken seriously. Owned types, table-per-type inheritance for equipment hierarchies, many-to-many joins, alternate keys — modelled the way an industrial schema actually needs them, not the way a tutorial simplifies them.
• Audit, history, and performance, with evidence. Soft delete with query filters, SQL Server temporal tables, RowVersion concurrency — then indexes measured the honest way, with logical reads and execution plans shown before and after, never asserted from memory.
• Beyond the ORM. A dedicated appendix on Dapper, SqlBulkCopy, and raw SQL — and the harder discipline of knowing the handful of places in a two-hundred-table schema where EF Core is genuinely the wrong tool.

How Every Chapter Is Structured

To keep sixteen chapters of database design from turning into a wall of DDL, every chapter follows the same five-beat scaffold the NEXUS-1 series has used since Volume I:

1. What You Already Know: The bridge from engineering instincts you already have — a bounded context is just a SQL schema with a passport; a foreign key is just the passport between them.
2. The Concept: A clear, prose explanation of the modelling decision, never a checklist of EF Core features for their own sake.
3. See It in NEXUS-1: Direct guidance on exactly where that table, that index, or that migration is live on your console screen.
4. Try It: Something to actually run — add a Status row and watch it appear without a redeploy; run a migration twice and watch nothing break.
5. Honest Boundary: A transparent account of what the model simplifies, defers, or deliberately does not claim — because nothing in this book claims to exist that does not.

👤 Who This Is For

This book assumes you're already fluent in C#, comfortable in .NET, and at home in SQL Server. It does not assume you want a guided tour of Entity Framework's feature list — that is not what this book is. If you've ever inherited a database you didn't trust, scaffolded a model you couldn't quite read, or wondered whether your Code First migrations and your DBA's hand-written schema actually agree with each other, this is the book that walks you through finding out — on a real, running reference you can open and check for yourself.

Author: Grigorios Kyriakos Agathangelidis
Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης
Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.

Full Book Description (Markdown, for the LeanPub landing page)

Most technical books perform certainty. This one interrogates it.

From Certainty to Calibration is the retrospective closing volume of the NEXUS-1 Companion Series — a return trip through six architectural decisions from the first seven volumes, each one re-examined against a single question: was this actually right, and if not, what would replace it?

Every chapter runs the same disciplined structure:

• Then — the original decision, stated faithfully
• The Mechanism, in Detail — the actual code or schema behind it, walked through before any verdict is offered
• Why This Seemed Sufficient at the Time — a fair reading of the original constraints, before any critique
• Learned — what changed the picture, labeled explicitly: did the original volume already name this limit (confirmed), or is this genuinely new (extended)?
• Now — a specific, implementable fix, not a vague direction
• What the Fix Itself Risks — the same scrutiny turned back on the book's own proposal

Six chapters, in full:

1. The Sacrifice of Scale for Readability — a reinforcement-learning Q-table's readability-versus-scale trade-off, and a hybrid design that keeps the audited core intact while adding room to grow.
2. The Sequential Bottleneck — a root-cause engine's fail-closed pipeline, and the hidden difference between "nothing caused this" and "the cause exists but was never mapped."
3. The Discipline of the LLM — ten anti-hallucination controls around a language model, and why the obvious fix for their one known gap would quietly break two of the ten.
4. The Naïve RAG Corpus — a retrieval corpus's governance disciplines, and the case for enforcing them as database constraints instead of team discipline.
5. The Illusion of Independent Witnesses — a telemetry corroboration check's independence assumption, and a table in the schema that looks like the fix but isn't.
6. The SQL That (Almost) Worked — a preview-feature dependency in a vector search query, and an argument against the obvious two-database fix.

A five-lesson survival guide distills the findings into a short, source-agnostic checklist for anyone building audit-heavy or safety-adjacent systems — each lesson closes with a worked example from outside NEXUS-1 entirely (payments, fraud detection, content moderation, medical triage, demand forecasting), as a check that it actually generalizes rather than just restating its source chapter.

The book closes with an honest tally of its own six chapters — how many findings were confirmed, how many were genuinely new, and an admission that most landed somewhere in between — because a retrospective that only ever finds fault in the original design, and never in its own proposals, hasn't actually kept its own rule.

Who this is for: senior software architects, .NET and SQL Server practitioners, and engineers building systems where an audit trail matters. Familiarity with the earlier NEXUS-1 volumes helps but isn't required — Part 0 gives enough context to follow the argument without it.

What this book is not: a defense, an apology, or a claim that the original series was wrong. Every original decision examined here is judged to have been correct under the constraints it was made with. What's new is only ever the second half of the sentence: correct, and here is what it costs now that the constraints have shifted.

Author: Grigorios Kyriakos Agathangelidis
Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης
Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.

Most architecture books show you a diagram and ask you to trust it. From Blueprint to Core shows you the diagram, then makes you prove it — with a compiler, a test runner, and nothing else.

This is the first volume of a three-part trilogy that builds the backend of NEXUS-1, a fictional Phase-0 nuclear-plant digital twin, from an empty folder to a fully tested Domain and Application layer — without a database, without a web server, and without a single line of infrastructure code. By the last page, fifty tests are green, every business rule has been watched failing on purpose at least once, and the core of a seventeen-context platform runs in about six hundred milliseconds on nothing but the .NET SDK.

That absence is not a shortcut. It's the argument. Clean Architecture's central claim is that the heart of a system — its rules, its language, its invariants — should be provable independently of the database, the framework, and the wire format around it. Most books that teach this claim show you a toy example and ask you to believe it scales. This one builds the real thing: five projects, seventeen bounded contexts (five fully populated, twelve honestly reserved), and a domain model translated line-by-line from an existing DDD specification into idiomatic, modern C# — records, primary constructors, collection expressions, and all.

What Makes This Book Different

It practices what it teaches. Every architectural decision is made once, in the open, and then held to for the rest of the book — the SharedKernel is frozen at five citizens in Chapter 4 and never grows again; the after-commit event-dispatch decision made in Chapter 9 becomes contract language in Chapter 12 and stays load-bearing through Chapter 19. When an earlier chapter's own code needs correcting, the correction happens on the page, in a diff, not silently.

It shows its refusals, not just its successes. Every invariant in this book is proven by a test that commits the exact crime the rule forbids and watches it fail by name. An inventory audit in Chapter 18 finds ten refusals the book itself forgot to test — and pays every one of them back, in the open, in an appendix.

It draws what it explains. Nineteen chapters are followed by nineteen two-page Deep Dive companions — plain-language explanations and original UML diagrams (use-case, class, sequence, and state-machine figures) for readers newer to software architecture, adding floors under the material without ever watering down the technical standard above them. A recurring "Where We Are in the Solution" panel tracks the growing codebase and test count from an empty tree to fifty green tests, so you always know exactly how much of the system exists at any page.

It knows exactly what it hasn't built yet. The book ends with an Epilogue titled The Honest Boundary of Volume I — an itemized account of everything deliberately absent (persistence, HTTP, authentication, logging) and which volume owns each one. The forward ledger is not a marketing footnote; it's the map the rest of the trilogy is built against.

What's Inside

• Part I — The Architectural Foundation. Solution structure, the Dependency Rule, the SharedKernel, and dependency injection — five projects, seventeen context folders, zero circular references, enforced by the compiler rather than a linter.
• Part II — The Domain Layer. Entities, value objects, aggregates, domain events, and domain services — culminating in three full bounded-context walkthroughs (alarm management, root-cause analysis, and reinforcement learning) proving the patterns hold at scale, not just in isolation.
• Part III — The Application Layer. Ports before adapters, CQRS as two disciplined code paths, commands and handlers that orchestrate without ever deciding a business rule themselves, and a closing case study — one operational night traced end to end through every layer the book built.
• Part IV — Proving the Core. The testing discipline made systematic: an invariant inventory that audits itself, test-data builders that only ever open legal doors, and the honest-fakery doctrine that keeps fifty tests fast without ever lying about what they've proven.
• Seven appendices — an installation guide, the full solution skeleton with every elided listing and exercise solution restored, the tools-and-packages ledger, the bounded-context-to-schema map, sources, a glossary, and an index.

Who This Book Is For

Developers who know some C# and have heard of Clean Architecture or Domain-Driven Design but have never seen either one built all the way through, without hand-waving, on a project large enough to feel real. Architects who want a worked example they can hold their own team's decisions against. And anyone who has ever finished an architecture book feeling like they understood the diagram but couldn't have written the code — this book is the missing middle step.

No prior NEXUS-1 reading is required. The companion volumes referenced throughout — covering the plant physics, the root-cause engine, the reinforcement-learning model, and the underlying schema atlas — are companions, not prerequisites: everything you need to follow this book's code is inside it.

About the NEXUS-1 Companion Series

From Blueprint to Core is the ninth volume in the NEXUS-1 Companion Series, a set of books that teach software architecture, data design, and applied AI through one consistent fictional demonstrator: a Phase-0 digital twin of a nuclear power plant. Every volume shares the same standing boundary — NEXUS-1 is a teaching platform, never operational guidance, and nothing in the series claims authority over a real facility. This volume opens the backend trilogy; From Core to Contract (persistence and the API) and From Contract to Container (testing, logging, and deployment) complete it.

Author: Grigorios Kyriakos Agathangelidis
Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης
Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.

I followed the same Leanpub-style logic as your NEXUS-1 page: strong opening question, clear bridge for the target reader, “under the hood” explanation, transparent boundary, and reader positioning. (Leanpub)

About the Book

Have you ever looked at a reactor-kinetics screen and wondered why the equations have the shape they do?

You see neutron power, delayed-neutron precursor groups, reactivity, Doppler feedback, moderator feedback, xenon poisoning, and a live numerical solver. The deterministic behaviour looks smooth and continuous. But underneath that smooth curve stands a more fundamental stochastic picture: neutrons are born, removed, counted, and lost through a chain of random events.

From Queue to Core is written to make that hidden bridge visible.

This book explains how the classical birth–death process from queueing theory and continuous-time Markov chains can be used as a disciplined stochastic foundation for understanding reactor kinetics. It does not claim that a reactor is literally a queue. Instead, it uses the birth–death process as a clean mathematical language for neutron-population dynamics: births correspond to fission-created neutrons, deaths correspond to absorption or leakage, and criticality becomes the balance between creation and removal.

The book then walks carefully from that stochastic picture toward the deterministic six-group point-kinetics model used in NEXUS-1. Along the way, it explains the master equation, extinction probability, startup intuition, delayed-neutron groups, mean-field collapse, feedback effects, and the difference between what a stochastic model can claim and what a deterministic engineering solver can claim.

This is a theoretical companion to the NEXUS-1 demonstrator, but it remains practical in spirit. The reader is not only shown equations; the book also includes worked examples, representative NEXUS-1 constants, interpretable comparison tables, and C# algorithms that implement the ideas step by step: a birth–death Monte Carlo path, a master-equation approximation, and a compact point-kinetics-style solver.

What This Book Covers

From Queue to Core develops the bridge in stages:

• why queueing theory is useful here, and where the analogy stops;
• how a birth–death process becomes a continuous-time Markov chain;
• how neutron populations can be interpreted as stochastic populations;
• why criticality, extinction, and startup are naturally probabilistic ideas;
• how delayed neutrons turn a prompt chain into a controllable reactor;
• how the master equation collapses into deterministic point kinetics;
• how the NEXUS-1 kinetics engine fits into this theoretical structure;
• how stochastic and deterministic models differ in meaning, cost, and claim;
• how the ideas can be implemented in clear, educational C# code.

What Is Under the Hood?

The book connects several layers that are often kept separate:

The stochastic layer
A reactor chain begins as a population process. Individual neutrons appear and disappear randomly. The birth–death model makes that population explicit.

The probability layer
The master equation tracks the probability of every possible neutron population. It is richer than a single trajectory, but also more expensive.

The deterministic layer
Point kinetics tracks the mean behaviour of the neutron population and delayed-neutron precursor groups. This is the layer that becomes practical for a live simulator.

The feedback layer
Doppler feedback, moderator feedback, xenon poisoning, and control input explain why reactor kinetics is not just exponential growth or decay. Feedback turns a chain into a regulated physical system.

The implementation layer
The C# appendix shows how the models can be translated into interpretable algorithms. The purpose is not reactor-control software; the purpose is executable understanding.

Who This Book Is For

This book is for software engineers, C#/.NET developers, systems architects, control engineers, mathematically curious readers, and advanced learners who want to understand the mathematical parentage of the NEXUS-1 kinetics engine.

You do not need to be a nuclear engineer to read it. Some familiarity with probability, differential equations, or simulation helps, but the book is written with the same NEXUS-1 teaching rule used throughout the series: explain the bridge before asking the reader to cross it.

Honest Boundary

This book is not a nuclear-safety manual, not a validated neutronics code, not certified simulation software, and not operational guidance for any real facility. NEXUS-1 remains a browser-based educational demonstrator. The value of this book is conceptual, mathematical, and architectural: it shows how stochastic thinking, deterministic reactor kinetics, and readable software implementation can be connected without pretending that the model is more than it is.

At its heart, From Queue to Core is about one idea:

A deterministic reactor-kinetics curve is not magic. It is the visible engineering shadow of a deeper stochastic chain.

This book is warmly dedicated to my good friend Alekos, with gratitude for his friendship, encouragement, and presence along the journey of turning difficult ideas into written form.

Author: Grigorios Kyriakos Agathangelidis
Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης
Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.

From Context to Flow is the advanced Domain-Driven Design bridge volume of the NEXUS-1 series. Where From Domain to Twin introduced the essential DDD vocabulary, this book takes the next step: it shows what happens when a domain model begins to move across boundaries as events, contracts, workflows, failures, retries, projections, audits, and delayed consistency.

This is not a microservices implementation guide. It is the book that should come before microservices. Its central question is simple:

Before we split a system into services, do we truly understand its boundaries, its language, its ownership, and its flows?

Using the NEXUS-1 digital-twin demonstrator as a coherent teaching system, the book follows a realistic architectural flow:

Alarm Raised → Alarm Flood Detected → Root-Cause Case Opened → Evidence Attached → Verdict Issued → Recommendation Generated → Audit Entry Written → Compliance Review Triggered

This flow crosses several bounded contexts: ReactorFleet, Instrumentation, AlarmManagement, RootCause, DigitalTwin, ReinforcementLearning, Audit, Compliance, and Reporting. That makes it an ideal environment for advanced DDD because every step forces a serious architectural question: who owns the rule, who publishes the event, who reacts to it, what must remain private, what becomes a public contract, and what happens when the next context is temporarily unavailable?

The book explains advanced DDD patterns in practical language: context maps, upstream/downstream relationships, customer/supplier relationships, conformist relationships, shared kernel, anti-corruption layers, published language, domain events, integration events, outbox, inbox, idempotency, dead-letter handling, process managers, sagas, compensation, timeouts, and eventual consistency.

It also draws a clear line between things that are often confused:

A domain event is not automatically an integration event.
An audit entry is evidence, not workflow.
A bounded context is not automatically a microservice.
A recommendation is not a command.
A projection is not the source of truth.
A retry is not a business decision.
A compensation is not a rollback.

Every chapter keeps the NEXUS-1 standing rule: nothing claims to exist that does not. The book does not pretend that distributed architecture is free. Every pattern is explained with its benefit, its cost, and its honest boundary.

This book is written for C#/.NET developers, software architects, and advanced learners who already understand the basics of DDD and want to move from modelling to architectural flow. It is especially useful for readers who want to understand how a modular system becomes ready for microservices without rushing into deployment boundaries too early.

By the end of the book, you should be able to look at a large system and ask better questions:

Which context owns this language?
Which aggregate protects this rule?
Is this event internal, external, or only an audit fact?
Does this workflow belong inside one application service, or does it need a process manager?
Is this dependency healthy, or does it require an anti-corruption layer?
Can this context become a microservice, or is it only a module with a fashionable name?

The goal is not to make the system more distributed.
The goal is to make the system more honest before distribution begins.

This book is dedicated to Eystathios Andreadis — my brotherly friend and an outstanding surgeon — who reminds us every single day that there are still people whose integrity, compassion, and dedication set them apart.

Author: Grigorios Kyriakos Agathangelidis
Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης
Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.

From Flow to Services is the architectural bridge between a well-designed modular application and a carefully designed microservice ecosystem. Rather than presenting microservices as the inevitable destination of every modern system, this book argues that distribution should be the consequence of mature boundaries—not the starting point.

Using the NEXUS-1 digital twin as a continuous case study, the book follows the evolution of a complex industrial software platform from advanced Domain-Driven Design into a realistic microservice architecture. Every architectural decision is examined through a single coherent system, allowing the reader to see not only what changes, but why those changes become necessary.

Across more than seventy chapters, the journey moves from service-boundary identification and data ownership to public contracts, asynchronous messaging, outbox and inbox patterns, sagas, eventual consistency, distributed workflows, observability, resilience, security, migration strategies, and operational readiness. Rather than presenting isolated patterns, the book demonstrates how these concepts reinforce one another inside a complete architecture.

One of the central themes of the book is intellectual discipline. It repeatedly challenges popular assumptions, showing why a bounded context is not automatically a microservice, why shared databases undermine service autonomy, why APIs must protect language rather than expose implementation details, and why every architectural benefit introduces corresponding operational costs. The objective is not to persuade the reader to adopt microservices, but to help them recognize when they have genuinely earned them.

Like every volume in the NEXUS-1 series, this book combines architectural theory with practical implementation. The explanations are grounded in C# and .NET examples while remaining focused on timeless architectural principles rather than framework-specific recipes. The emphasis is on reasoning, trade-offs, and design judgement instead of memorizing technologies.

Who This Book Is For

This is not an introductory book on software development, C#, or microservices.

It assumes that the reader already understands object-oriented programming, ASP.NET Core, relational databases, and the fundamentals of Domain-Driven Design. Familiarity with aggregates, bounded contexts, domain events, and clean architecture will significantly improve the reading experience.

The ideal audience includes:

• Experienced .NET developers moving from modular monoliths toward distributed systems.
• Software architects designing service-oriented platforms.
• Technical leads responsible for system decomposition and long-term architecture.
• Engineers who want to understand why architectural patterns exist before learning specific tools.

A Word About the Difficulty

This is one of the most demanding books in the NEXUS-1 series.

It deliberately avoids simplified "how-to" recipes in favor of architectural reasoning. Many chapters ask the reader to evaluate competing trade-offs, understand the costs of distribution, and think about language ownership, contracts, consistency, and operational responsibility simultaneously. Readers looking for quick implementation shortcuts may find the material challenging.

However, developers who invest the time will gain something more valuable than a collection of patterns: a structured way of thinking about distributed systems that remains applicable regardless of programming language, framework, or cloud platform.

Near the end of this journey, the reader should not simply know how to build microservices—they should understand when they should not.

This book is dedicated to my friend Anna, whose quiet encouragement, thoughtful attention, and genuine belief in both ideas and people became a reminder that every worthwhile journey is made possible by someone who chooses to listen.

Author: Grigorios Kyriakos Agathangelidis
Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης
Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.

Volume I built a core with no database and no web server, and dared you to call that a limitation. From Core to Contract is the volume where the database and the wire finally arrive — and the entire discipline is keeping them on their own side of the seam.

This is the second volume of the NEXUS-1 backend trilogy. It takes the fully tested Domain and Application layers built in From Blueprint to Core and gives them the two things Clean Architecture spends its whole life holding at arm's length: persistence and a public API. By the last page, EF Core is mapping an aggregate to real SQL Server tables, HTTP requests are flowing in and problem-details refusals are flowing back out, JWTs are being issued and validated — and not one line of that infrastructure has reached up past the boundary to change a rule the core already proved.

That restraint is the subject of the book. Anyone can wire up a DbContext and a controller. The hard part — the part most books wave through — is doing it so that the framework, the database, and the wire format stay below the seam, adapters to ports that were declared before any of them existed. This volume implements those ports against the exact 654 tables of the published schema atlas, across 17 bounded contexts, and it does so under the same standing rule that governs the whole series: nothing claims to exist that does not. Every project compiles, every class is shown in full, and every invariant is proven by a test that commits the exact crime the rule forbids and watches it fail by name.

It practices what it teaches. Every boundary decision is made once, in the open, and then held to. When the outbox needs a table of its own in Chapter 7, it doesn't quietly appear — it is admitted as a lawful Infrastructure citizen by amending, on the page, the very statute Chapter 2 wrote to keep Infrastructure out of the Domain's tables. When an earlier chapter's own code needs correcting, the fix happens in a visible diff, not in silence.

It shows its refusals, not just its successes. Optimistic concurrency isn't asserted — it's watched, with two real database connections racing for the same row until one loses by name. A DTO leak is proven by shipping the domain-carrying type on purpose and reading the leak back as JSON. Refusals cross the wire as RFC 7807 problem details carrying the platform's published refusal codes, so the client sees the same "no" the core meant.

It draws what it explains. Eighteen chapters are each followed by a two-page Deep Dive companion — plain-language explanations and original UML for readers newer to persistence, EF Core, web APIs, tokens, and authorization, adding floors under the material without lowering the technical ceiling above it. A recurring "Where We Are in the Solution" panel tracks the growing codebase, the migration's table count, and the test total, so you always know exactly how much of the system exists at any page.

It knows exactly what it hasn't built yet. The book closes with an Epilogue — The Honest Boundary of Volume II — an itemized account of what is deliberately deferred (the outbox dispatcher, the integration harness, logging, configuration environments, health checks, the container) and which volume owns each one. The seam to Volume III is stated in plain sight; it is part of the design, not an omission.

• Part I — The Persistence Boundary. The NexusDbContext wired to the configuration atlas of From Entity to Context; repositories as three-line adapters behind Volume I's ports; the Unit of Work with its after-commit dispatch clause; optimistic concurrency armed by a single typed RowVersion; the write half of the outbox; and migrations and seeding that build to the exact tables of the schema atlas.
• Part II — The API Layer. The composition root completed; controllers kept honest by a thinness statute; DTOs and the three-vocabularies translation that keeps the Domain off the wire; refusals as RFC 7807; idempotency as a pipeline behavior; and versioning behind a browsable, honest Swagger contract.
• Part III — The Security Context (The Closing Act). Operators and roles modeled in code; JWT issuance and validation; and authorization where OperatorId is no longer taken on faith but carried, checked, and enforced.
• Part IV — First Light. One operational night, traced end to end over a real wire — the whole stack the book has built, from HTTP request to persisted twin and back, in a single run that proves the layers actually meet.
• Five appendices — an installation guide, the full Volume-II solution skeleton, the tools-and-packages ledger, the bounded-context → schema → DbContext map, and the refusal-code → HTTP-status registry — plus source references, a glossary, and an index.

Developers who have read a Clean Architecture or DDD book and then hit the question those books skip: how do you add a database and an HTTP API without the framework leaking upward into the rules you worked so hard to isolate? Architects who want a fully worked persistence-and-API layer to hold their own team's decisions against. And readers of Volume I who want to watch the ports finally get their adapters.

Volume I is a companion, not a prerequisite — but this book assumes a tested Domain and Application core already exists, and From Blueprint to Core is where that core was built. Everything you need to follow this book's code is inside it.

Author: Grigorios Kyriakos Agathangelidis

Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης

Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.

Most books that teach deployment show you a green checkmark and ask you to trust it. From Contract to Container shows you the checkmark, then makes you prove what's behind it — a real database, a real container, and a gate that will not lie.

This is the third and closing volume of the backend trilogy that builds NEXUS-1, a fictional Phase-0 nuclear-plant digital twin, from a proven Domain and Application core (Volume I) through a real Infrastructure and API layer (Volume II) to a system that ships. Seventeen chapters take the codebase from two hundred tests to a running container answering its own health probes — without a mock standing in for the database, without an assumption standing in for a real failure, and without a claim that outruns what the suite actually proves. By the last chapter, a real SQL Server has been stood up and torn down on every single test run, a dispatcher delivers at-least-once and turns that into an exactly-once effect, every refusal the system can produce carries a correlation id, and a CI gate will not package an image unless the entire suite is green.

That absence of shortcuts is not caution for its own sake. It's the argument. A system that "works" against a fake database or a stubbed dependency hasn't been proven — it has been rehearsed. This volume's whole discipline is refusing that substitute: the harness in Part I runs every integration test against a disposable, genuine SQL Server; the dispatcher in Part II is watched failing under a killed process before it is trusted to recover; the observability in Part III is proven by triggering the exact failure it claims to report; and the container in Part IV is shipped only once a gate — not a developer's judgment — has verified it.

What Makes This Book Different

It tests against the real thing, not a stand-in. Every integration test in this book runs against a genuine, disposable SQL Server under Testcontainers — never a mock, never an in-memory substitute. If a query is wrong, the test finds out the way production would.

It watches its own promises fail. Every invariant this book claims — a retry budget, a health probe, a refusal shape — is demonstrated twice: once holding, and once deliberately broken in a test and watched to fail. A guarantee that has never been watched failing is not yet a guarantee.

It closes its own debts in writing, and updates them when it can't. Chapter 1 opens by reading Volume II's debt ledger back as a promise, chapter by chapter. The closing Epilogue reads that promise back a second time — and when one row can no longer be kept as written, the book corrects it on the page rather than letting it quietly disappear.

It audits itself across chapters, not only within them. The back matter doesn't just summarize what earlier chapters built — it cross-checks them against each other, and names what it finds, including a real wiring gap between the CI pipeline and the Dockerfile that no single chapter, read alone, would have caught.

It knows exactly what it hasn't built yet. The trilogy closes on an Epilogue titled The Honest Boundary of the Trilogy — a final, itemized account of everything three volumes still do not do, with nothing deferred to a future book that does not exist.

What's Inside

• Part I — The Harness. The seam inherited from Volume II, a real disposable database, the API exercised in process, a full choreographed night proven under load, and every refusal the system can produce asserted over the wire.
• Part II — The Dispatcher. A hosted worker that drains an outbox table, delivery with exponential backoff and quarantine for the message that can't be delivered, the wiring that finally activates two reactions Volume I could only describe, and the inbox pattern that turns at-least-once delivery into an exactly-once effect.
• Part III — Observability. Structured logging with Serilog, a correlation id threaded through an entire request, a refusal that is counted and explained rather than merely returned, and the liveness/readiness split that lets an orchestrator drain traffic without restarting a healthy process.
• Part IV — Configuration & the Container. Layered configuration and secret rotation, a multi-stage Dockerfile that ships one image to every environment, a CI gate that will not package a red build, and a deployed container proven against a killed database.
• Six back-matter chapters — an Epilogue that closes the trilogy's own debt ledger, an installation and run guide, the full solution skeleton, the tools-and-packages manifest, the outbox-to-reaction map, and the complete configuration and secrets matrix, plus source references, a glossary, and a page-verified index.

Who This Book Is For

Developers who have built (or read) a clean, layered backend and want to see it proven against real infrastructure and actually shipped — not just described as production-ready. Engineers who want a worked, honest example of a CI gate, a retry-and-quarantine dispatcher, and a health-probe contract, built end to end rather than assembled from framework defaults. And anyone who has finished an architecture book with a working core and wondered what it actually takes to trust that core outside a debugger.

Volumes I and II are companions, not prerequisites for the code in this book — every class this volume builds on is named and explained where it first matters. But the trilogy's ledger, and the weight of what gets closed here, land hardest if you've read the debt this volume was written to repay.

About the NEXUS-1 Companion Series

From Contract to Container is the closing volume of the NEXUS-1 backend trilogy, part of the wider NEXUS-1 Companion Series — a set of books that teach software architecture, data design, and applied AI through one consistent fictional demonstrator: a Phase-0 digital twin of a nuclear power plant. Every volume shares the same standing boundary — NEXUS-1 is a teaching platform, never operational guidance, and nothing in the series claims authority over a real facility. This volume completes the backend, begun in From Blueprint to Core (Domain and Application) and continued in From Core to Contract (Infrastructure and the API); the trilogy closes with a Phase-0 demonstrator, proven and shipped, and an honest account of everything it still does not do.

Author: Grigorios Kyriakos Agathangelidis

Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης

Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.

From Flow to Proof is a bridge between advanced software architecture and formal reasoning.

Modern distributed systems make promises that ordinary architecture diagrams cannot fully express. They promise that committed information will not disappear, repeated delivery will not repeat a business effect, temporary inconsistency will not become corrupted truth, ownership boundaries will remain intact, and failures will eventually become either recovery or visible evidence.

These are not merely questions about components, APIs, databases, or message brokers. They are questions about system behavior across time, concurrency, translation, and failure.

This book shows how those architectural promises can be stated explicitly, examined systematically, and supported by evidence.

Using the NEXUS-1 digital twin as a continuous architectural setting, From Flow to Proof explores how complex systems can be understood as stateful models whose transitions, contracts, responsibilities, and failure paths are open to inspection. The purpose is not to turn software architects into academic mathematicians, nor to use formal notation as decoration. The purpose is to give engineers a stronger language for claims that prose, diagrams, and ordinary tests often leave dangerously ambiguous.

The book introduces several complementary ways of examining architecture. State machines make lifecycle and forbidden transitions visible. Contracts clarify what individual operations require and guarantee. Temporal reasoning addresses what must never happen and what must eventually happen. Concurrency models expose parallel behavior, waiting, and possible deadlock. Relational models examine ownership, access, and authority. Meaning-preserving mappings ask whether information remains truthful as it crosses boundaries. Refinement connects these perspectives to a central engineering question:

Can a more detailed implementation safely stand in for the architectural promise made by a simpler specification?

These methods are not presented as disconnected mathematical subjects. They are coordinated around one proof-oriented architectural method and one recurring concern:

What exactly has the system promised, and what evidence justifies believing that the promise survives time, failure, translation, and distribution?

The book remains firmly grounded in software engineering. Formal notation is introduced only after the architectural pressure is visible. Important concepts begin in ordinary language, become explicit models, are connected to realistic distributed-system concerns, and are then challenged through broken cases, counterexamples, or deliberately weakened designs.

The reader is not asked merely to trust a pattern. The reader is asked to understand what the pattern protects, what assumptions it depends on, what evidence supports it, and where its protection ends.

A central discipline of the book is its careful use of the word proof. A checked model is not presented as proof that production code, infrastructure, operators, networks, or the physical world will behave perfectly. Models omit details. Implementations may drift. Tests cover selected executions. Monitoring observes only what has been instrumented.

Formal methods strengthen architectural reasoning, but they do not remove engineering responsibility.

For this reason, From Flow to Proof repeatedly distinguishes model evidence from implementation evidence. It connects specifications to contracts, code, tests, database constraints, execution traces, audit records, and operational observations, while preserving an explicit and honest boundary around every conclusion.

The result is not simply a collection of formulas, notations, and tools. It is a proof-oriented way of thinking about architecture.

By the end of the journey, the reader should be better prepared to ask:

• What states and transitions does this design really permit?
• Which outcomes must never occur?
• Which outcomes must eventually occur?
• What assumptions are hidden inside a reliability claim?
• Who owns each piece of truth?
• Can information cross a boundary without changing its meaning?
• Does the implementation preserve the promise of the model?
• What remains uncertain or unproven?

The objective is not to make architecture sound certain. It is to make architectural confidence more disciplined, reviewable, reproducible, and honest.

Companion Artifacts

The book is supported by practical artifacts available in the NEXUS-1 project repository:

github.com/gregory82gr/Nexus-1-phase-0

Readers can use the repository alongside the book to inspect the technical materials that support its arguments. Depending on the relevant chapter, these materials may include model definitions, executable checks, structured catalogues, code examples, machine-readable records, diagrams, verification inputs, and supporting evidence artifacts.

The repository is not a substitute for the explanations in the book. It is the practical companion to them.

The text explains the architectural pressure, the modelling decision, the property being examined, the assumptions behind it, and the honest boundary of the result. The repository allows the reader to inspect and work with the corresponding artifacts directly.

This combination is important because From Flow to Proof does not ask the reader to accept formal claims only because they appear in print. Where executable or inspectable evidence exists, the reader is encouraged to open it, examine it, modify it, and observe what happens when an assumption, guard, invariant, or relation is removed.

The artifacts also make the book a useful foundation for future automation. Its structured properties, contracts, formal models, counterexamples, catalogues, refinement records, and evidence descriptions can support later work with domain-specific language models and AI-assisted engineering workflows. Such automation must remain governed, evidence-based, and subordinate to deterministic checks and human responsibility.

The intended direction is not artificial authority.

It is artificial assistance with an honest boundary.

Who This Book Is For

This is not an introductory book on programming, databases, or basic software design.

It is written primarily for experienced developers, software architects, technical leads, and engineers working with systems whose behavior extends beyond one process, one database, or one transaction.

The ideal reader may already understand application development, APIs, relational databases, testing, and object-oriented design, but may have little or no previous experience with formal methods. Advanced mathematical knowledge is not assumed. The necessary concepts are introduced gradually and connected to recognizable engineering problems before formal notation is used.

The book is especially relevant for:

• Backend and .NET developers moving toward distributed-system architecture.
• Software architects responsible for reliability, consistency, ownership, and integration boundaries.
• Technical leads reviewing event-driven workflows and microservice decompositions.
• Engineers working with audit-heavy, regulated, safety-adjacent, or high-accountability software.
• Readers who want to understand what formal methods can contribute without pretending they can prove everything.
• Teams exploring model-based verification, continuous architectural evidence, or domain-specific AI assistance.

Readers familiar with Domain-Driven Design, asynchronous messaging, outbox and inbox patterns, sagas, eventual consistency, projections, and independent data ownership will recognize many of the architectural pressures. However, mastery of those topics is not assumed. Where an idea is load-bearing, it is explained or explicitly recalled before being used.

A Word About the Difficulty

This is the most demanding volume in the NEXUS-1 series.

Its difficulty does not come only from mathematical notation. It comes from the need to think about architecture, behavior, time, failure, ownership, concurrency, meaning, and evidence at the same time.

The book deliberately avoids reducing formal methods to a few attractive diagrams or copying tool syntax without explaining the underlying engineering question. It asks the reader to distinguish:

• Safety from liveness.
• Delay from silent loss.
• Temporary inconsistency from corrupted truth.
• Valid abstraction from misleading simplification.
• Model evidence from implementation evidence.
• Confidence from certainty.

That requires patience.

Some chapters are designed to be read slowly. Definitions matter. Assumptions matter. A small change in a property may completely change what has actually been claimed. Readers looking only for quick recipes or a short catalogue of best practices may find the book unusually demanding.

However, the book is designed not to abandon the reader. Important concepts begin with ordinary examples. The same architectural concerns return under different formal lenses. Understanding accumulates instead of restarting with every new notation. Counterexamples are treated as teaching instruments rather than as failures.

The companion repository also gives the reader a practical path beyond the page. Concepts can be connected to concrete artifacts rather than remaining purely theoretical.

Those who complete the journey should gain more than familiarity with particular tools. They should gain a reusable method for turning architectural promises into explicit questions, selecting appropriate evidence, identifying hidden assumptions, exposing counterexamples, and stating conclusions with greater precision.

The book does not promise certainty.

It teaches calibration.

This book is dedicated “… to my parents…”

Author: Grigorios Kyriakos Agathangelidis
Greek name: Γρηγόριος Κυριάκος Αγαθαγγελίδης
Also searchable as: Αγαθαγγελίδης Γρηγόριος, Αγαθαγγελιδης Γρηγοριος, Grigorios Agathangelidis.