Cross-silo federated learning has no audit standard. SWT3 procedures witness the governance envelope around each round without inspecting the gradients themselves.
Audience: Privacy engineers, data protection officers, healthcare AI teams, fintech ML engineers, cross-organization AI consortium leads, and regulators evaluating federated AI deployments.
Assessor Notice: SWT3 witness anchors record that specific governance and operational controls were active at a specific point in time. They do not replace the assessor's independent judgment, the regulator's interpretive authority, or the organization's obligation to implement substantive controls. Evidence of witnessing is not evidence of compliance.
Federated learning is deployed in production today. Pharmaceutical consortia use cross-hospital FL for drug interaction discovery. Financial institutions run cross-bank fraud detection models where no single bank sees the others' transaction data. Telecom operators optimize network performance across infrastructure providers. Mobile keyboards predict your next word using on-device training that never uploads your keystrokes.
The technique was designed to solve a privacy problem: train a shared model without centralizing data. It works. Data stays local. Gradient updates -- not raw records -- travel between participants and the aggregation server.
"Data stays local" solved the privacy question. It did not solve the governance question.
No participant in a cross-silo FL session has complete visibility into what influenced the resulting model. The aggregation server sees gradient updates but not the data that produced them. Each participant sees their own data but not how the global model weighted their contribution against others. The resulting model is a product of all contributions, but no single entity can fully account for it.
The July 2026 arxiv paper "Auditable Session Admission for Cross-Silo Federated Learning" formally catalogs the gap: no portable, auditable authorization standard exists for cross-organizational federated sessions. Organizations are running production FL with governance frameworks designed for centralized training -- frameworks that assume a single entity controls the data pipeline.
Under GDPR Article 26, all participants in a cross-silo FL session are joint controllers. The regulation is explicit: joint controllers must have "a transparent arrangement" determining their respective responsibilities for exercising data subject rights and providing required information.
But federated learning was designed to prevent any single party from seeing the other parties' data. That is the entire point of the architecture. The privacy guarantee and the joint controller obligation are structurally at odds.
This creates a paradox that no existing governance framework addresses cleanly: joint controllers who are architecturally prevented from knowing what they jointly controlled.
The joint controller arrangement says "we share responsibility." The FL architecture says "we cannot see each other's contributions." The audit trail says nothing -- because there is no standard for it.
Each participant can attest to their own data quality. Each participant can document their own preprocessing pipeline. But no single participant can attest to the quality of the combined model -- because the combined model is a function of contributions that are, by design, invisible to any individual contributor.
In centralized training, you know exactly what data trained your model. In federated learning, you do not -- and neither does any single participant. That is the point of FL: data never leaves its silo. But "data stays local" is a privacy property, not a governance property.
When an auditor asks "What data influenced this model?", the honest answer in FL is "contributions from N organizations, but no single entity can enumerate them." Under GDPR Article 26, every participant in a cross-silo FL session is a joint controller -- and joint controllers need evidence of what they jointly controlled. Under EU AI Act Article 10, training data quality must be documented, including for federated configurations.
SWT3 federated learning procedures witness the governance envelope around each round -- who participated, what aggregation method was used, whether consent was verified, whether data isolation held -- without inspecting the gradients themselves. The privacy guarantee is preserved. The governance gap is closed.
This is the key insight: SWT3 does not break FL's privacy model. It witnesses that the governance controls around each round were intact. The aggregation server records that 5 organizations participated in round 47, that FedAvg was the aggregation method, that all participants had verified consent, and that secure aggregation was enforced. None of that requires seeing any participant's data. But all of it is evidence that a regulator, auditor, or joint controller can independently verify.
| Regime | FL-Specific Requirement | Current Evidence Gap | SWT3 Evidence |
|---|---|---|---|
| GDPR Art. 26 | Transparent joint controller arrangement | No round-level participant accounting | AI-FL.2 session admission records org consent and count |
| GDPR Art. 35 | DPIA for high-risk processing | Cannot enumerate all data sources across silos | AI-FL.1 round provenance + AI-DATA.1 per participant |
| EU AI Act Art. 10 | Training data quality documentation | Aggregated model has no single data quality sheet | AI-FL.1 + AI-DATA.1 + AI-DATA.5 |
| Singapore IMDA MGF v1.5 | Multi-organization AI governance framework | No cross-org evidence standard for FL | AI-FL.2 + AI-ID.1 |
| HIPAA | BAA for PHI processing; minimum necessary | FL gradient updates may encode PHI signals | AI-FL.1 + AI-FL.2 + AI-DATA.5 |
| SR 26-2 | Model risk management (GenAI excluded) | Cross-institution model validation undocumented | AI-FL.1 + AI-FL.2 |
In cross-silo federated learning, N organizations -- hospitals, banks, telcos -- each hold local datasets that never leave their infrastructure. An aggregation server coordinates training rounds. Each round follows the same pattern: clients compute local gradient updates on their private data, transmit those updates to the aggregation server, the server applies an aggregation algorithm (FedAvg, FedProx, SecAgg), and distributes the updated global model back to all participants.
SWT3 witnesses two layers of this architecture:
Before training begins, the session admission record captures which organizations were admitted, that consent was verified for each participant, and that data isolation controls are in place. This is the governance configuration -- the "who is at the table and under what terms" record that GDPR Article 26 requires but that FL architectures have never standardized.
During each training round, the round provenance record captures the aggregation method, the round number, and the number of participating clients. This is the operational provenance -- the "what happened in round N" record that allows tracing model behavior to specific points in the training timeline.
Key boundary: SWT3 never inspects gradient updates. That would defeat FL's privacy guarantee. It witnesses the metadata envelope -- the "who, what, when" of each round -- not the "what data" inside each gradient. This means an auditor can verify governance without accessing any participant's private data. The privacy guarantee and the audit trail coexist.
What it records: Aggregation method code (FedAvg=0, FedProx=1, FedSGD=2, SecAgg=3, other=4), round number, participating client count.
What it proves: Each training round was documented with method, sequence, and participation count. The training timeline is reconstructable from round-level provenance.
Verify that the client count is consistent across rounds. A sudden drop in participating clients mid-session may indicate an unrecorded withdrawal. Compare the aggregation method in round 1 against later rounds -- a method change without governance authorization is a finding. For GDPR Art. 26 assessments, the client count per round should match the number of organizations in the joint controller arrangement.
What it records: Consent status (none=0, given=1, withdrawn=2), participating organization count, data isolation verification status (not verified=0, verified=1, unknown=2).
What it proves: The session governance configuration was documented before training began -- who was admitted, whether consent was explicit, and whether isolation was verified.
Request the session admission anchor for each FL session. Verify that the org count matches the joint controller arrangement. If the anchor shows more participants than the legal agreement covers, the arrangement is incomplete -- a GDPR Art. 26 gap. Check the data isolation field: "unknown" (2) means isolation was not verified before the session started.
What it records: Source identifier, record count, quality check status for each participant's local data contribution.
What it proves: Each participant in the FL session attested to their own data quality before contributing to the global model.
In FL, training data provenance is per-participant. Verify that every admitted organization produced at least one AI-DATA.1 anchor during the session. Participants without data provenance anchors contributed unattested data to the global model -- and under EU AI Act Art. 10, unattested training data is a documentation gap.
What it records: Synthetic fraction, generation depth, contamination check result.
What it proves: If synthetic data was used in FL (e.g., synthetic minority oversampling, data augmentation across silos), it was documented with provenance.
FL systems increasingly use synthetic data techniques to balance class distributions across silos. If any participant introduced synthetic data, verify that AI-DATA.5 anchors exist for the synthetic component. Unattested synthetic augmentation in FL changes global model behavior without governance evidence.
What it records: Client identity verification for each FL participant.
What it proves: Every contributing client in the FL session was identified and authenticated.
Verify that every client contributing gradients has a corresponding AI-ID.1 anchor. An unidentified client in an FL session is a Sybil risk -- a single participant masquerading as multiple clients to disproportionately influence the global model. For any session where AI-FL.1 shows N clients but AI-ID.1 shows fewer than N unique identities, flag the discrepancy.
| Clearing Level | FL Configuration | Required Attestations | Example Use Case |
|---|---|---|---|
| L0 (Analytics) | Cross-device, non-sensitive data | AI-FL.1 round summary | Mobile keyboard prediction |
| L1 (Standard) | Cross-silo, business data | AI-FL.1 + AI-FL.2 + AI-ID.1 | Cross-retailer product recommendation |
| L2 (Sensitive) | Cross-silo, regulated data | Full procedure set + AI-DATA.1 per participant | Cross-bank fraud detection, drug interaction discovery |
| L3 (Classified) | Cross-organization, national security | Full set + continuous per-round attestation | Defense intelligence fusion, critical infrastructure |
A pharmaceutical consortium runs cross-silo FL for drug interaction prediction. Five hospitals participate. Each hospital contributes gradient updates from their local patient records without sharing the records themselves.
After 200 rounds of training, the consortium notices that the global model is underreporting interactions between two specific medications. The clinical team suspects a data quality issue, but cannot identify which hospital's data is causing the bias -- because no single participant can see the others' contributions.
Without round-level provenance, the investigation stalls. The consortium knows something is wrong but cannot determine:
With AI-FL.1 provenance, each round's participant set and convergence metrics are recorded. The consortium traces the drift to round 134, where a convergence metric diverged from the trend. Cross-referencing with AI-ID.1, they identify that Hospital C's contribution in that round was anomalous. Hospital C investigates and discovers a systematic labeling error in their local drug interaction database -- a batch import that transposed two medication codes.
The fix is straightforward: correct the labels, retrain from round 133. But without round-level provenance, the consortium would have had to retrain from scratch -- or worse, deploy a model with a known but untraceable bias.
Regulatory implication: In regulated contexts, the inability to trace a model defect to a specific participant and round is not just an operational problem. Under GDPR, each joint controller is liable for the processing. Under FDA 21 CFR Part 11, the audit trail for a clinical decision system must be reconstructable. Without round-level provenance, neither obligation can be met.
| Procedure | GDPR Art. 26 | GDPR Art. 35 | EU AI Act Art. 10 | IMDA MGF v1.5 | HIPAA | SR 26-2 |
|---|---|---|---|---|---|---|
| AI-FL.1 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| AI-FL.2 | ✓ | ✓ | ✓ | ✓ | ✓ | |
| AI-DATA.1 | ✓ | ✓ | ✓ | |||
| AI-DATA.5 | ✓ | ✓ | ✓ | |||
| AI-ID.1 | ✓ | ✓ |
from swt3_ai import Witness
w = Witness(
api_key="axm_your_key_here",
endpoint="https://sovereign.tenova.io/api/v1/witness"
)
# Record session admission (before training starts)
w.witness("AI-FL.2", verdict="PASS",
factor_a=1, # consent: given
factor_b=5, # 5 participating organizations
factor_c=1 # data isolation: verified
)
# Record each training round
for round_num in range(1, 201):
w.witness("AI-FL.1", verdict="PASS",
factor_a=0, # aggregation: FedAvg
factor_b=round_num, # round number
factor_c=5 # 5 participating clients
)
# Record per-participant data provenance
w.witness("AI-DATA.1", verdict="PASS",
factor_a=1, # source documented
factor_b=12400, # record count
factor_c=1 # quality check passed
)
w.flush()import { Witness } from '@tenova/swt3-ai';
const w = new Witness({
apiKey: 'axm_your_key_here',
endpoint: 'https://sovereign.tenova.io/api/v1/witness',
});
// Record session admission
await w.witness('AI-FL.2', {
verdict: 'PASS',
factorA: 1, // consent: given
factorB: 5, // 5 participating organizations
factorC: 1, // data isolation: verified
});
// Record each training round
for (let round = 1; round <= 200; round++) {
await w.witness('AI-FL.1', {
verdict: 'PASS',
factorA: 0, // aggregation: FedAvg
factorB: round, // round number
factorC: 5, // 5 participating clients
});
}
await w.flush();Ready to witness federated learning governance? Create a free account to get your API key, or explore the SDK documentation for advanced configuration including batch witnessing and OTel export.