Start
Introduction
Read a text once, then answer thousands of typed questions against that single read, each with a probability.
Siltstone answers questions about a text. Not with generated prose you then have to parse: every answer is a choice from a menu you wrote, in its own type, with the probability the model put on it.
Support ticket
Charged twice for the 03/03/2026 invoice. Second time this happened. Fix it today or I cancel.
- Is this urgent?Yes98%
- Which team handles it?billing97%
- How upset are they?2.3995%
- Did they ask for a refund?No94%
- Which invoice date?2026-03-0395%
How it works#
You send a text and a list of questions. Each question has a type:
| Type | Asks | You get back |
|---|---|---|
bool | Does the text say X? | true or false |
choice | Which one of these? | one of your option names |
score | Where on this scale? | a position on your levels, like 2.4 |
number | How many, how much? | a number, like 1840.5 |
date time datetime | When? | an ISO string, like "2026-03-03" |
The model reads the text once. Every question then runs against that single read, costing only its own few tokens: on an 11,711-token document, the read takes about two seconds and each question after it about five milliseconds. Two hundred questions take a little over a second. Asking more questions about a text is how Siltstone gets cheaper per answer, not more expensive.
Why typed answers#
A free-text answer has to be read before a program can act on it, and reading it is where the errors creep in: a "yes, but…", a label spelled differently, a confident sentence about something the text never said.
A Siltstone answer is already the value your code branches on. For most types the model does not write the answer at all; it picks a row from your menu, and the probabilities across the rows are the answer's confidence. Numbers and dates are written, but under a grammar that allows nothing else, so they always parse. Either way the answer carries a confidence you can act on: take the answers that clear your bar and send the rest to a person.
{
"id": "team",
"type": "choice",
"value": "billing",
"confidence": 0.97,
"probabilities": { "billing": 0.97, "technical": 0.02, "sales": 0.01 },
"review": false
}What it is good at#
- Routing and triage. Which queue, how urgent, does it need a person.
- Extraction into a schema. One question per field, every field typed: amounts, dates and counts included.
- Checking a catalogue. Which of these 200 things does the text mention.
- Judgement at scale. The same rubric, applied the same way, to every text.
What it does not do is generate prose: it will not write a summary or an explanation. And it answers what the text states, not what follows from it: a date "two weeks after delivery" is arithmetic, which is yours to do.