Introduction

Go To Top

The Phase 0 Developer Handbook defines the practical implementation guidance for creating the first executable Baseline of the Financial Systems Archetype. It is intended to help the team move from architectural definition to repeatable development practice without losing the structure, Traceability, and governance established in the preceding parts.

Phase 0 focuses on a deliberately limited implementation objective: to create a working Node network that can be built, run, stopped, inspected, and explained. The initial Baseline is centred on Repository structure, generated Artifacts, DDS/IDL type generation, containerised execution, basic Node Lifecycle behaviour, Control Plane status reporting, and developer Workflow. It is not intended to implement the full financial semantics, full ACTUS processing, full Policy enforcement, production Security, or enterprise Deployment model.

This handbook should be used by developers, architects, reviewers, and demonstration team members as the operational companion to the architecture documents. It identifies how implementation Artifacts should be organised, named, generated, documented, reviewed, and Validated. It also defines the practical expectations for scripts, Configuration files, logs, containers, and Node behaviour, so that the Phase 0 Baseline can be reproduced consistently by different team members.

The handbook does not replace the architectural source documents. Parts 1 through 4 remain authoritative for conceptual framing, distributed logical architecture, the FX Demo Logical Profile, and implementation source material. This handbook translates those sources into development conventions and execution practices. Where architectural meaning is required, the architecture documents should be consulted. Where implementation discipline is required, this handbook should be followed.

The main goal of Phase 0 is to establish confidence. By the end of this phase, the team should have a Repository that can be checked out, prepared, built, executed, observed, and reviewed. The resulting Baseline should demonstrate that the project can move from model-driven architectural reasoning to a working, disciplined, and inspectable demonstration Execution Environment.


© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.