> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hollerith.monarcha.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# The model

> Where Hollerith wins, and where it does not

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](/concepts/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.

```python theme={null}
clf.fit(train, target="churned")               # classification or regression
clf.predict(test)                              # labels, or point predictions
clf.predict_proba(test)                        # class probabilities
clf.predict(test, quantiles=[0.1, 0.5, 0.9])   # prediction intervals
clf.evaluate()                                 # one held-out metric
```

* **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](/reference/limits). What each job kind costs
is in [Usage and billing](/account/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](/reference/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](/guides/forecasting).
* **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](/guides/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

* [How Hollerith works](/concepts/how-hollerith-works) — why there is no training step
* [Preparing your table](/guides/preparing-your-table) — dtypes, targets, and the traps
* [Data handling and retention](/account/data-handling) — what is kept, and for how long
* [Limits and quotas](/reference/limits) — every ceiling and the error you get at it
* [Usage and billing](/account/usage-and-billing) — what each job kind bills