Skip to main content
Hollerith is a transformer pretrained to predict directly from tables, trained and served by Monarcha. It reads your labeled rows in context and scores new rows in a forward pass. No gradient updates happen on your data. The mechanism is in How Hollerith works; this page is the envelope around it.

​
What it does today

Five calls cover the whole surface. Everything below runs against the same pretrained model, with no per-task variant to choose between.
  • Classification. Labels from predict, probabilities from predict_proba, up to 160 classes.
  • Regression. Point predictions, plus quantiles when you ask for them.
  • Evaluation. One metric per run — accuracy for classification, RMSE for regression.
  • Fitted contexts. One fit, reusable for 7 days and from another process.
  • Forecasting, in Beta. Time-indexed targets through forecast, implemented end to end.
Every ceiling on these is in Limits and quotas. What each job kind costs is in Usage and billing.

​
Where it runs

The model is served by Monarcha on an NVIDIA L4 GPU tier, behind one worker that drains the queue. Whether that worker stays up between calls is a deployment setting, not a promise. A cold worker costs a warm-up before your job starts. The SDK waits through it while polling, with one exception around fit covered in Errors.

​
Where it is strong

The shape of the problem decides this more than the domain does. The three cases below share a shape, not an industry.
  • Structured business tables. Churn, conversion, risk, pricing, quality control. Mixed numeric and categorical columns, with missing values read as information rather than as something to impute first.
  • Cold starts and fast iteration. One call tells you whether signal exists in a table, where the alternative is a round of feature work before you find out.
  • Many small-to-mid problems. One interface, instead of training and maintaining a separate model per table or per segment.

​
Known limitations

Each of these is a property of how the model reads a table, not a defect waiting on a fix. We are not describing any of them as temporary, and you should not plan as though they are.
  • Free text and dates are ordinal-encoded. The model sees category identity, not meaning and not ordering. A signup_date tells it which rows share a day, not which came first.
  • Row-wise predict has no temporal structure. No seasonality, no autocorrelation, no lag. Time-indexed targets belong in Forecast.
  • Very wide tables degrade. 2,000 columns are accepted, and accuracy and latency both suffer as the column count grows. No threshold is published for where selecting features first starts to pay, so measure it on your table.
  • Domain feature engineering still matters. The model cannot invent signal that is not in the columns. Ratios, aggregates and joins earn their keep here as they do anywhere else.
  • Latency and cost scale with table size. The context is read on every call, so a large fitted table is paid for on every prediction rather than once.
  • Distribution shift is silent. A new product line or a pricing change breaks the assumption that scored rows resemble fitted rows, and nothing warns you. Re-fitting is one call, which makes it the cheap remedy.

​
Where a tuned gradient boosting pipeline may still win

A well-tuned XGBoost or LightGBM pipeline, built by someone who knows the domain, is a serious baseline on a stable table. It is also cheaper per prediction once it exists. Hollerith’s advantage is widest before that pipeline has been built and narrowest after. Which one wins on your table is a measurable question rather than an argument — Evaluating accuracy sets out how to run the comparison so the answer means something.

​
What is not built

This list exists so that nothing here gets planned around. None of it is built today, and saying so is not a statement about whether it ever will be.
  • Any SDK other than Python.
  • Self-hosted or in-VPC deployment.
  • Customer-managed encryption keys.
  • A public SLA.

​
Next