What it is sized for.
A specification, published rather than discovered. The operating envelope, the measurements behind it, and the internal targets kept separate from both — because a target read as a measurement is how a capacity page becomes a marketing document.
Three kinds of number appear on a page like this and they mean different things: what the system accepts, what it has been measured doing, and what we aim for. They are kept apart here, and each says what it is.
The supported envelope
What the system accepts by construction. Exceeding these is refused rather than degraded.
- Model size
- ≤ 24 variables
- a bound on the model, not a target for one
- Conditional table
- ≤ 2,048 cells
- per node, across all its parents
- Widest measured node
- width 10
- the cell cap would permit about 12
- Deployment
- 10 tenants · 25 concurrent
- per-project isolation
The cell cap and the width guard are two different limits, and the smaller one binds first. A model can have a node whose parent set the width guard permits and whose table exceeds the cell cap — so the number worth publishing is the measured 10, not the permitted 12. A vendor would let the guard stand for the capability.
What has been measured
Query latency under load, taken on a development machine against the committed envelope.
- p50
- 74.7 ms
- 25 concurrent queries
- p95
- 271.7 ms
- 25 concurrent queries
- Errors
- 0
- across the run
- Inference alone
- 0.8–3.7 ms
- 8 variables, as predecessors rise
One API process and one database, on development hardware. The workload, topology and request count are recorded with the artifact, and the figure is not a claim about a production deployment with different hardware or a different model shape.
Internal targets
What we aim for operationally. These are objectives, not observations, and they are listed separately so they cannot be mistaken for the block above.
- Query p95
- < 500 ms
- objective
- Query availability
- 99.5% / 30 days
- objective
- Generation success
- 95% / 7 days
- objective
A target is not a measurement and is not an SLA. Observed availability is not published here because it has not been measured long enough to be worth stating, and a capacity page that lists an aspiration beside an observation without distinguishing them is the failure this section exists to avoid.
What that means for your problem
Three consequences, stated plainly, because each one is a reason this might be the wrong tool.
Sized for a decision, not an enterprise replica
Twenty-four variables is enough for a decision with a defensible model and not enough for a replica of an organization. If your question needs several hundred variables, this will not answer it and no amount of tuning will change that.
What this does not establish: The bound is a property of the method and the envelope, not of the hardware. A larger machine does not raise it.
One process, one database
The deployment is a single API process and a single Postgres instance. That is measured and reproducible, and it is what the numbers above describe.
What this does not establish: Horizontal scaling has not been measured, so nothing here should be read as a claim that it works. The envelope describes one process, and it is stated that way.
Discrete by construction
Variables are discrete, and a continuous variable reaches the model through binning, which is lossy and labeled as such on the row. Exact inference is exact over the discrete model that was built.
What this does not establish: Binning is a modeling choice that changes what the answer means. It is not native continuous support, and nothing here should be read as if it were.
If you have a decision to make and a number someone will hold you to, the question is not whether we can produce a number. It is whether you can say where it came from.