Regional Model Adaptation

Faster Market Entry for Regulated AI Vendors

Local performance uplift without raw data transfer Geo-specific remediation for deployed models

Federated fine-tuning · with privacy-preserving agents

Models age. Their data can’t leave the room. We refresh them anyway.

Vendors stop model drift. Clients keep raw data inside their perimeter. Only gradients, weights, and quality metrics travel between.

Try the live demo → Request a pilot

            vendor.py
            customer.py
          
fedtuna · sdk

# Vendor side — register the base model and validation set
from fedtuna import Project, BaseModel
import timm

model = timm.create_model("resnet50", pretrained=True)
project = Project.create(
    name="derm-classifier-v4",
    base_model=BaseModel(model),
    validation_set="./val/",
    quality_gate=EER(threshold=0.02),
)

# Stream training to TensorBoard / W&B
project.attach_logger("tensorboard")
project.attach_logger("wandb")

# Hand off to the customer perimeter
project.issue_client("acme-hospital")
# → Docker container, gRPC + TLS, no GPU required

Built for

Healthcare Banking & insurance Public sector Industry & inspection

SOC 2 — pending

// Live in your browser

Two roles, one workflow.

The same UI, two perspectives — vendor on the left, customer on the right. Bring up to 50 of your own images or use our sample dataset. Nothing leaves your browser raw.

ML VENDOR

classifier-v4.7

Round 3 / 5

Validation set18,000 images

Sendinggradients · weights

Receivinggradients

Raw data crossed— none —

Validation EER↘ ↗

gRPC
TLS

Gradients
only

CUSTOMER

your-dataset.zip

Round 3 / 5

Local images47 / 50

Sendinggradients · metrics

Receivinggradients

Raw data crossed— none —

Local EER (your data)↘ ↗

Launch the demo →

No signup. Sample data included · Up to 50 images · CPU only · Auto-deletes after the session.

How it works

Three movements, nothing else moves.

A working product, not a research framework. Setup typically under an hour. Customer-side hardware does not need a GPU.

Vendor connects

Open a project, register the base model and validation set. The customer receives a Docker container or SDK and installs it inside their perimeter.

SETUP · under an hour · gRPC + TLS

Customer trains locally

The customer points the container at their local data. Training runs on their hardware. CPU works; a GPU roughly doubles speed but is not required.

LOCAL · raw data never moves · CPU-friendly

Only gradients sync

Gradients, weight updates, and aggregated metrics travel between vendor and customer. A vendor-side quality gate accepts the new model only if validation holds.

SYNC · gradients + metrics · quality-gated

Privacy by construction

Agents that never see your data.

Most AI products say "we don't train on your data." That is a policy. FedTuna agents cannot see your data — by design. They live one layer above the perimeter, alongside the gradients and quality metrics that already cross the gRPC boundary. Raw images, transactions, signals, scans — those never leave the customer's machine to begin with. The agent doesn't have a path to them. There is nothing for Claude or any future model provider to "accidentally" log, fine-tune on, or leak.

This is the same architecture that makes federated fine-tuning work in the first place. We just extended it to the agentic layer.

Agent receives

Privacy-preserving artifacts only

gradient updates
weight deltas
aggregated quality metrics
drift statistics, embedding histograms
training session telemetry

Agent never receives

Raw customer data

images, scans, transactions
per-record features
per-record predictions
customer database rows
file contents inside the perimeter

Two layers, planned three to four

Specialized agents, one architectural shape.

Each agent has a narrow job and a narrow surface. They compose along the same federated boundary the platform is built on. First two are in development; third and fourth are scoped.

Layer 01 · monitoring

Drift & quality watchdog

Privacy-preserving observability for a deployed model.

Watches the federated boundary continuously. Compares score distributions and embedding statistics on the customer side against the vendor's reference distribution. Surfaces drift as soon as it begins, before quality regresses visibly downstream.

Score-distribution drift, by class
Embedding scatter, single- and double-sided
Quality-gate alerts with a recommendation, not an action

Operates on: gradients, statistics, metrics in development

Layer 02 · remediation

Fine-tuning conductor

Closes the loop without the human standing over it.

When Layer 01 confirms drift past tolerance, the conductor proposes a fine-tuning run. Picks hyperparameters from prior session history, kicks off a tune session on the same federated infra, monitors progress, validates against the quality gate, and either commits the new version or rolls back with a written rationale.

Hyperparameter selection from history
Session orchestration on the existing federated transport
Quality-gate validation before commit

Operates on: gradients, weights, metrics in development

Layer 03 · planned

Infrastructure assistant

Diagnoses deployment problems on the customer side.

Reads logs, container state, gRPC health, replication status. Tells the customer's ops team what to fix when something goes wrong with the deployment itself — not with the ML.

Operates on: infra logs, deployment state scoped

Layer 04 · planned

Onboarding & runbook agent

Interactive documentation that answers, not searches.

Walks a new ML engineer through their first project. Knows the product. Knows the user's environment. Suggests the right artifact, the right validation set, the right quality gate. Successor to a static docs site.

Operates on: docs, account state scoped

Deployment

Two ways to bring the agent in.

Agents run where the data flow already runs. The customer's IT team chooses between a console agent that lives in their CI or a long-lived process on the FedTuna server. Either way, the agent operates on the same privacy-preserving surface.

FORMAT · 01

Console agent

Text-based, declared in a config file, runs on demand or on a schedule. Drops into existing CI / cron / Airflow without surface area. Reads its task, reports its result, exits.

# fedtuna-agent.yaml — drift watcher, daily
agent: drift-watchdog
project: derm-classifier-v4
scope:
  type: rolling_window
  window: "24h"
on_drift:
  threshold: "medium"
  notify: ["#ml-ops"]

FORMAT · 02

Server-resident agent

Long-lived process on the FedTuna node. Watches the federated boundary continuously. Surfaces findings into the product UI, the inbox of the ML engineer, or directly into a Slack channel.

# Enabled via the product UI · Settings → Agents
deployment: server
node: demo-vendor
attached_to:
  - project: derm-classifier-v4
  - project: incidents-fraud-v2
channels:
  - ui: in-app
  - slack: "#ml-ops"

Model access

The agent uses an LLM provider chosen by the customer. The product brings two provisioning shapes: personal API tokens for individual ML engineers — handy for evaluation, scoped to one user — and team plans bound to a corporate account, with shared usage budgets and SSO. Either way, the provider receives only the privacy-preserving payload described above. No raw customer data crosses the LLM API. We can advise on the right shape during the pilot.

Works with your stack

Integrations, not abstractions.

The platform ships compatible with tools your team already runs. Whitelist by design — only vetted packages execute inside the customer perimeter.

↳ Visualize training

TensorBoard

Stream training and validation curves the way your team already reads them. Baseline MLOps, no extra wiring.

↳ Models, no custom objects

timm

Use any architecture from timm directly. No serialization quirks, no custom layers to register.

↳ Whitelisted models

Hugging Face

Pull models from a curated whitelist. Vetted for the federated loop, safe for closed-perimeter deployment.

↳ Track experiments

Weights & Biases

Log runs, compare federated rounds, share dashboards. Optional, off by default — your data, your choice.

Whitelist by design. Only vetted packages run inside the customer perimeter. Ask about your stack →

Case · Image classification

500 client images. No data movement.

A representative pilot in image classification — universal across medical imaging, financial documents, and regulatory inspection.

FROM A RECENT PILOT

When new client devices appeared, the base model collapsed. Five hundred labelled images put it back together.

The vendor’s model had never seen the new camera hardware at the client site. Equal Error Rate dropped from 6.97% to 0.7% after federated fine-tuning on 500 client images. The vendor’s validation score held steady. No raw images moved between parties.

Read the full case →

6.97% → 0.7%

EQUAL ERROR RATE · CLIENT DATA

After 500-image federated fine-tune

CPU only

CLIENT-SIDE HARDWARE

GPU optional · ~2× speedup

24w → 6d

VENDOR UPDATE CYCLE

From one healthcare pilot

For the security team

What stays inside the perimeter, and what doesn’t.

Designed so a security or compliance reviewer can answer the perimeter question in under two minutes.

STAYS Inside the client perimeter

Raw images, records, and labels
Patient, customer, and case identifiers
Trained model weights on the client side
Local feature stores and intermediate tensors

TRAVELS Between vendor and client

Gradients and weight updates
Aggregated quality metrics
Model version and project metadata
All over gRPC with TLS

Deployment: Docker container or SDK, installed inside the client perimeter. Read the full Trust & Security note →