FAQ
Common questions about Rosa, your data, jobs, outputs, integration, and the free trial.
About Rosa
What does Rosa stand for?
Rosa is named after Rosa Parks. It stands for nothing formally - it is a name, not an acronym.
Is Rosa the same as AIF360 or Fairlearn?
No. AIF360 and Fairlearn are model-centric tools that constrain a model's training loss. Rosa operates at the data layer: it transforms your dataset before any model training. See the Overview page for a full comparison.
Does Rosa sacrifice model accuracy?
Not on data with genuine predictive signal - the usual case. When all three models are evaluated against the same unbiased ground truth, the Rosa-debiased model achieves the best R² of the three with near-zero bias - it beats both the biased model and the parity-constrained baseline on R² (accuracy is close across all three, so R² - how well each model tracks the fair signal - is the deciding measure). The parity baseline reaches marginally lower bias, but only by trading away predictive quality: its R² is the lowest of the three, below even the biased model. The honest exception is weak-signal data where the protected attribute itself carries much of the predictive power: on COMPAS, our worked hard case, removing race does cost accuracy - about 14 points - and we publish the full panel there rather than bury it. See the Model Validation page for the figures.
What kind of algorithm is the FAN?
Rosa's Fair Adversarial Network is standalone (it runs as a pre-processing step with no coupling to your downstream model), nonlinear (it captures complex relationships, not just linear correlations), multivariate (it considers all features jointly, which is how it finds proxy variables), and distribution-agnostic - it makes no assumptions about the shape of your data's distribution, so it works regardless of how your data is shaped. (A neural network is technically a parametric model, so "distribution-agnostic" is the precise claim here, not "nonparametric": no assumptions about the input distribution, rather than an absence of parameters.)
How does Rosa find and remove proxy variables?
Because the FAN is multivariate, its discriminator looks at all columns at once - so it detects the protected attribute even when no single column is labelled as a proxy, by combining the partial signals several columns carry. The encoder then rank-maps each column (reorders the values already in that column) until the discriminator's ability to predict the protected attribute is driven down toward chance, and reports how close that run got. You only declare the bias column; Rosa works out which other columns leak it and how. Rank-mapping breaks each column's correlation with the protected attribute while preserving its marginal distribution.
Are there proxies Rosa cannot fully remove?
One case. Because rank-mapping only reorders values that already exist in a column, it cannot fully neutralise a near-deterministic categorical proxy - a category whose value almost exclusively identifies one group (for example a first-name column drawn from exclusively male or female name pools, or a title such as Mr/Ms). Rosa still reduces the dataset-level association, but each such value carries strong group-specific signal that reordering cannot remove, so as a proxy's correlation with the protected attribute approaches 1.0 the residual bias rises. Numerical proxies and ordinary categorical proxies - values that appear in both groups at different rates, which is the usual shape of real data - are the case Rosa handles best, and it drives them to a low residual as measured on held-out data by its own permutation test. That is a low residual rather than none: some runs leave a residual the test still detects, and the Outputs page reports that verdict alongside the score. This is why Test 1 uses numerical gender proxies at a moderate correlation: representative of real-world proxies, and well within the range Rosa drives to a low residual bias (on Test 1, the honest held-out bias dial falls from strong recoverability before debiasing to low residual recoverability after, varying run to run).
Why does the residual bias differ each time I train Test 1?
Because Rosa's Fair Adversarial Network is a neural-network training, and like any such training it is stochastic - it is not pinned to a fixed random seed. So each training job lands on a slightly different residual bias: on Test 1 the honest held-out bias dial falls from strong recoverability before debiasing to low residual recoverability after, with the exact residual varying from run to run. This is why the residual is best read as "low, characterised across runs" rather than one fixed number - the same reason the Diagnose report presents the discriminator accuracy as an average across multiple training instances with a standard deviation. The directional result observed across the runs we publish is the one that matters: the residual falls to a low level, and because the score is measured on held-out data and calibrated against shuffled labels, a low reading is not something the detector can produce by fitting itself to this dataset. That is a measurement under a specific test rather than a proof, and it does not hold identically on every run: some runs leave a residual the test still detects, which is why the Outputs page reports the significance verdict next to the number instead of the number alone.
Can I set a seed to make a Rosa run reproduce exactly?
No, by design. Rosa deliberately exposes no training seed. Debiasing is stochastic, and even a fixed seed would not make it bit-for-bit reproducible (numerical libraries and thread scheduling still introduce variation), so a seed would offer false precision. Reproducibility is instead statistical: run the same job several times and take the mean. This is exactly why Rosa's own published benchmark figures are reported as N-run means with a range, each stamped to a specific Rosa version, rather than as a single number - the honest form for a stochastic engine.
I ran Diagnose on the debiased inference output and still see residual bias - is that a failure?
No - this is expected, and worth understanding. Training and inference are different operations. Training fits the FAN to your data and drives the debiased training output to a low residual bias (on Test 1 the honest held-out bias dial falls to low residual recoverability). Inference applies that already-trained mapping to new, unseen rows - it does not re-optimise - so the debiased inference output keeps more residual signal - a fresh Diagnose of Test 1's held-out rows reads materially higher than the near-zero residual of the debiased training data. That is the honest operational picture, not a defect - in production you train once and then apply the model to fresh data it never saw. The proof that debiasing worked is not that Diagnosing the inference output reads zero; it is that Model B - trained on Rosa's debiased training data and then run on that debiased inference output - stays fair on the unbiased ground truth (on the Model Validation page it reaches the best R² of the three models, with near-zero bias). Diagnose is a training-time measurement tool; for a deployed model the bias was measured at training time and the dials live on the Training job's Outputs page.
Data and configuration
What is the Check my data tab?
An advisory, in-browser health check you can run on your CSV before you submit a job, so you catch problems in seconds rather than after a run. It reads your file entirely in your browser - nothing is uploaded, no network calls are made, and it never runs the debiasing engine - so it is safe for sensitive data, and you can download it and run it offline on your own machine. It reports the encoded width and an estimated runtime, checks your data against the trial limits (1,000-50,000 rows, up to 100 raw columns and 150 post-encoding columns), and flags common quality issues: near-deterministic proxies for the protected attribute, missing values (including numeric placeholders such as -999 or 9999 that Rosa reads as real data), heavy-tailed or negative-value numeric columns, sparse low-frequency categories, blank or duplicate column headers, and the presence of more than one protected characteristic. It also proposes a sensible bias_columns / cat_columns / ignore_columns config - auto-detecting a UK Equality Act protected characteristic as the bias column and moving identifier and obvious outcome/label columns to ignore - which you can edit; running the check inside the portal also auto-fills the Jobs Upload my own CSV form so you can go straight to Diagnose or Train. Rosa reads your whole file - streaming it so it stays light on memory even for a very large file - and reports the exact row count. For its per-column statistics it takes a representative random sample of the rows (up to about 4 million cells), drawn evenly from across the file, so the result does not depend on how your data is ordered, and it tells you when it has sampled. It is guidance, not a gate - the real limits are enforced by Rosa when you submit.
What is a bias column (bias_columns)?
The protected attribute you want Rosa to remove association with. The trial supports one bias column per job. It should be categorical (continuous attributes such as raw age in years must be binned first). Low cardinality (around 10 distinct values) is a rule of thumb, not a hard limit: Rosa's multi-group measurement handles more than two groups and has been run with up to nine groups in our own testing. What actually limits the number of groups is per-group detectability, not a fixed count - as the groups multiply, each holds fewer rows in the ~10,000-row training sample, and a group with too few rows gives the detection test too few examples to find its bias reliably. The rows it takes depend on the group count: with two or three groups detection has held on a couple of dozen rows in the smallest, while at eight groups we found none at 120 rows and detection on every run at 181. A large majority group does not by itself defeat the test. Only a column with fewer than two distinct groups is rejected.
What should I check about my bias column before I submit?
A bias characteristic is any variable you want to remove bias with respect to, protected or not: sex or ethnicity, but equally regional office, product line or intake cohort. Rosa handles one per run, and there is no maximum number of groups.
One check before you submit: count the rows in your smallest group. Training runs on a sample of at most about 10,000 rows drawn in proportion to your groups, so a group that is 1% of your file is about 100 rows in the sample however big the file is. How many rows that group needs depends on how many groups the column has, and no single number covers both ends: with two or three groups detection has held on a couple of dozen rows, while at eight groups we found none at 120 rows and detection on every run at 181, with the space between unmeasured. Neither figure is a cut-off, and neither is about how uneven your groups are: every group counts equally in the test, so a large majority group does not defeat it. What limits it is how few examples of the rarest group it has to learn from. If your smallest group has fewer than nine rows in the training sample, the test will not run at all: the job reports "detection not supported" instead of a verdict. Nine is the point below which the test cannot run, not a size at which detection is reliable.
A decline does not mean your data is fair. It means this test did not find the characteristic detectable here. Check the rows per group in your report first, and read the guide before concluding anything else.
Reshaping your file to even the groups up is not a fix, because unevenness is not the problem. Discarding rows from large groups buys nothing; merging small groups hides the one you care about; dropping your largest group removes the comparison you probably want. What does help a rare group is a training file in which it is a larger share, applied to your full population at inference.
Count the rows on your own file rather than from population figures. A dataset drawn from a particular city, catchment or cohort can be far more even than the national picture, and that is your number, not ours.
What must go in cat_columns?
Any column that should be treated as categorical rather than numeric. This includes string columns (required) and integer-coded categoricals (e.g. gender stored as 0/1). Rosa does not auto-detect this. If a categorical column is missing from cat_columns, results may be incorrect.
What goes in ignore_columns?
Columns that should not be debiased or included as features - typically the target/outcome label. Rosa transforms features; it does not touch ignored columns. If you omit the outcome column from ignore_columns, Rosa may modify it, breaking downstream model training. Direct identifiers (names, email addresses, customer IDs) should not be submitted to the free trial at all - remove or pseudonymise them before upload. ignore_columns is a transformation control, not a privacy boundary: an ignored column is still uploaded and still processed, it is simply left untouched and kept out of the model. If an identifier does reach Rosa, ignore_columns is still the right place for it rather than cat_columns, because cat_columns would record its distinct values in the retained Run Manifest.
Why does the debiased CSV have fewer columns than my input?
Rosa removes the bias column(s) from the output. The protected attribute is suppressed entirely from the output dataset.
What is the 150 post-encoding dimension limit?
Rosa one-hot-encodes categorical columns. A column with N distinct values expands to N binary columns. If the total after expansion exceeds 150, the job is rejected. This limit is a deliberate product cap for the trial - it keeps a worst-case trial job to about 15 minutes on the shared queue.
Does Rosa train on my whole dataset?
For training and diagnose, datasets over ~10,000 rows are down-sampled to a representative ~10,000-row subset before the debiasing model is trained, so trial runtime depends on the number of columns rather than the number of rows. The sample is drawn roughly in proportion to your groups, so a group that is 1% of your file is about 100 rows in the sample however large the file is; a bigger file does not give a small group more rows in training. Your full dataset is then debiased end-to-end at the inference step.
Is there an enterprise option without the free-tier caps?
Yes. The free trial is a shared service with the limits above. For enterprises, a paid Proof of Concept over 12 weeks on a dedicated instance in your own region - your own compute and encrypted storage, sized to your production data, with the row, column, and monthly-job-quota caps all lifted and no shared-queue wait - is available as the next step. Contact support@rosadebias.com for more details.
How does Rosa handle missing values?
Rosa imputes missing values automatically - the column mean for numeric columns, the most frequent value for categorical columns. Keep missing values below roughly 5% per column: above that, imputation quality degrades and your results become less reliable. Represent a missing value as an empty cell or a standard null token (N/A, NA, NULL, NaN, None) - Rosa recognises these and imputes them. Numeric placeholders such as -999 or 9999, or words such as "unknown" or "missing", are read as real data values and skew the column. To audit missing data, run Diagnose - its report and Run Manifest record the per-column missing-value count found in your input. A Training run imputes those gaps, so its output and manifest show the filled data.
Is there a minimum dataset size?
There are two numbers here, and they are different. 1,000 rows is the minimum for Rosa to accept a Diagnose or Training job; below that the bias statistics are unreliable and the job is rejected. 1,500 eligible training rows is the floor our published “no fairness/accuracy trade-off” benchmark is stated for. “Eligible training rows” means the rows that actually enter training after validation and exclusions, not the size of the file before you split it. Between the two, Rosa runs normally and reduces measured bias - but the downstream utility result varies enough from run to run at that size that a single run is not a reliable read on the trade-off claim. In the named synthetic benchmark, on Rosa 1.48.0 and the stated held-out A/B/C protocol, we saw 5 utility-ordering failures in 20 runs at about 1,200 training rows, and none in 40 runs at 1,500 or more; we have not characterised the transition between those ranges, and 1,500 bounds the failure rate rather than proving failures impossible above it. That observation is specific to that benchmark: on other datasets run with the same script and the same protocol the ordering fails more often, and the rate varies substantially from dataset to dataset. Our synthetic validation script declines to render a verdict below the floor rather than reporting a pass or a fail. Inference has no minimum - it applies an already-trained model to whatever you submit.
What does Rosa do to my data before debiasing?
Every job runs through a pre-processing pipeline before any debiasing: input data checks (file and schema validation), configuration validation (modes, bias/cat/ignore columns, size limits), type coercion, and statistical checks (per-column distributions and missing-value analysis). These steps make the run robust and feed the figures that appear in your Run Manifest and PDF report.
Does Rosa check that my inference data matches the trained model?
Yes. Before running inference, Rosa checks the new dataset against the data the model was trained on (the reference values come from the model metadata produced by the training job). Two structural checks are enforced - if either fails, the job is rejected immediately with INFERENCE_STATS_MISMATCH, before any compute is consumed: (1) every training column must be present and identically named; (2) no categorical column may contain a new value that was not seen during training (the model has no learned representation for an unseen category). Column order does not matter. If the same columns arrive in a different order, Rosa reorders them to match the training data before the run - the values are unchanged and no action is needed. Three further conditions are advisory - they do not fail the job and are recorded in the Run Manifest warnings field: (a) a training category that is missing from the inference data - the model encodes it as an all-zero column, so the rows that are present are unaffected and the job runs; (b) a non-categorical column whose minimum or maximum falls more than 10% outside the training range - out-of-range data is handled (debiasing may simply be less effective far from the training distribution); (c) COLUMN_ORDER_ALIGNED, recording that the reorder above took place. This catches a structurally incompatible dataset early, while still letting you run inference on data whose column order differs, whose values have drifted, or whose rare categories are absent.
Do my training and inference data need to contain the same categories?
New or unseen categorical values still fail - the model cannot encode a category it never saw during training. But a training category that is absent from the inference data is now tolerated: Rosa encodes it as an all-zero column (the rows that are present are unaffected) and records it as an advisory in the Run Manifest warnings field, so the job still runs. This means you no longer need to engineer a stratified split or drop rare categories just to avoid a rejection when a random train/test split lands all rows of a rare category on one side. In short: the inference set must introduce no new categorical values, but it does not need to contain every training value.
When does Rosa say "no bias detected"?
Before it debiases, Rosa runs a significance test: it measures how recoverable the protected attribute is from the other columns on a held-out split, then reruns the same test on many shuffles of the protected labels to establish the chance level for your dataset's shape. It reports "recoverable bias" only when the real recoverability is statistically above that chance level; otherwise it reports "no bias detected" rather than manufacture a result. On a Remove Bias (training) job it then declines to debias - status declined_no_bias - since there is nothing to remove; on a Diagnose job it completes normally, reporting the same "No Recoverable Bias Detected" finding with its full evidence. Either way it is a legitimate result - this test, on this dataset, found no signal above the chance level it established - and a guard against fairwashing. There is no fixed cutoff: because it is a significance test, the smallest detectable bias depends on how much data you have. It also depends on how many rows your smallest protected group contributes: every group counts equally in the test, so it is the rarest group that decides how close a run sits to its decision line, and more rows in the file do not help it, because training samples in proportion. What counts as enough rows there moves with the number of groups: at two or three, detection has held on a couple of dozen rows in the smallest group; at eight we found none at 120 rows and detection on every run at 181. With a few thousand rows you need a clearly-above-chance signal (a protected attribute recoverable at only ~AUC 0.54 on ~1,500 rows is declined); with tens of thousands of rows a smaller gap can still register. It also depends on the resolution of the test: the p-value can only be as fine as the number of shuffled-label runs allows, and that number is a per-instance setting rather than a property of the engine - the trial default is 24, which resolves the p-value to steps of 0.04, and a dedicated instance can raise the grid for evidential work (99 permutations resolve to 0.01, 999 to 0.001). Quick pre-check: if a simple model cannot beat chance by a clear margin on a held-out split, expect Rosa to decline.
"Detection not supported" is a different outcome, and not a "no bias detected" result. When a group of your bias column has fewer than nine rows in the training sample, Rosa does not run the test at all, because a group that small cannot be scored on a held-out split. Diagnose and Remove Bias (training) jobs both end with status declined_insufficient_support. There is no dial, no p-value and no verdict, the manifest names the group and its row count, and the outcome says nothing about whether your data is biased: the test that would have told you never ran.
What is a near-deterministic proxy, and should I remove it?
A near-deterministic proxy is a single non-protected column that predicts the protected attribute almost perfectly on its own - a rule of thumb is a held-out AUC ≥ ~0.85, or a category that is ≥ ~95% one group. In the US Census "Adult" dataset the relationship column is a classic example: Husband is ~100% male and Wife ~100% female. Rosa debiases one attribute per run (univariate), which reduces the overall signal, but a downstream model can still reconstruct the group split from such a column, so your downstream fairness gain will be limited. Consider removing or coarsening these columns before debiasing. (Debiasing several protected attributes jointly is a future capability.)
Jobs and quotas
How many jobs can I run?
20 jobs per workspace per calendar month (resets on the 1st). Both Diagnose and Training jobs consume the same quota - they run the same FAN training loop.
Is Rosa limited to 50,000 rows and 100 columns?
No - those are the limits of this free tier only, not of the Rosa engine. The underlying FAN algorithm is not bound by them. Published, independently reproducible evidence currently covers datasets up to the widths used in our benchmarks; larger shapes are sized per deployment and we will quote a measured figure for your data rather than a general one. The row, column, and monthly-job caps here exist to keep the shared free service responsive for everyone; a production deployment is sized to your data and is not bound by these figures.
Why are Diagnose and Training the same quota cost?
Diagnose runs the full FAN training loop internally to produce its bias report. It is not a quick scan - it costs approximately the same compute as a Training job.
How long do jobs take?
Depends on dataset size and mode. For Test 1 (2,000 rows, 24 columns): Diagnose/Training typically about 3 minutes each; Inference is much faster (seconds). For a job at the maximum width (150 post-encoding dimensions): up to ~15 minutes. Training down-samples to ~10,000 rows, so runtime depends on the number of columns, not the number of rows.
How does inference scale with data size?
Very well. Once a FAN model is trained, applying it to new data is fast - inference scales roughly linearly with the number of rows, so you can debias large operational datasets and run inference continuously in production. Training and Diagnose are the heavier steps; inference is the light one.
Can I cancel a job?
Yes. If a job is queued or running, a Cancel button appears on that row in the Jobs page history. Cancellation kills the processing within a few seconds and marks the job cancelled. A cancelled job's Run Manifest is preserved for audit purposes. Jobs that are already complete cannot be cancelled.
My job failed - what do I do?
The Jobs page shows the reason inline beneath a failed job's status - a short label plus a plain-language message - so you can see exactly why it was rejected without opening anything. The Run Manifest (written for every terminal state) records the same reason for the audit trail, alongside a structured error_code that the API and MCP tools return so a client can key on it. The most common causes are a column listed in cat_columns that is not present in your CSV, the bias_columns value missing from cat_columns (Rosa debiases between discrete categorical groups, so the protected column must be declared categorical), or a dataset below the 1,000-row minimum. Correct the config or the data and resubmit - a rejected job does not consume your monthly quota. A training job can also occasionally fail if the model diverges on your data. Rosa handles typical skewed / outlier-heavy real-world data directly (it debiases COMPAS's heavy-tailed count and duration columns with no pre-conditioning), but very extreme columns can sometimes trigger a divergence. That fails safely (the run is aborted and Rosa never returns altered or garbage data), the error field says so, and pre-scaling those columns resolves it.
What happens to my data after the job completes?
The files you can download - the debiased data and the PDF report - are available for 7 days after a job completes, after which a download returns a clear expired response and the files are removed shortly afterwards. Rosa also keeps internal files it manages for you and does not hand over: your input CSV and the run log for 7 days, and the trained model checkpoint for 365 days (so you can run inference against an earlier training job for a year - Rosa resolves the checkpoint for you from the training job id; you never download it). Run Manifests are kept permanently and are not subject to these windows.
Outputs and downloads
What does the debiased CSV contain?
The same rows as your input, with feature values transformed to suppress the protected attribute. The bias column itself is removed from the output. Row order is preserved. Row count is preserved for inference; for training and diagnose, inputs over ~10,000 rows are sampled first, so a training output carries the ~10,000-row sample (the Run Manifest records the original count).
What are my output files named?
The debiased CSV is named after your input file: <name>_fair.csv. Over the REST API the name comes from the file you upload. Over MCP, when you send a CSV inline, pass the optional filename argument (for example applicants.csv) to rosa_diagnose or rosa_remove_bias so the output is applicants_fair.csv; the tool echoes back the sanitised name it used as input_filename. If you omit it, the source defaults to rosa_input.csv, so the output is rosa_input_fair.csv. Either way, rosa_get_artifacts always lists the exact filenames once the job completes.
Do the statistical properties of my data change?
No. Rosa's rank-mapping step preserves each column's marginal distribution - the sorted values are unchanged. This holds exactly in both Training and Inference modes: the debiased column contains the same values as your input, reordered, preserved to float64 CSV precision (~13 significant figures). Column means, standard deviations, and percentiles are unchanged. Cross-column correlations may change where they were encoding bias.
What is the PDF report?
For Diagnose jobs: a bias evidence report showing random baseline accuracy, discriminator accuracy, per-feature debiasing-adjustment scores, and a feature-association proxy table. For Training jobs: a bias reduction report showing residual discriminator performance post-debiasing.
Where can I find definitions of the terms in the report?
A plain-English Glossary (PDF) defines every term Rosa emits in the PDF report and the Run Manifest - Bias Characteristic, Proxy Variables, Random Baseline Accuracy, Best Random Accuracy, Average Discriminator Performance, Bias and Residual Bias, Feature Associations, and the Debiasing Adjustment by Feature. It is also linked from the Test 1 and COMPAS download rows on the Jobs and Data Validation pages.
What is the Run Manifest?
A machine-readable JSON record written for every job - including Diagnose, cancelled, and failed jobs - and retained indefinitely as the permanent evidence of the run. It records what was processed and how: job id, status and timestamps, the mode, the Rosa version and container digest, row and column counts before and after encoding, the declared bias / ignore / categorical columns, the training job an inference model came from, the bias measurement (before and, for Training, the residual after debiasing) with its significance, how it was measured and the per-group figures, whether the detection test could run, per-column statistics and feature associations, advisory warnings, operational metrics about the run, and SHA-256 hashes of the input file, schema, configuration and every output artifact. It contains no row-level data. Open it on the Run Manifest page, download it, and use its hashes to prove a specific dataset was processed unaltered at a specific time - the per-run audit trail an EU AI Act Article 10 or SOC 2 review expects.
Can I verify the debiased CSV has not been tampered with?
Yes. The Run Manifest contains SHA-256 hashes of all output artifacts. Compute the SHA-256 of your downloaded file and compare against output_artifact_hashes in the manifest using the verification tool on the Run Manifest page. The raw input CSV is verifiable the same way: the manifest's input_hash (SHA-256 of the exact file you submitted, computed before any processing) lets you confirm Rosa processed the file you sent. This also works for Diagnose, cancelled, and failed jobs, which produce no output artifacts - input_hash is then the only hash to check.
Can I validate Rosa against a known ground truth?
Yes - and it is the strongest check. On your own real data you can run the Model A (raw) versus Model B (Rosa-debiased) comparison, but real data has no "correct fair answer", so it shows the group gap moved without showing how close it got to ideal. For a gold-standard check, use a synthetic dataset where the fair answer is known. The portal offers two standalone scripts (neither imports Rosa, so you can read exactly what they do): synthetic_test_generator.py builds a dataset with a known fair ground truth and a matching Rosa config, and reproduce-synthetic-downstream.py scores three downstream models against that ground truth - Model A on the raw data, Model B on the Rosa-debiased data, and Model C the parity-constrained “fairness by quota” baseline (Model A with per-group thresholds forced to equal approval rates). All three are scored against the known fair outcome - the oracle. A working debiaser gives C < A < B on R² at close accuracy: the parity constraint sacrifices the most predictive quality, so Rosa’s B beats both the biased model and the parity baseline. The ordering is stochastic: Rosa’s engine varies from run to run, so a single run is not a verdict, and on some datasets the ordering does not appear over repeated runs even though nothing is wrong. Run several and read the mean, as the script’s own header says. Find both under "Upload my own CSV" on the Jobs page; section 7 of the BYO-LLM guide walks through the flow.
Integration (REST API and MCP)
What is the base URL?
https://api.rosadebias.com/v1
How do I authenticate?
X-API-Key: <your_key> or Authorization: Bearer <your_key> on every request.
How do I submit a job via the API?
POST /v1/jobs with multipart/form-data containing csv_file and config (JSON string). Returns HTTP 202 with job_id. Poll GET /v1/jobs/{job_id} until the status is terminal - complete, declined_no_bias (a remove job with no recoverable bias), declined_insufficient_support (a group too small for the detection test to run), failed, cancelled or interrupted. To retrieve your job history, call GET /v1/jobs, which returns it newest first a page at a time - follow next_cursor for older pages.
How do I list my past jobs?
GET /v1/jobs returns your workspace's jobs a page at a time, newest first (200 by default; pass limit, status or cursor, and follow next_cursor for older pages), with the same fields as GET /v1/jobs/{job_id} (job_id, mode, status, submitted_at, started_at, completed_at, row_count, error, error_code) across every state - queued, running, complete, declined_no_bias, declined_insufficient_support, failed, cancelled, interrupted. On a failed job error_code is a structured code from a fixed set (for example ENGINE_FAILED, JOB_TIMEOUT, MODEL_NOT_FOUND) and error is a plain-language message; both are null otherwise. This is what the portal's Jobs page uses to rebuild your history after you sign out. For billing-style records of completed jobs only, use GET /v1/usage instead.
Can I use Rosa from an AI agent?
Yes. Rosa exposes eight MCP tools: rosa_diagnose, rosa_remove_bias, rosa_job_status, rosa_get_report, rosa_get_artifacts, rosa_get_manifest, rosa_list_jobs, rosa_cancel_job. Connect your MCP client to the Rosa MCP endpoint https://api.rosadebias.com/mcp, sending your API key as the X-API-Key header. See the API/MCP page for the full tool list and connection details. The quickest start is to download the Rosa Starter Kit (.zip) and hand it to your assistant - it bundles the connection guide, worked examples and validation scripts so your assistant can onboard on its own. One limit to know: inline MCP is for small trial files of a few megabytes, and anything larger should go over the REST endpoint. The effective inline ceiling is set by the MCP transport and by your own MCP client rather than by Rosa's dataset limits, and base64 encoding inflates a CSV by about a third before it reaches that ceiling, so preflight the encoded size in your client rather than relying on a fixed figure. If an inline submission is refused for size the response is an HTTP 413 naming the REST upload path; that is a transport refusal rather than a dataset validation failure, and it consumes no quota.
What is a training_job_id?
To run inference, you provide the job_id of a completed training job. Rosa uses it to locate the trained model checkpoint automatically. You never upload model files directly.
Security and compliance
Where is my data processed?
AWS EC2, eu-west-2 (London, UK). Data does not leave the UK. EU-to-UK transfers are covered by the EU-UK adequacy decision.
Is the connection encrypted?
Yes. TLSv1.3 + AES-256-GCM via nginx. All HTTP requests redirect to HTTPS.
Is my data stored encrypted?
Yes. All job artifacts, model checkpoints, and manifests are stored on AES-256 encrypted EBS volumes.
Is my API key stored securely?
Your API key is hashed using argon2id (OWASP-recommended). The plaintext key is only ever shown once (at creation or rotation). Rosa cannot recover it.
Is there multi-tenant isolation?
Yes. All job data is scoped to your workspace_id. Requests for another workspace's jobs return 404, not 403 - your workspace's existence is not revealed to other tenants. The same boundary was tested adversarially against the running shared service with two workspaces on one instance: reads, artifact downloads, a cross-workspace cancel and a reused idempotency key, nine checks, nine refusals.
Does Rosa's Diagnose output count as EU AI Act Article 10 data governance evidence?
It is designed to. Article 10 requires operators of high-risk AI systems to examine training data for potential biases and document that examination before deploying. Rosa's Diagnose mode produces a structured Data Bias Audit: it identifies which features carry protected-attribute signal, quantifies the degree of association, and generates a cryptographically hashed PDF report (the Run Manifest records the SHA-256 of every output artifact). This is the kind of per-dataset, per-run evidence record an Article 10 audit trail requires. A parity output adjustment does not satisfy this requirement. A regulator who asks “can gender be predicted from your features?” gets “yes” from a parity-adjusted model's underlying data - the data itself is unchanged. Rosa changes the data. After Rosa debiasing, gender is markedly harder to predict from the feature set, measured on held-out data by Rosa's own discriminator and permutation test. The Run Manifest records a SHA-256 of every input and output, so the exact dataset transformed and the moment it happened are both verifiable. Those hashes establish integrity and linkage; they are not by themselves proof that the measurement is correct or that a deployment is compliant. For legal advice on EU AI Act compliance, consult a qualified professional.
Does Rosa keep an audit log of API access?
Yes. API requests are recorded as structured access-log entries - UTC timestamp, method, endpoint, response status, source IP, request duration, and a non-reversible fingerprint of the API key used (never the key itself) - and every job emits lifecycle events (submitted, started, completed/failed/cancelled) to a separate application log. Both ship to AWS CloudWatch, centralised and append-only, retained for 365 days, and are joined by a per-request correlation id returned in the X-Request-ID response header. Neither log ever contains your CSV contents - no row, field or cell of your data is written to either. What they do contain is limited operational metadata about the request and the job, and that metadata can include a source IP and a stable key fingerprint, which may identify a person or organisation; we process it only for the security, availability and audit-trail purposes described here, and hold it for the stated retention period. One bound worth stating plainly: the log shipper holds records in a buffer of fixed size and, under sustained load, discards the oldest queued entries rather than growing without limit - so the trail is complete in normal operation but is not guaranteed to be gap-free under pressure. This is the logging-and-monitoring control for SOC 2, and it complements the per-job Run Manifest (the immutable record of what was done to each dataset).
Is the API rate limited?
Yes. Each API key has separate per-minute limits for read requests (job status, artifacts, manifests) and write requests (job submission and other mutations), and all traffic is additionally bounded by a per-IP limit that absorbs keyless or credential-stuffing floods. A request over a limit receives a standard 429 RATE_LIMITED response with a Retry-After header telling the client when to retry; normal portal use stays well within the limits. Rate limiting protects service availability and is separate from your monthly job quota. One further limit applies only when the service is stopped: to keep cost bounded, it is started at most 20 times an hour from any one network. Past that, the request that would start it also receives 429 ("Too many wake attempts") and nothing is started; retrying sooner does not help, and the service can be started again once the oldest of those starts is more than an hour old. The portal tells you when this happens.
How do you keep dependencies secure?
Every build audits Rosa's software dependencies for known vulnerabilities and fails if any fixable one is present, so a vulnerable package cannot reach production unnoticed; a 72-hour patching target applies to critical advisories. Dependabot additionally opens automated update pull requests for dependencies, CI actions, and container base images. The one exception is the frozen machine-learning engine (TensorFlow 2.13), pinned for reproducibility until a planned migration - its advisories are tracked on a documented, auditable allow-list and reviewed, never silently ignored. This is the dependency-management control for SOC 2.
How do you protect against leaked credentials?
Every code change is automatically scanned for committed secrets before it can merge, and the full commit history is periodically rescanned. Operational secrets are kept in protected, root-only stores off the application and out of process listings, with a defined rotation policy. This sits on top of continuous third-party security scanning across our code, dependencies, infrastructure, and cloud configuration.
What does signing out do?
Signing out clears this browser session only - your key and cached job history are removed from the browser. It does not revoke your API key: the key stays valid for the REST API, MCP, and your next sign-in. To invalidate a key, rotate it - use the Rotate key link in the header or POST /v1/workspaces/me/rotate-key.
Commercial model and service tiers
How will Rosa be offered commercially?
Rosa is offered around its buyer segments - regulators, auditors, and enterprises - each on their own dedicated instance, with a shared instance for AI-agent (MCP) usage:
- Regulators, auditors and enterprises - organisations in regulated sectors (financial services, healthcare, law enforcement) and the supervisory bodies and auditors who assess them each get a dedicated instance: a separate compute instance, its own encrypted storage volume, and its own internal certificate authority whose signing key is held in AWS KMS and never leaves it, for physical tenant isolation. Storage encryption uses AWS-managed keys today; customer-managed keys, where you hold and control the key yourself, are on the roadmap for this tier rather than available now. This tier carries the compliance posture (Data Processing Agreement, dedicated data residency, audit evidence) that these buyers require.
- AI agents via MCP - agent-native usage over the MCP tools runs on a shared instance with logical isolation (every job scoped to your workspace_id), consistent with standard SaaS multi-tenancy. This shared MCP / AI-agent tier comes later.
During the current free trial everyone shares one instance. Physical co-location on a shared volume is disclosed before onboarding; regulated workloads should use a dedicated instance.
Free trial and getting help
Is this really free?
Yes. The free trial is funded by Rosa. No credit card required. 20 jobs per month per workspace.
When will pricing start?
Rosa will transition to a commercial model when your free trial phase ends (usually after 3 months). You will be notified in advance at the email address you registered with.
How do I rotate, reset, or get a second API key?
You can rotate your own key at any time - use the Rotate key link in the portal header, or call POST /v1/workspaces/me/rotate-key directly. The current key stops working immediately, the new key is shown once, and your workspace_id and full job history are preserved. This is also the recovery path if a key is compromised. For a separate additional workspace, email support@rosadebias.com.
I found a bug or have a question.
Email support@rosadebias.com.
