Federated Computing as Code (FCaC): Sovereignty-aware Systems by Design

1. Problem Statement

Federated Computing (FC) enables collaborative analysis (e.g., machine learning, analytics) across distributed organizations while keeping raw data local. However, current FC implementations face a critical gap in cross-boundary governance:

• Lack of Portability: Existing systems rely on runtime policy evaluation, shared trust infrastructure, or institutional agreements. These mechanisms fail when crossing organizational or jurisdictional boundaries where no central authority exists to enforce delegation constraints.
• Brittleness and Auditability: Traditional access control (RBAC/ABAC) and policy engines depend on mutable state and shared context. Reconstructing audit trails ("Why was this allowed?") is often impossible or unreliable because decisions are inferred from logs rather than verified directly.
• Federation Drift: As partners and toolchains change, admission semantics drift, leading to ad-hoc integrations and a loss of consistent governance.
• Derived Output Risks: Current models often implicitly authorize access to derived outputs (predictions, embeddings) based on participation, creating risks of data leakage even if raw data never moves.

The core challenge is how to enforce sovereignty-critical constraints (permission to execute and delegate) across independent domains without relying on a centralized runtime policy engine.

2. Methodology: Federated Computing as Code (FCaC)

The authors propose FCaC, a declarative architecture that transforms sovereignty constraints into cryptographically verifiable artifacts rather than procedural agreements. The methodology is built on four pillars and a strict separation of governance layers.

A. Architectural Principles

FCaC operationalizes four principles of Federated Computing:

1. Distributed Data Assets: Data remains local; only bounded computation is permitted.
2. Federated Services: Computation moves to data.
3. Standardized APIs: Interoperability across heterogeneous stacks.
4. Decentralized Governance: Multi-party control without a central authority.

B. Virtual Federated Platforms (VFPs)

FCaC organizes systems into Virtual Federated Platforms (VFPs) defined by three declarative contract classes:

1. Core Contracts: Define local execution, service topology, and infrastructure (e.g., where the model trains).
2. Business Contracts: Capture domain-specific intent, economic terms, and interaction semantics.
3. Governance Contracts: Specify allowed cross-boundary operations, authorities, and delegation structures. These compile into verifiable artifacts.

C. Separation of Governance

A central innovation is the distinction between two governance layers:

• Constitutional Governance (Boundary): Deterministic, stateless, and portable. It answers "Who is allowed to enter and under what scope?" This is enforced via Proof-Carrying Capabilities at the boundary.
• Procedural Governance (Internal): Stateful and context-dependent. It handles workflow, rate limiting, consent validation, and ABAC after admission. This remains local to the executing system.

D. The Cryptographic Trust Chain

To enforce Constitutional Governance, FCaC introduces a three-part trust chain (Figure 3 in the paper):

1. Key Your Organization (KYO): Anchors the sovereign identity of an organization. It uses mTLS and trusted execution environments (TEE) to prove key ownership, establishing the root of trust without relying on external identity providers.
2. Envelope Capability Tokens (ECTs): Portable, signed artifacts (based on JWTs) that express what is allowed. They are compiled from declarative contracts into a finite set of capability tuples (resource, action, scope, caveats). These tokens are immutable and define the outer limits of execution.
3. Proof of Possession (PoP): Realized via DPoP (Demonstrating Proof-of-Possession). It binds the capability to a specific execution event by signing the request with the holder's private key. This prevents token replay and ensures the entity using the token controls the associated key.

3. Key Contributions

1. Declarative Sovereignty: The shift from runtime policy interpretation to compile-time artifact generation. Authority and delegation are "compiled" into signed tokens (ECTs) that travel with the request.
2. Stateless Boundary Admission: The boundary verifier does not query a central database or policy engine. It performs local, deterministic verification of signatures, possession, and capability matching against cached trust anchors.
3. Constitutional vs. Procedural Separation: A clear architectural boundary that isolates cross-domain permission (Constitutional) from local operational control (Procedural), ensuring that cross-boundary decisions are reproducible and auditable regardless of backend complexity.
4. Virtual Federated Platform (VFP) Model: A framework for composing federated systems using Core, Business, and Governance contracts, linking infrastructure automation (IaC) with cryptographic governance.

4. Results and Validation

The authors validated the approach using a Proof of Concept (PoC) based on a cross-silo Federated Learning workflow using the MNIST dataset as a surrogate for clinical imaging.

• Implementation: The PoC demonstrated the full lifecycle:
  • Envelope Formation: Multi-party quorum approval to create a sovereign envelope.
  • Token Minting: Issuing ECTs with specific scope constraints (e.g., specific cohorts like "EVEN_ONLY" digits).
  • Boundary Verification: Local verification of ECTs and DPoP proofs at the entry point.
• Key Findings:
  • Deterministic Admission: The system consistently allowed or denied requests based solely on the presented artifacts and local trust anchors, independent of runtime state.
  • Scope Enforcement: Requests attempting to access data outside the authorized scope (e.g., wrong cohort or action) were deterministically rejected.
  • Tamper Resistance: Attempts to replay tokens or use mismatched keys (PoP failure) were rejected.
  • Separation of Duties: The UI demonstrated that admission (governance) is distinct from execution (prediction), with the backend enforcing additional local constraints only after admission.
• Limitations Identified: The PoC currently lacks immediate revocation mechanisms (relying on short validity windows), simulates key management rather than using hardware-backed HSMs, and treats envelope IDs as routing selectors rather than token-bound constraints.

5. Significance and Impact

• Sovereignty Preservation: FCaC provides a mechanism for organizations to collaborate across strict legal and jurisdictional boundaries without surrendering control to a central coordinator.
• Auditability: By making execution a "proof-carrying act," FCaC creates an immutable audit trail. Regulators can verify why an operation was permitted by inspecting the signed artifacts, rather than reconstructing logic from logs.
• Interoperability: It decouples governance from specific technology stacks or vendors. Since the enforcement surface consumes standardized, signed artifacts, different organizations can interoperate without aligning their internal policy engines.
• Future of Federated Systems: The paper argues that as data spaces and cross-border analytics grow, the industry must move from "policy-as-code" (which still often relies on centralized engines) to "governance-as-code" where authority is cryptographically bound to the data and computation itself.

In summary, FCaC offers a rigorous architectural discipline for building federated systems where sovereignty is not a policy assumption but a cryptographically enforced invariant at the system boundary.