Three choices, and together they are the whole thing
A chatbot sends your question to one very large model in a data centre, which searches through a paid service and hands the finished paragraph back to you. You cannot point at a sentence in it and ask where that came from, because the paragraph carries no record of which page produced which clause. Three decisions take that apart.
- Discovery
- Orchestr.
- Task Giver
- Query Help
- Task Doer
- Evaluator
Your browser fetches the pages, so sites see a person
Today, an extension you install does the fetching. Every page request leaves your own machine, on your own connection, so a publisher sees the same request it would see if you opened the page yourself. Pages that turn away a data centre open normally for a person, so LoQuery reads sources a crawler cannot reach.
Because your browser does the fetching, no crawler of ours visits the pages you read, and no site has an address of ours to recognise. And the fair question about fetching through your browser gets a straight answer: LoQuery reads one page at a time, at the pace a person browses, defeats no paywall and no login, and the excluded-domains control keeps a run off any site you name. Your account and your run records do sit on our servers. The privacy page lists what is stored.
Sources Discovered 24 sources 8 domains
Most-used sources
- en.wikipedia.org × 6
- aviation-safety.net × 4
- recherche-research.bac-lac.gc.ca × 4
- www.canada.ca × 3
- archives.gov × 2
- nsarchive.gwu.edu × 2
- www.baaa-acro.com × 2
- ufocasebook.com × 1
Cell values, sources and caveats here are real and open to checking. The scores, attempt counts and source totals show the shape of a run and get replaced once a captured session record lands.
Extraction and judgment are separate calls, so nothing grades itself
LoQuery splits research into narrow jobs: one writes the searches, one pulls a single fact off a fetched page, one decides whether that page supports it. Every answer comes back in a fixed shape, checked by plain code, so you can tell which step produced a value and which step to check.
Every question put to the model is about a page that search already fetched, so the work is judgment over supplied evidence rather than recall from training. No value in the table comes from what the model remembers. Small open models are enough for that. A model grading its own work defends the answer it already committed to, which is why the judging step never sees how the extraction reasoned.
- 01
Extract Task Doer
Reads a fetched page and pulls out the specific value for one field, with the URL it came from. It does not score anything and it is not asked whether it did well.
-
Verdict boundary
One of exactly three places in a run where LoQuery stops to read what you typed, named for the verdict it leads to. The gate and the judge below are a single call, so whatever you sent while this item was in flight is taken here, all at once, before that call starts. Nothing is read once it is running, because acting on an instruction early costs more than making it wait.
- 02
Gate Deterministic
Plain code, no model. Six checks run over the extracted values. Dates in the future, dates outside the window you asked for, too many fields marked not-applicable, entities pulled off an aggregator page. Arithmetic, so it always fires the same way.
- 03
Judge Evaluator
A separate call with its own context. Is this actually the entity that was asked about? Is this source authoritative for this kind of claim? Does the date make sense for this event? It never sees how the extraction reasoned, which is the point.
- 04
Verdict confirmed · with caveats · uncertain · mismatch
A score, one of four verdicts, and typed caveats, each with a code and a severity rather than a sentence the model improvised. And verdict_source: evaluator.
- 05
Override You, if you disagree
Set the verdict yourself, or keep it and rewrite the reasoning. verdict_source becomes user or collaborative, and it stays that way downstream. The machine's original call is not overwritten, it is recorded as having been overruled.
LoQuery writes its own instructions for every question
The code knows nothing about securities enforcement or aviation history. Before a search runs, LoQuery decides what it is looking for, which sources count as authoritative in that subject, and what each column has to contain. Nobody added a subject, a source list or a field rule.
Aviation history · Task Plan 6 sections
- 1 · Research intent unspecified · event · aviation history
- 2 · Output fields date, official explanation, primary source, status, summary
- 3 · Research strategy DAG · 1 level
- 4 · Field limitations (none)
- 5 · Authoritative sources aviation-safety.net, gov, canada.ca, archives.gov, nasa.gov, mil
- 6 · Dynamic config summary domain: aviation history · denied_sources: 0
Enforcement · Task Plan 6 sections
- 1 · Research intent unspecified · company · enforcement
- 2 · Output fields regulator, penalty, date, filing, summary
- 3 · Research strategy DAG · 1 level
- 4 · Field limitations penalty: currency required
- 5 · Authoritative sources sec.gov, justice.gov, cftc.gov, gov, courtlistener.com
- 6 · Dynamic config summary domain: enforcement · denied_sources: 1
Aviation history · Task Plan 6 sections
- 1 · Research intent unspecified · event · aviation history
- 2 · Output fields date, official explanation, primary source, status, summary
- 3 · Research strategy DAG · 1 level
- 4 · Field limitations (none)
- 5 · Authoritative sources aviation-safety.net, gov, canada.ca, archives.gov, nasa.gov, mil
- 6 · Dynamic config summary domain: aviation history · denied_sources: 0
Enforcement · Task Plan 6 sections
- 1 · Research intent unspecified · company · enforcement
- 2 · Output fields regulator, penalty, date, filing, summary
- 3 · Research strategy DAG · 1 level
- 4 · Field limitations penalty: currency required
- 5 · Authoritative sources sec.gov, justice.gov, cftc.gov, gov, courtlistener.com
- 6 · Dynamic config summary domain: enforcement · denied_sources: 1
Press Esc or click outside to close
Sources here are real; scores and attempt counts are illustrative until a session capture lands.
The subject decides which sources count as authoritative, and LoQuery works that out from the question before anything is searched. When a subject gives it no institutions to name, the plan leaves the source list empty and flags the subject as uncalibrated.
Two ways in, and the one you pick decides what you type
A run starts one of two ways, and the choice decides what you type. Direct takes a list you already have. Give LoQuery a category instead and Discovery works the population out first, in waves, then hands the list back. You strike what does not belong, so you can settle who is in the set before anything is researched.
Direct
Vitol Inc, Glencore Ltd, Freepoint Commodities
It researches each item against your criteria and returns one row per item.
- You paste the list
- It researches each item
- Table with a source on every cell
Use it when You already know the population and need evidence about it.
Discovery
Aerial incidents over Canada or the Great Lakes that a government or military body formally investigated
It finds the population first, in waves, then hands the list back for you to approve before it spends anything researching it. Set a discovery budget and it can run straight through.
- You describe the category
- It collects candidates in waves
- It validates and removes duplicates
- You approve, strike or send it back
- Then it researches the approved list
Use it when You do not know who is in the set, and the answer depends on getting that right.
Two ways the configuration gets written, and neither is a template
Filling that gap is your job, and there are exactly two ways it gets filled. LoQuery writes the whole configuration from your description, which is what happens if you do nothing. Or you write it yourself. There is no menu of domains to pick from.
Writing it yourself is not all or nothing. Set the two fields you have an opinion about, so you can correct one run without teaching LoQuery a subject.
Auto-detect. Describe the question in plain language and a model writes the whole configuration for this run. Most people never leave here.
Build Your Own Type. You supply the configuration. Whatever you set is locked and never overwritten.
There is no third path, and specifically no library of prebuilt domain templates. Six of those existed once and were deleted, because a template list is where a general system quietly becomes a specialist in whatever is on the list.
-
entity_typeWhat counts as one row clinical_trials -
discovery_preferred_sourcesSpecialist sources to reach for first clinicaltrials.gov, ema.europa.eu, who.int -
tier_overridesPromote or demote specific domains for this run clinicaltrials.gov: 0.95 -
entity_confidence_thresholdHow sure it has to be before a candidate survives 0.70 -
additional_field_typesField names it would not recognise auto -
dedup_key_patternWhat makes two names the same entity auto -
task_doer_contextExtraction rules for this subject auto -
field_guidance_overridesWhere to look for a novel field type auto
Field names are the product's own. The values beside them are illustrative of a subject nobody configured, rather than a captured run.
Blanks are not defaults, they are deferrals. Anything you leave empty is generated for this run, and if that generation fails the static foundation underneath still answers, with a more generic result, not a broken one.
Every cell carries a source or a reason
The source sits on the cell itself, next to a verdict on how well it supports that claim, so you can defend one number without re-reading the run. Any warning LoQuery raises against its own answer sits there too. When no record resolves, every cell reads Not Found and the row says why. Nothing is filled in with something plausible.
Every item gets up to three attempts, and each one searches wider while accepting weaker sources. The full ladder is in Making an open model return Not Found.
| Item name | Score | Verdict | Why | Caveats | Date | Official explanation | Primary source | Still unexplained |
|---|---|---|---|---|---|---|---|---|
| Kinross incident 2 attempts | 0.71 | confirmed with caveats | Score 0.71; a USAF determination is on record and is contested, and no government or military file establishing it was located: the safety board's analysis, findings and recommendations were withheld under FOIA. | source_contested uncalibrated_authority_domain | 23 November 1953 aviation-safety.net/wikibase/161691 | USAF: the F-89C was tracking an off-course RCAF C-47 and was lost over Lake Superior en.wikipedia.org/wiki/Felix_Moncla | None located. The safety board's findings were withheld under FOIA; ASN WikiBase entry 161691 is user-submitted, not the USAF report aviation-safety.net/wikibase/161691 | No. A determination was issued, and the pilot of the RCAF flight named in it, Gerald Fosberg, denied being intercepted en.wikipedia.org/wiki/Felix_Moncla |
| Lake Michigan 1994 incident 3 attempts | 0.18 | mismatch | Low score (0.18); zero of 2 evidentiary field(s) filled. The 1994 reports are a cluster of sightings across several towns, so no single incident record resolves. | Not Found | Not Found | Not Found | Not Found |
Sources here are real; scores and attempt counts are illustrative until a session capture lands.
What a chatbot does, what deep research does, and what LoQuery refuses to be
A deep research mode is a chatbot given a longer leash. Rather than answer from one round of search, it plans, runs many searches, and hands back a written report with citations in it. Those citations sit inline, next to the claims they support, and none of them says how well the page supports the sentence. Whether a verdict travels with the source decides if you can defend one number later, and LoQuery puts one on every cell.
The differences fit in one table, and the last row is what a class of thirty pays. The pricing rule behind that row →
| A free chatbot | A deep research mode | LoQuery | |
|---|---|---|---|
| Where sources attach | Nowhere, or the answer as a whole | Inline, per claim, with no verdict on fit | Per claim, with a verdict on fit |
| When the record is missing | Answers anyway | Nearly always answers, cited | The cell says Not Found and why |
| Who judged, on the record | Nobody | Nobody | Every verdict names the judge: machine, human, or both |
| What a class of thirty costs | Free, sold below cost | A subscription per seat | The runs those thirty students make, at cents a run |
The same argument, stated in the negative.
-
Not a chatbot
There is no conversation with the pipeline. You configure a run, watch it work, steer it while it goes, and get a table. Nothing here is trying to sound like a person.
-
Not a search engine
It orchestrates search engines, today through your browser and your connection. We do not have an index and we are not trying to build one.
-
Not trained on a private library
It reads the live open web, per run. Nothing is retrieved from a corpus we curated in advance, so nothing is as stale as the last time we updated it.
-
Not a cache
Nothing carries over between sessions. Run the same question twice and it is researched twice, because a verdict reused from last month is a verdict nobody checked.
-
Not autonomous
A run expects you in the loop, and today it needs your browser attached. The person in the loop is the design: a tool that finished the thinking while you were away would be the thing we built this to replace.
Where we lose: reasoning, speed, testing
LoQuery loses on open-ended reasoning. A small open model under hard contracts beats a large one on verifiability, and that is the trade LoQuery is built on.
If your question needs a long chain of original thought, this is the wrong tool. We would rather say so here than have you find out on your third run.
The first answer takes longer than a chatbot's, because today searching happens in your browser at the pace a person would browse. We check quality by hand: LoQuery runs only with a browser attached, so no automated end-to-end evaluation exists yet for anyone to check.