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

Abstract

Federated computing (FC) enables collaborative computation such as machine learning, analytics, or data processing across distributed organizations keeping raw data local. Built on four architectural pillars, distributed data assets, federated services, standardized APIs, and decentralized services, FC supports sovereignty-preserving collaboration. However, federated systems spanning organizational and jurisdictional boundaries lack a portable mechanism for enforcing sovereignty-critical constraints. They often depend on runtime policy evaluation, shared trust infrastructure, or institutional agreements that introduce coordination overhead and provide limited cryptographic assurance. Federated Computing as Code (FCaC) is a declarative architecture that addresses this gap by compiling authority and delegation into cryptographically verifiable artifacts rather than relying on online policy interpretation. Boundary admission becomes a local verification step rather than a policy decision service. FCaC separates constitutional governance from procedural governance. Admission is validated locally at execution boundaries using proof-carrying capabilities, while stateful services may still implement post-admission controls such as ABAC, risk scoring, quotas, and workflow state. FCaC introduces Virtual Federated Platforms (VFPs), which combine Core, Business, and Governance contracts through a cryptographic trust chain: Key Your Organization (KYO), Envelope Capability Tokens (ECTs), and proof of possession (PoP). We demonstrate the approach in a proof-of-concept cross-silo federated learning workflow using MNIST as a surrogate workload to validate the admission mechanisms and release an open-source implementation showing envelope issuance, boundary verification, and envelope-triggered training.

Figures (5)

• Figure 1: FCaC Admission: identity establishes who, authorization defines what, and FCaC binds under which authority via locally verifiable artifacts.
• Figure 2: FCaC architecture across Core, Governance, and Business contracts. FCaC binds Core services and Business interactions through proof-carrying artifacts derived from declarative contracts. At runtime, the boundary check is a verification step (artifact validity, possession binding, and capability match), not an online policy evaluation service. This yields a shared declarative model for infrastructure and policy automation, while keeping workflow and domain logic inside Core and Business components.
• Figure 3: FCaC cryptographic trust chain: Key Your Organization (KYO), Envelope Capability Tokens (ECTs), and Proof-of-Possession (PoP)
• Figure 4: Minimal illustrative fragment of a policy.json file. The example shows the main policy elements used by FCaC—operation set, capability profiles, default capability assignment, caveats, and policy metadata—while omitting the additional fields and detail present in the full policy used in the proof of concept.
• Figure 5: Deployment mode of federated governance regimes (FC $\to$ Hybrid $\to$ FCaC). Stateful-only federations form a limiting case (a degenerate FCaC) in which admission is mediated by stateful control planes. FCaC targets regimes where admission must remain portable across domains through locally verifiable artifacts.