Skip to content

2026 Organisation Proposal

Executive Summary

This document will inform how organise work better across engineering, design and product creation, while reducing syncronized operational work (Sprint Review and Planning calls, updates) and maximizing the quality of work, allowing small steps leading to big outcomes using versioned thinking and iterative work. The proposal is divided in two parts: business goals and technical arhcitecture.

Business Goals

Departure Point

TTI does not have in-house Engineering staff and relies on fractional CISO and Software Architect functions.
Building TTI's P4P software suite is entirely outsourced to esatus. P4P relies on core functionality of SOWL, a esatus product.
As esatus acts both as in-house engineering and a supplier, roles and boundaries are blurred (Conway's Law).
This presents unique and complex challenges in RFI/RFP context where existing products and assets should be clearly identified, as future work is often owned by the RFP issuer.

Ambition

Starting 2026, SOWL and P4P will be developed and maintained in separate environments. Code, documentation, design and other artifacts will be air-gapped across different registries, with clear rules how they connect and interact.

Goals. We would like to...

  • Depart from Sprints and organize around artifacts and outcomes.
  • Reduce operational and coordination overhead.
  • Systematically improve by documenting our goals through specifications.
  • Use specifications to iluminate and inform scope and then price it. Budget may be monetary, time, attention or attached to deliverables and outcomes.
  • Use clear criteria to accepting deliverables.
  • Use change requests when deviating from specifications.
  • Use best practices in maintainting and evolving code, documentation, design and other assets.
  • Define boundaries and connectors for each component to inform customer-facing decisions.

Proposed organisation as of Jan 2026

Specification is the first document in every discussion, scoping the desired goals and outcomes.
Specification will be reviewed jointly, improved and finalized as input to effort estimation.
Specification should, at a minimum, include scope, owner, hosting/layer attribution, access control, deliverable, acceptance criteria and target timeline.
Effort estimation is bound to the specification.
Change requests follow the same path as specification, if scope is amended.

Proporsed Architecture for 3-Layer Ownership

1. Architectural Strategy

This proposal defines a federated development environment that balances the proprietary retention needs of Esatus (E) with the sovereignty and transfer requirements of TTI (T) and its national clients (C). The system is divided into three distinct logical layers [1]. These layers are distinguished not only by functionality but by infrastructure hosting and ownership models.

To satisfy the requirement that national layers can be eventually transferred to client ownership, the architecture utilizes a hybrid infrastructure approach. While the core layer remains within E's existing environment, the upper layers are decoupled and hosted on neutral ground [2].

2. Layer Definitions and Hosting

Layer 1: SOWL Core (The Foundation)

  • Scope: Proprietary decentralized identity technology, issuer/verifier modules, and core subsystems.
  • Owner: Esatus.
  • Hosting Platform: Azure DevOps (ADO).
  • Access Control: Strictly internal to E. No external source code access is granted to T or C [3].
  • Deliverable: Immutable, versioned build artifacts (e.g., NuGet packages, Docker containers) published to a secure, private Artifact Feed.

Layer 2: P4P Platform

  • Scope: Government identity logic, adaptation of SOWL for national use cases, etc.
  • Owner: TTI.
  • Hosting Platform: GitHub.
  • Access Control: T is the administrator. E is a maintainer.
  • Input: Consumes Layer 1 artifacts via the Artifact Feed. Does not consume Layer 1 source code.
  • Deliverable: Enhanced build artifacts published to a TTI-managed Package Registry [4].

Layer 3: National Implementation (The Variant)

  • Scope: Country-specific UI, localization, branding, and configuration.
  • Owner: TTI (initially) -> a particular C (upon handover).
  • Hosting Platform: GitHub.
  • Access Control: TTI maintains the repository. E is a contributor/maintainer. C may eventually assume Administrator privileges.
  • Input: Consumes Layer 2 artifacts.

3. Dependency and Release Management

The Air-Gap Integration

Integration between Layer 1 (ADO) and Layer 2 (GitHub) occurs solely through artifact consumption. There is no source code bridging. Layer 2 contains a definition file (e.g., nuget.config) that points to the secure feed where Layer 1 publishes its binaries [5].

Promotion Logic

Releases follow a strict bottom-up promotion methodology. A release at a higher layer cannot occur without a stable, versioned release from the layer immediately below it. 1. SOWL Release: E triggers a build in ADO. Resulting artifacts are tagged (e.g., v1.0.0) and pushed to the Feed. 2. P4P Release: TTI (or E acting as maintainer) updates the dependency version in the Layer 2 GitHub repository to match SOWL v1.0.0. A GitHub Action builds the new P4P version. 3. National Release: The National Layer dependency is updated to consume the new P4P version [6].

Documentation Strategy

Documentation is treated as code. Technical documentation resides as Markdown files within the repository of the layer to which it pertains. When a layer is built, the documentation is packaged alongside the binary artifacts, allowing upper layers to inherit and render documentation from the layers below [7].

Release Initiation vs. Execution

While the build chain is strictly bottom-up, the release process is often initiated top-down. A requirement for a new release at the National Layer (Layer 3) triggers a "Demand Signal" (e.g., a ticket or workflow dispatch) to the lower layers. This signals the maintainers of Layer 1 or Layer 2 to generate the required artifacts. This ensures that client needs drive the release schedule, even though the code must flow upwards [8].

Endnotes and Design Rationale

[1] Three Logical Layers: The separation into SOWL, P4P, and National layers is necessary to navigate the intellectual property landscape. It isolates the proprietary tech (SOWL) from the commercial product (P4P) and the sovereign assets (National). This ensures that when a country buys a system, they own their specific customizations without polluting the core product or accessing the vendor's trade secrets.

[2] Hybrid Infrastructure (ADO + GitHub): The proposal rejects a monolithic hosting strategy. While Esatus undoubtedly prefers Azure DevOps (ADO) for internal efficiency, TTI requires a platform that supports easy divestiture. Moving the top two layers to GitHub allows TTI to hand over a repository to a nation state simply by transferring administrative ownership or mirroring the repo, which is a key requirement. Keeping everything in ADO would require integration of C into esatus AD.

[3] Layer 1 Access Control: Esatus retains full ownership of the SOWL layer. By keeping this in their existing ADO environment, they maintain their preferred security perimeter and development velocity. TTI does not require source access here, only artifact access.

[4] Artifact-Based Handoff: To bridge the divide between ADO and GitHub, we rely on immutable artifacts rather than shared git submodules. This enforces a clean air gap. Layer 2 (GitHub) effectively treats Layer 1 (ADO) as a third-party vendor library. This aligns with the requirement that a layer knows only about the artifacts below it, not the internal development state.

[5] Configuration vs. Code: Managing the connection via configuration (e.g., nuget.config) rather than hard-coded pipeline bridges reduces operational friction. It allows the CI/CD pipelines in GitHub to be standard and portable, rather than heavily customized to talk to a specific Azure tenant.

[6] Bottom-Up Promotion: Strict adherence to bottom-up releasing ensures stability. By forcing Layer 2 to explicitly update its dependency version to consume a new Layer 1 release, we prevent silent breaks where an upstream change automatically breaks the downstream build. This gives TTI (the auditor) a specific commit to review whenever the underlying platform changes.

[7] Documentation inheritance: Since documentation lives in Markdown within the code repos, it can be versioned with the software. Packaging it with the build artifacts ensures that a C receives a comprehensive documentation bundle that corresponds exactly to the version of the software they are running.

[8] Demand Signaling: We distinguish between triggering a need (Top-Down) and triggering a build (Bottom-Up). Automating a full top-down build chain (where a Layer 3 click forces a Layer 1 build) introduces "coupling" that defeats the security and stability goals of this architecture. Instead, a top-down signal alerts the maintainers to execute the bottom-up protocol.