Part VI — Reading the five projects together
Each of Parts I–V answers one question in one domain. This part reads them side by side. It is written for the book and makes no new claims about the projects. Every statement about a project refers to its pinned revision and to the chapters where that project teaches it.
The comparisons are organised around engineering questions, not projects:
| Chapter | Question |
|---|---|
| Capability, permission and authority | What can a component cause, what may it do, and who makes a decision binding? |
| Runtime state, domain state and audit history | Which store answers "what is true now?" and which answers "what happened?" |
| Approval boundaries and exact-action binding | What exactly does a human approve, and what re-checks it? |
| Idempotency, replay, concurrency and recovery | What happens when the same action arrives twice, or after a crash? |
| Technology choices follow boundaries | Why five projects use four languages and three agent runtimes |
| What is integrated, and what is only designed | Which connections between the projects exist in code today |
The part ends with a design exercise: an agent proposes a payment, and you design its path from proposal to settlement across the architectures. It is an exercise. The integrated system it describes does not exist.
One pattern, five times
Read together, the projects repeat one shape:
flowchart LR
M["Model<br/>interprets · proposes"] -->|"typed request<br/>(capability)"| B["Boundary<br/>tool surface · identity"]
B -->|"proposal"| P["Deterministic policy<br/>rules · Ash policies · state machine"]
P -->|"needs consent"| H["Human decision<br/>bound to the exact action"]
H -->|"signed / exact approval"| V["Point of mutation<br/>lock · re-derive · verify"]
V --> S[("State + audit<br/>one transaction")]
The details vary from project to project:
- Part I stops at the boundary unless an approval is enabled.
- Part II has no approval at all; its subject is what happens to this flow over time.
- Part III makes consent mandatory and the policy versioned.
- Part IV replaces the human decision with the absence of any authority-bearing tool: there is nothing to approve because nothing can move value.
- Part V puts policy and lifecycle in the domain layer, the same for every interface.